@leopod1995 #20 开启这个参数之后，速度有一点提升，不过影响不是很大，也是非常感谢！

@bilibiliLM #6 是的 话说我感觉右面的 ctrl 也想利用起来- - 。。

突然感觉这是一个好设计。。。一直用不上右面的 alt

读的话是在职研究生吗？感觉研究生毕业了。。形式就更不好了，目前 it 形式就不是特别明朗了，比较饱和。要是在职的，半工半读可能会更好。
如果不是为了学历，只是为了弥补知识点，那还是继续工作，然后晚上回家自学比较靠谱。
而且考研也要考虑到考研失败之类的损失。
不过我看你写的这个非常清晰，好久见不到读起来这么舒服的文章了，你做什么应该都会成功，加油！

你这个消费水平，买个 cpu 纠结 500 块钱，肯定是不正常的，建议去查查是否有心理方面的疾病。一定要正视心理问题，不能逃避。

win10 才 50 个 G 确实吃不消

问下。。N+1 真的会收到么。。一般不是让主动离职吗，不离职的，也慢慢把你熬到主动离职。。

如果你说的是真的。。那你试试去投诉一下咸鱼。

@libook #18 试了一下，deleteMany 比较慢，大部分时间都消耗在这里。

@libook 通过 2000 个 objectid 直接查询，瞬间就查询到结果了。应该是具体删出的时候，非常的慢。
@matrix67 刚看了下 iops，很有道理，但是刚刚找了一下，没有对 iops 的查询工具，您有推荐吗？
@opengps 是希捷的 7200 转 6T 盘，物理服务器

@libook 奥我理解你的意思了，我直接去 find2000 个指定的 objectid 试试速度去。

@libook 感谢分享思路。我目前从集合 A 查询 2000 条 ObjectID 加上处理这些 ID 大约在 500ms 左右，处理后的 ObjectID 大约剩下 1500 条左右，然后开始执行 集合 B.delete_many({'_id': {'$in': dup_list}}) ，就非常的慢。我现在不太好定位具体是在集合 B 查询 ObjectID 太慢，还是查询后删除太慢。。这个语句是应该是在一个事务里的？
@misaka19000 硬盘还是比较新的，使用了没几个月，应该不是写性能的限制，之前拷贝数据的时候，能到到 200M/s 的吞吐。 不过目前也有个问题没查出来，就是用 iotop，进程的 io 百分比接近 100%，但是实际上磁盘的吞吐只有几 M 而已，不知道这个百分比是怎么计算的。

@asilin #7 用于删除脚本的 io 确实是接近 100%，但是服务器磁盘的吞吐才不足 10M 每秒，请教下，进程的 io 接近 100%是指给这个进程分配的 io 使用量被占满了吗？我看远不到磁盘的吞吐量。
@liprais 没太理解

话说。。。。想了一个搞笑的。。。。。你用触摸板的时候，手指头是不是一直粘在上面。。哈哈哈哈哈哈哈。。。。。。。。。。。。。。。

你怕不是不会用鼠标，你怕是没玩过比较费鼠标的游戏- -

什么是：“也并出现拖欠工资吧，最多晚发一天。”

也尝试了多线程、多进程的方式，性能就变更慢了。。

@rrfeng 感谢，没有看出有什么异常的情况。
@laminux29 应该不是应用层的问题，瓶颈不在代码上。
@Vegetable 因为数据量比较大，之前把 ObjectID 都整理到另一个集合了。从一个集合查询，然后删除。
@libook datacol.delete_many({'_id': {'$in': dup_list}})
瓶颈应该是在从百亿数据里面查询对应的 objectid，然后删除。真的是非常慢。。一秒就能查询到 300 左右然后删除掉。