标签：准备 date sql 效果 持续时间 mys 开始 扫码 问题：
在之前，也写过几篇入职相关的文章，不过那时候还没有正式毕业，处于实习的状态，从 2020 年 3 月 5 号入职现在也有 180 天了。
这时间是过的真快啊，这篇文章就谈谈入职这段时间帅地在工作上的一些不足与收获 + 未来的何去何从。
1、面试各种理论，工作各种考虑不周到
记得之前面试那会，写过好几篇 MySQL 的文章，特别是索引以及锁相关的知识点，可谓倒背如流，相关底层原理也都有研究过，每次面试官让我谈谈索引以及锁的时候，数据结构的选型以及各种算法原理都能和面试官扯一遍，感觉自己 MySQL 这方面的相关理论也还行。
然而到了工作的时候，我的 sql 却写的很糟糕，倒不是因为不懂，而是自己考虑的很不周到，我举个简单化的例子吧，例如有一个表，表中只有两个字段 id 和 age，其中 id 是主键，age 也有创建索引，例如
create users(
`id` int primary key,
`age` int
)然后当时需要写一个脚本，脚本中其中一个逻辑是需要删除表中所有 age 大于 10 的行记录，这还不简单？在脚本代码中，直接一行代码暴力删除搞定（可以左右滑动）
// sql 语句
String sql = "delete from `users` where `age` > 10";
// 执行 sql 语句
query(sql);但是，实际上这个表的数据量是上千万级别的，如果满足 age > 10 的数量很大的话，例如上百万了，那么这种删除方式显然很影响性能。我们都知道，当我们进行 update 或者 delete 的时候，mysql 都会帮我们创建一个事务，并且也会加锁，那么这条删除语句可能会出现一些问题，例如
1、删除的时间可能会比较久，意味着事务的持续时间也会比较，影响其他 update 操作。
2、删除的过程中，删除了一半失败了，例如删除了 50 万条行记录，还有 50 万条没删除，那么事务就会进行回滚，这么大的数据量回滚，显然是很影响性能的。
当然，我这只是举个简单的例子，对于这种情况，其实我们可以按照 id 的大小来分批删除，例如我们可以做一个 for 循环，分批来删除。
// 获取最小 id
min_id = getUserMinId();
// 获取最大 id
max_id = getUserMaxId();
// 之后阶段性删除，每次偏移 10 万
for(int i = min_id; i <= max_id; i += 100000)
{
int temp = i + 100000;
delete from `users` where `id` >= i and `id` < temp and `age` > 10;
}这种方式的话，性能方面就会好一些，说实话，这种方式一点也不难，不过刚开始的时候，我却也没想到，后面是我导师 review 代码的时候，我才知道，还可以这样，当然，这只是个简单的例子，实际的场景要复杂一些。
还有一次也是写一个脚本来每天扫码表里的数据，把那些符合某种规则的记录拿出来更新一下，并且每个行记录每天只能更新一次。
不过我也没有考虑幂等性的问题，例如一个脚本突然中途挂了，如果你重新手动执行脚本的话，那么有些数据可能就会被更新了两次，显然这会使得数据不准确，这个时候我们就必须保持每个行记录只能被更新一次，也就是说，如果脚本一天内多次执行的话，我们得保持行记录只会更新一次。
这些都是一些基本的常识，不过自己在写代码的时候，却很少注意到这些，导致写到代码容易出现一些问题，说白了就是，考虑不周到。
这只是其中两个例子，简单的代码，自己还是有挺多考虑不周全…
2、不细心
记得有一次，需要改项目的配置文件，我直接复制一些代码，然后就直接替换到配置文件里，感觉自己写的应该没问题，因为就新增一些配置文件嘛，而且我又是直接复制粘贴的，那肯定稳。
刚好我导师对比了下原文件和我修改过的文件，特么我才发现自己把一些原有的文件给吃掉了，在自己粘贴的时候，鼠标不小心选到了一些原有的配置文件，直接把某一行的几个字符给覆盖了。如果我自己不要自以为是，细心检查一下就能发现这个问题了……为此我还被导师教育了一波
这些问题难吗？我为什么没考虑到？为什么我平时做算法题的时候，能够很快着找出这道算法题的一些临界点，能够很快地知道这道算法题有哪些陷阱？而在工作中，却变的这么不严谨？
1、暴力遍历与精准匹配
记得刚做算法题那会，我刚学了一些算法思想，例如动态规划，递归，回溯，枚举，贪心，由于这些算法思想在运用方面还不熟，所以我每次做的时候，都会想一下这道题用什么算法思想比较好，最开始的时候，我是用脑袋遍历一下这几个算法思想，看一看哪一种算法思想是可以套用进去的。
后来，这些算法思想运用的熟悉了，每次看到一道算法题的时候，脑子会马上自动想到使用其中的算法算法思想来匹配。当有人问我是如何想到用这种算法思想的时候，我可能会告诉他们：其实我也不知道为何会想到这一种，更多的是一种神经反应吧，脑子里，就自动把这道算法题和某种算法思想精准匹配起来了。
说白了，其实就是熟能生巧吧，最开始我们可能无法快速定位，后来做多了，我们的脑子里有了一定的积累，就会自动马上联想到采用哪一种方式了。
2、其实工作也是一样的
刚开始，看着自己这么不严谨，这么不细心，其实心里是有点埋怨自己的，特么这么简单的事情都没想到？？
后来，想了一下，虽然在其他一些领域自己挺严谨、细心，但到了实际工作上的时候，自己就不一定也能这么严谨、细心了，所以为了让自己以后能够细心点，我会把自己考虑不周到的事情记录下来，下次写代码的时候，先逐一核对一下自己的代码里是否还会出现这些错误。每发现一个错误，我就会记录一个错误，可能慢慢着，就可以减少自己的错误。
慢慢着，当我对这些陷阱足够熟悉的时候，应该就不需要暴力遍历了，应该就可以看一眼代码，就能快速看出这行代码是否有问题了。
也就是说，当我们在做一些不是很有把握的事情的时候，不妨先想一下，先遍历一下曾经遇到过的坑，可能遍历的次数足够多了，我们就可以直接神经反应定位到了。
在工作上，有时会因为一些简单的事情自己没有做好而产生一些挫败感，当然，对于这些，我会尽力去减少自己的犯错。同时也很感谢我的导师，也给予了我挺多的帮助，帮我 review 代码，找出代码存在的一些问题，然后给我建议，告诉我应该怎么优化。
不过，入职鹅厂的这半年里，其实我还有另外一个还需要去重视的问题：工作与内容写作上的平衡。
其实我的文章，更多的是为读者而写的，而不是为了更好着提升自己的技术，例如我平时写的春秋招相关的，面试相关的，算法、计算机基础相关的，其实我工作之后，基本很少用到这些，用的技术和语言，可能和大部分的读者都不一样，所以我写的文章，是真的为你们而写。
大家都知道，我这号有 10 万粉丝，微信有一万多好友，每天花在写文章，维护微信号的时间还是挺多的，这就导致我在工作上的时间有所减少，并且你要知道，这不仅仅是时间减少的问题，这还会使你各种分心，例如你会时刻关注你公众号的一些后台消息，会关注留言，会关注文章的阅读量，会关心每一天的涨粉情况等等。
而这些，都会让你在无形之中，花掉不少的时间，如果你也写过公众号，可能也会有所体会吧。
而对于现在的我来说，工作经验不多，需要快速去提升自己的技术。也就是说，一边是技术，一边是写作，而我两者都不可能丢下，当然有人可能会说，你可以通过写工作相关的文章啊，这样既可能写文章，也能提升自己的技术。
说的倒简单，但实际搞起来，却没有那么容易，对于一个拥有 10 万粉丝的号主来说，每一篇文章，都必须考虑很多指标，例如阅读量，点赞率，转发率，涨粉效果，读者评价等等。
本科毕业能够进入腾讯这样的大公司，也算是挺幸运，一毕业特么还能拥有一个 10w+ 粉丝的公众号，也是极其幸运，这两种幸运交互在一起，有时候就会产生某种冲突。当然，比起失去其中一个，同时拥有这两个肯定是更佳的，只是现在的我，需要做的就是，如何把这两种给合理运行起来，让他产生出更好的「运气」。
我身边其实也有和我类似的号主，也是在大公司，也是年纪差不多，也是坐拥 10w+ 粉丝，可是，每个人的计划都不尽相同，很多时候，很难找到一个自己觉得「十分可行」的方案。
当然，我也向一些工作多年的大佬讨教过，但，很多时候，建议始终是建议，自己心里那么总有一道坑，总是飘忽不定，道理大家都懂，就像有些人经常问我，我该准备工作还是准备考研啊？担心准备了工作，万一还是找不到理想的公司，那便错过了考研；或者准备考研的话，万一考不上，便会错过了秋招…
也就是说，现在的我，虽然起步很不错，但未来的路，其实我也不大清楚，该如何走，才能获得更好的收益，说实话，我是真心不知道啊，但，人生也算是一场赌博，未来的路，更多的，我会自己去探索吧，未来何去何从，就让时间去决定吧。
时间是过的真快，一周复一周，一小心，入坑职场已半年，在这半年的时间里，虽然挺忙，但过的很充足，这半年里，最需要批评自己的，应该就是缺少运动了，立了好几次 flag
呵呵，你懂的，还是躺床上睡觉香，目前是一周去跑步 1～2 次，跑着步，听着歌，那种满身大汗的感觉是真的舒服啊，不行，这次在文章里也来立一次 flag，一周坚持夜跑 3+ 次。
最后，未来路漫漫，何去何从，就交给时间吧，我需要的，便是做好眼前事，虽然也不清楚眼前做的这些事，是对还是错！
标签：准备 date sql 效果 持续时间 mys 开始 扫码 问题：
原文地址：https://blog.51cto.com/15015171/2554447
