@kuanat 你好，谢谢你的回复，但是你完全没有仔细阅读 1 楼的内容，我从来没有讨论文件内容索引的问题，我从来没提文件 IO 的事情。我一直讨论的是文件名，文件路径，文件大小，修改时间这些快速索引，搜索，排序的问题。

至于 x64 逆向我会，但是你能从从汇编反向推出来核心索引算法吗？除非花费大量的时间，否则根本不可能，你顶多下个断点，知道什么时候触发一下。

@tool2d 感谢回帖，我也想过 bloom filter ，但是我自己测试是这样的，上面也有提到，我的硬盘中有 100 万文件，其中几十万（具体 90 万）文件都包含"a"，我不知道他是如何在 5 毫秒（ everything 单个字符搜索 5 毫秒，二哥字符 15 毫秒）内完成的，现在 bloom filter 对这个案例过滤不了多少，并且用 priority_queue 也无法保证在 5 毫秒内完成 90 万文件搜索+排序。所以最大的问题是，everything 能再 5 毫秒内完成 90 万文件的操作，并且整个过程中好像还没有并行计算，我观察 CPU 都多核没变化。如果按照分库分表并行的话，必然 CPU 会有不少波动，我上面说的并行方法其实就用的分库分表，不能符合预期。还有什么其他的方法愿意分享吗？多谢