详解 Windows 搜索索引:那些 edb 文件到底在干什么

索引的机械原理

搜索索引是建在 Extensible Storage Engine(ESE)上的真数据库——与 Exchange 邮件存储和 Active Directory 同款引擎——住在 C:\ProgramData\Microsoft\Search\Data\Applications\Windows。在 NTFS 卷上，索引器订阅 USN 更改日志，新保存的文件几秒内就会被收录，不必等完整遍历磁盘。文本由 iFilter 和属性处理器提取，所以一文件夹 PDF 和一文件夹纯文本的索引方式并不相同。这一切最终落进一整套大多数人从未打开过的文件里。

Windows.edb —— 主数据库，存路径、属性和提取的内容
Windows.db —— 近期版本里加入家族的新属性存储
edbXXXXX.log —— 事务日志，让写入在落库前就抗崩溃
edb.chk —— 检查点文件，标记哪些事务已刷入磁盘
tmp.edb —— 引擎为维护过程预留的暂存空间

edb 文件组为何增长——以及何时算问题

健康的经典模式系统上，整套文件在 50 MB 到 1 GB 之间，随文档数量伸缩，没什么可修的。默认索引整机的增强模式，一旦轮到游戏库、项目目录树和虚拟机文件夹，就会把数据库推到数 GB。Outlook 是经典的放大器:PST 和 OST 数据文件也做全文索引，一个邮件存档能在一夜之间把 300 MB 的索引变成 4 GB。

真正的麻烦是这样现身的:Windows.edb 持续增长，搜索却变慢甚至一无所获——通常是脏关机或系统盘塞满后，索引器反复重写一个损坏的数据库。在这种状态下，重建是标准的第一步，不是赌博。日志文件本身不算泄漏:Windows 保留一组轮换日志，会自动裁掉旧的。

不搞坏任何东西地重建索引

官方路径是控制面板 → 索引选项 → 高级 → 重建;“设置”里的“搜索 Windows”页面负责经典/增强模式切换和文件夹修剪。重建会删除数据库并从头爬一遍，所以在大型库上搜索会瘫软一两个小时——这是修复在工作，不是失败。手动路线——停止 Windows Search 服务、删掉 Windows.edb 和日志、再启动服务——效果相同，因为 Windows 会在下次启动时重新生成整套文件。

不该做的是把 Search 文件夹排进每周清理计划。索引存在的意义就是让搜索即时，每七天删它一次，等于拿 1 GB 磁盘去换一个永远半温不火的索引和无穷无尽的重新爬取。真有症状时重建一次，其余时间别碰。