C 盘红了好几天，用空间分析工具一扫，系统盘的 ProgramData 目录下躺着一个好几 G 的 Windows.edb，旁边还有一堆日志文件。删不删？能删，但要按顺序来，直接删文件有时候服务起不来，或者索引一直重建耗 CPU。

这一堆文件分别在哪

索引数据库在系统盘 ProgramData 下的 Microsoft/Search/Data/Applications/Windows 目录里，文件名 Windows.edb。它等价于整个索引，几十万封邮件和文档的环境里长到 20GB 很常见。运行日志在事件查看器的应用程序和服务日志里，Microsoft/Windows/Search 下面的 Operational 就是。

日志可以清，数据库要重建

事件日志本身占不了多少空间，清掉不会有副作用，只是历史记录没了。真正占地方的是 edb。正确顺序是：先在服务里停掉 Windows Search，再删掉 edb 文件，然后重新启动服务，系统会自动建一个新的。嫌麻烦就在索引选项里点高级，选重建，走的是同一件事，只是慢一些。

不想重建就先把范围缩小

控制面板的索引选项里点修改，把不需要的位置取消勾选。常见元凶是整个 D 盘、Outlook 的离线缓存、以及某些同步网盘的目录。把这几项排除，索引体积往往能降一半以上，搜索响应还更快。改完等它自己收缩，不用手动删库。

干脆关掉服务行不行

可以，但要想清楚代价。关了之后开始菜单搜不到程序，文件资源管理器里的搜索变得极慢，Outlook 搜索会退化到慢速模式。固态硬盘用户日常影响不算大，机械盘或者经常靠搜索找文件的人会很别扭。关掉后 edb 不再增长，占用的空间也就固定了。

更省心的组合

用 Everything 这类工具做文件名搜索，索引文件小、结果秒出，几乎不占空间。需要全文检索时再用 Windows Search，两者并存不冲突。日常找文件靠前者，找文档里的某句话靠后者，各管一段。

清完还反弹怎么办

重建后几天又长回原样，说明索引范围里有个巨大的、频繁变动的目录，比如代码仓库或者虚拟机磁盘。把这类目录明确排除，别让它参与内容索引。同步盘的缓存目录也是常客，文件名天天变，索引跟着重写。

取舍：硬盘紧张就先缩小索引范围，再考虑删库重建，最后才是关服务。直接关掉最省空间，但你会在某天找不到文件时想起它。