Windows 搜索索引器为什么会连吃几个小时 CPU

是积压，不是 bug

索引器跟踪 NTFS 的 USN 更改日志，所以每一次大规模文件事件都会变成索引工作。重新解析系统卷的 Windows 功能更新、拉下数千个文件的 OneDrive 或 Teams 同步、恢复的备份，或者开发者新拉的 node_modules 树——每一项都能让几十万个条目排队。索引单个条目很便宜；索引几十万个要花几小时，而你在任务管理器里看到的正是这个。

另一个经典是 Outlook：庞大的 .pst 或 .ost 存档会通过同一条流水线逐条索引，一个 20 GB 的邮件存档能让索引器忙掉大半个工作日。打开“索引选项”，读一读状态行——“剩余项目”计数巨大而已索引总数在涨，说明这是一个正在清积压的健康索引器。计数不动，或者 CPU 高企的同时数据库膨胀到离谱，则指向一个循环重建的损坏索引——这也是唯一真正需要“重建”按钮的场景。

带有大型 .pst 或 .ost 文件的经典 Outlook——同一服务逐条索引
向机器同步数千个文件的 OneDrive、Teams 或备份恢复
重新解析系统卷并重新校验索引的 Windows 功能更新
开发者目录：包含数万个小文件的 node_modules、构建输出和 .git 文件夹
触碰全部文件元数据的扫描工具——整个磁盘重新排队
损坏的 Windows.edb 或 Windows.db 索引，不断重建、膨胀、再重建

不破坏搜索的前提下驯服索引器

杠杆率最高的动作是控制范围，而不是控制服务。在“索引选项”里点“修改”，把那些你从不搜索的树全部取消勾选——构建文件夹、媒体存档、下载泥潭——然后让改动沉淀。对于经典 Outlook 存档，只索引你真正会搜索的存储，而不是历年来挂载过的每个 .pst；任何范围改动之后给索引器一晚上：傍晚六点看起来无穷无尽的队列，常常到早上就清完了。

不要为了解决 CPU 峰值而禁用搜索服务。索引关闭时，资源管理器在已索引位置的搜索、开始菜单结果和 Outlook 搜索都会退回缓慢的逐盘爬取模式，而且服务重新启用的那一刻，积压照样回来。如果索引确实损坏了——循环重建的症状——就在“索引选项”里用“高级”和“重建”一次性删除并重养数据库：这会一次性花掉几小时 CPU，并终结循环。在多用户并发的服务器上，记住索引器按用户各跑一份：多个 SearchIndexer.exe 实例就是多份独立的积压。