HOWTO: 解决Windows搜索索引性能和容量问题
当 Windows 搜索性能较差或发现磁盘空间正被索引数据库吞噬时就需要进行相关的优化。通常索引性能受其项目数量和总体大小因素影响。当索引超过40万个项目时，我们便可能觉察到性能问题，它将直接体现在CPU、内存或磁盘利用率上。此外，Windows 搜索还会为 Outlook 邮箱生成索引，如果邮箱包含了超过6万个项目时，索引的性能也可能会降低。
在容量方面，随着索引数量的增长，不管这些项目的大小如何，索引数据库都会大幅增长。当然项目本身的大小也会影响数据库的大小。索引数据库的文件名为“Windows.edb”，该文件位于“%programdata%\Microsoft\Search\Data\Applications\Windows”下，若要检查该数据库的容量不能仅从文件大小来看，而是要进入其文件属性查看“占用空间”来检查其实际占用的磁盘空间。
如我们所见，当索引数量和容量这两个因素加在一起时，会使索引问题复杂化。优化的方式有一些，下来我们来看看如何对 Windows 索引进行调优。
首先，最简单直（Cu）接（Bao）的方法是重建索引。相当于复位了索引数据库，能解决不少问题，但带来的不利因素是重建时所消耗的时间和资源，并且随着时间的推荐，我们的索引依旧会重现数量和容量问题。
第二种方法，为搜索索引排除文件夹，可以打开 Windows 11 的设置应用，定位至“隐私和安全性”，使用“添加要排除的文件夹”按钮来添加。对于 Windows 10 系统可以在设置的搜索框中键入“搜索”或“排除”查找。
第三种方法，更改索引处理特定文件类型的方式。我们可以打开“索引选项”，在“高级选项”下的“文件类型”选项卡内进行配置。
第四种方法，在讲之前我们先了解一个特性！自 Windows 8 开始至 Windows 10/11 索引数据库合并了文件属性和持久索引两类数据，并且会索引整个文件，这种设计是为了提高搜索的召回率和索引以及查询的性能，即全面/综合索引法，这种方法虽然提高了搜索和查询的效率和准确性，但问题也很显而易见，尤其是在小容量固态硬盘普及时期，或小容量系统卷时，大家总会发现硬盘可用容量在不断被吞噬。
而在 Windows 7 时代，索引数据库只包含了文件属性，而持久索引则单独存储在一个扩展名为 .ci 的文件中，并且对于大型文件也只会对前部分进行索引，所以 Windows 7 的索引数据库要小很多，但其缺点也显而易见。由于文件属性和持久性索引数据存储在不同的文件中，因此可能会导致索引数据的不一致性和丢失（这就是为什么 Windows 7 时代搜索故障/问题在 IT HelpDesk 居高不下的原因）；对于大型文件，由于只索引了文件的前部分，这极大增加了搜索结果的不完整和不准确性；如果需要进行全文搜索的文件类型（TXT），其索引速度会慢很多，因为它需要访问 .ci 文件中的持久性索引数据。
全面/综合索引和分离式索引的数据存储方式各自都有一些弊端，但考虑到实际效率，且计算性能的提升以及固态存储成本的降低，前者更适应我们现实需求。
另外，还有一个问题不容忽视，Outlook 的邮箱数据文件！通常我们仅会缓存一年或者半年的邮件，此时并不会遇到很严重的容量问题。但是如果客户端将 Outlook 配置为使用 PST 文件，并且下载了所有数据，那么在 Windows 10/11 平台上，由于前面所描述的特性因素，会发现 Windows.edb 的文件容量非常之大。此时 IT 人员就需要考虑为客户端减少索引范围，然后重新生成索引来缓解。或者使用第四种方法 - 对索引数据库进行碎片整理，为此执行如下命令行。
sc config wsearch start=disabled
net stop wsearch
esentutl.exe /d %programdata%\Microsoft\Search\Data\Applications\windows.edb
sc config wsearch start=delayed-auto
net start wsearch
OK，今天的分享就到这里！如果您在应用和部署 Windows 时遇到什么问题欢迎与我联系交流。
