我这边是这么玩的，初始化的时候 100 为基数，调整顺序的时候（ A+B ）/2，如果找不到，对 B 的值进行增大处理，增大的时候，（大于 B 的+小于 B 的）/2+50，绝大部分情况不用调整很多的顺序就能找到空隙，一旦找不到，这次调整会比较慢，因为要调整较多的记录数，但是这次调整完了，后续的就会很快了。
A 100
B 200
C 300

说的难听一点，早干嘛去了，离职的时候干嘛去了。既然做了就实话实说，否则直接黑名单，得不偿失。

先关掉后台刷新试试

过来人说一下，你最终是要和家里人一起生活的，家人的幸福程度决定你的幸福指数，我最后选择回家。家人都在南昌，南昌和合肥的差距不是很大，建议选择南昌，虽然工作机会少，但是竞争压力也相对的小，小城市靠关系，但是反过来，因为家人在，你也容易有关系。如果真的是想拼一下，那就要去一线大城市北上广，不要呆在合肥这种啥都算不上的地方。

只要说清楚，能做到表里如一就是是进步。

有责任感就是非常好了，想想后续怎么优化更重要。不要两次掉在一个坑里面！

我一直用 md + grep 管理我自己的代码片段~，这玩意还用得着单独的软件来管理？

和 @PP 的看法一致。这个待遇在传统制造业里面算是还不错了，看 jd 要求实际上是想找一个老家伙，经验经验丰富的而且学习能力强的，但这个薪资虽然在制造业不错，但是真的算不上有吸引力。我这边一个哥们，杭州，信息化总监，40 一年，传统制造业的上市公司，现在也是面临着信息化转型的问题（主要是近年来人力成本上升，质量问题靠人难以完全控制），这边招聘的待遇是上不封顶，所以你这个待遇留人是很难的。建议你：1. 看看能不能给期权或者股权 2.看看能不能降低要求，选择有潜力的毕业生进去培养 3.多发发环境、生活方面的东西，到了一定程度的老家在那边的人想养老的人看重这个。4.再看看能不能解决个人问题，要是有个好妹子，干啥都行，你说是不~

@woxibohua 实话说，你这个待遇太低了，愿意沉下去，而且靠谱的人 20W 起步。

看到待遇水平，太吃惊了，9K 现在应该找不到人吧。我在传统制造业，工人差不多 5-8K，30-50W 左右的也挺多的啊

MySQL 太不靠谱，这种情况下居然表会坏~

pg 的话可以意向锁或者 for updte，mysql 看看有没有 for update 的等价物。

字典绑定，工厂方法

那个行业的，我也是做行业的，可以聊聊，感觉机会还是挺多的

这种需求建议在业务层处理，窗口函数用起来爽，等到后面加需求的时候，慢慢慢慢的性能就被脱下来了。

@lihongjie0209 依赖数据批量加载进去，按批次处理，3000 条数据依赖也不会太多。关键在于数据要批量加载、处理、保存。

@lihongjie0209 你想的太多了，才 50 万数据，根本不用考虑那么多，一个批次 3000 条的处理就完全足够了。

这么简单的需求，最省心的就是 sql 到底。