为什么 Windows 文件管理器中自带的搜索往往慢于 Everything 的文件搜索速度相信几乎每个人都有过这样的崩溃瞬间在 Windows 文件管理器中自带的搜索框里输入一个文件名然后看着顶部的绿色进度条像蜗牛一样慢慢爬行风扇开始狂转等了几分钟才弹出文件搜索结果。而在安装了文件搜索软件Everything之后体验却迎来了降维打击输入名字的瞬间结果秒出。哪怕你的硬盘里有几百万个文件它也能在眨眼间找到你想要的那个。为什么同样是在同一块硬盘上找东西微软官方自带的搜索被一个体积仅有几十MB 的第三方软件按在地上摩擦今天我们就来扒一扒这背后的原因。文章目录为什么 Windows 文件管理器中自带的搜索往往慢于 Everything 的文件搜索速度 Windows 搜索求全不求快1. 传统的文件遍历2. 沉重的“全文内容”索引⚡ Everything直接读取系统中的主文件表MFT1. 首先直接读取系统中的主文件表MFT2. 文件变更后的更新读取 USN 日志 差异对比总结 Windows 搜索求全不求快Windows 的文件搜索慢是因为它的工作逻辑是传统的目录遍历 内容全文索引。1. 传统的文件遍历当你没有建立索引或者在非索引区域搜索时Windows 会从根目录开始一个文件夹一个文件夹地打开遍历里面的所有文件对比文件名是否包含你的搜索词。这样会产生海量的磁盘随机 I/O 操作。如果你的有的文件层级很深、数量庞大磁盘读写就会成为巨大的瓶颈。2. 沉重的“全文内容”索引当然为了解决遍历慢的问题Windows 引入了索引机制Windows Search 跑在后台的SearchIndexer.exe。但微软的文件搜索功能的设计初衷是“大而全”它不仅记录文件名还要解析文件内容。它会打开你的 Word 文档、PDF、TXT 甚至邮件把里面的文字全部提取出来建立倒排索引。它还会读取照片的 EXIF 信息、MP3 的歌手专辑信息等元数据。这种事无巨细的搜索策略导致了两个致命后果建立索引极慢且消耗资源每次重装系统或大批量导入文件后系统都会在后台疯狂扫盘导致 CPU 和磁盘占用率飙升。索引数据库极其庞大包含全部文件内容的索引库会变得异常臃肿即便是在索引库里进行匹配由于检索维度太多速度也快不起来。⚡ Everything直接读取系统中的主文件表MFTEverything 之所以快是因为它的作者 Voidtools 放弃了传统的文件遍历直接绕过了文件系统 API去读取硬盘的主文件表MFT。1. 首先直接读取系统中的主文件表MFT如果你使用的是 NTFS 文件系统现在 Windows 默认且最常用的硬盘格式硬盘上会有一个隐藏的系统文件叫做MFT (Master File Table主文件表)。把整个硬盘想象成一个巨大的图书馆你的各种文件相当于这个图书馆里的书MFT 就是这个图书馆的书名目录。硬盘里的每一个文件和文件夹在 MFT 中都有一条对应的记录里面保存了文件名、大小、创建时间以及文件在物理硬盘上的存放位置。Everything 的做法是启动时直接请求管理员权限绕过常规 API直接读取并解析整个硬盘的 MFT 数据。由于 MFT 是连续存放在硬盘上的结构化数据读取它是一个顺序 I/O 操作。即便你有 100 万个文件MFT 的大小也就几十 MB读取并加载到内存中只需要短短几秒钟。加载到内存后Everything 会在内存中构建一个高效的搜索树。当你输入关键词时它其实是在内存中直接比对字符串这速度当然很快了。冷知识这也是为什么 Everything 在早年间必须要求 NTFS 格式的硬盘。如果你在 FAT32 或 exFAT 格式的 U 盘上用 Everything它也只能退化成和 Windows 文件管理器的搜索一样去慢慢遍历目录虽然现在它支持对这些格式建立缓存但首次加载依旧会慢。2. 文件变更后的更新读取 USN 日志当文件发生变化新建、删除、重命名时如何保持索引的实时同步也是个难题。如果不停地扫描硬盘又会变成 Windows 搜索那样吃资源。但是 Everything 再次利用了 NTFS 的一个特性USN Journal (更新序列号日志)。NTFS 文件系统本身自带了操作日志功能。硬盘上任何文件的增删改查NTFS 都会在 USN 日志里默默记下一笔比如上午 10 点在 D 盘新建了test.docx。Everything 只需要在后台监听这个 USN 日志就可以了。系统一有风吹草动Everything 瞬间就能知道然后以极低的资源消耗更新自己的内存索引。整个过程几乎不占用 CPU 和磁盘读写。 差异对比总结特性对比Windows 自带搜索Everything搜索目标文件名 文件内容 元数据仅限文件名及大小、日期等属性底层原理目录 API 遍历 后台爬取全文索引直接读取 NTFS MFT 内存检索更新机制监听系统事件 / 定时扫描重构实时监听 NTFS USN 日志资源占用高经常引发高 CPU 和高磁盘占用极低几十 MB 内存占用适用场景想找某段文字存在哪个文档里时知道文件名想要立刻找到该文件时其实说 Windows 搜索“垃圾”多多少少有些冤枉微软。两者的功能定位不同Windows 搜索是一个“内容搜索引擎”它的目标是让你能通过一句台词找到一个文档。Everything 是一个“文件名定位器”它的目标是将文件名的检索效率推向物理极限。但在我们日常绝大多数的使用场景中我们的文件搜索需求其实都只是根据文件名或文件名包含的部分关键字来找到对应的文件路径而已。在这种需求下放弃了沉重历史包袱、把底层特性利用到极致的 Everything自然就成了封神的效率工具。 你平时的文件查找更习惯用 Windows 自带搜索还是 Everything除了 Everything你还知道哪些能快速搜索文件的神仙工具欢迎在评论区分享交流
【小科普】为什么 Windows 文件管理器中自带的搜索往往慢于 Everything 的文件搜索速度？
为什么 Windows 文件管理器中自带的搜索往往慢于 Everything 的文件搜索速度相信几乎每个人都有过这样的崩溃瞬间在 Windows 文件管理器中自带的搜索框里输入一个文件名然后看着顶部的绿色进度条像蜗牛一样慢慢爬行风扇开始狂转等了几分钟才弹出文件搜索结果。而在安装了文件搜索软件Everything之后体验却迎来了降维打击输入名字的瞬间结果秒出。哪怕你的硬盘里有几百万个文件它也能在眨眼间找到你想要的那个。为什么同样是在同一块硬盘上找东西微软官方自带的搜索被一个体积仅有几十MB 的第三方软件按在地上摩擦今天我们就来扒一扒这背后的原因。文章目录为什么 Windows 文件管理器中自带的搜索往往慢于 Everything 的文件搜索速度 Windows 搜索求全不求快1. 传统的文件遍历2. 沉重的“全文内容”索引⚡ Everything直接读取系统中的主文件表MFT1. 首先直接读取系统中的主文件表MFT2. 文件变更后的更新读取 USN 日志 差异对比总结 Windows 搜索求全不求快Windows 的文件搜索慢是因为它的工作逻辑是传统的目录遍历 内容全文索引。1. 传统的文件遍历当你没有建立索引或者在非索引区域搜索时Windows 会从根目录开始一个文件夹一个文件夹地打开遍历里面的所有文件对比文件名是否包含你的搜索词。这样会产生海量的磁盘随机 I/O 操作。如果你的有的文件层级很深、数量庞大磁盘读写就会成为巨大的瓶颈。2. 沉重的“全文内容”索引当然为了解决遍历慢的问题Windows 引入了索引机制Windows Search 跑在后台的SearchIndexer.exe。但微软的文件搜索功能的设计初衷是“大而全”它不仅记录文件名还要解析文件内容。它会打开你的 Word 文档、PDF、TXT 甚至邮件把里面的文字全部提取出来建立倒排索引。它还会读取照片的 EXIF 信息、MP3 的歌手专辑信息等元数据。这种事无巨细的搜索策略导致了两个致命后果建立索引极慢且消耗资源每次重装系统或大批量导入文件后系统都会在后台疯狂扫盘导致 CPU 和磁盘占用率飙升。索引数据库极其庞大包含全部文件内容的索引库会变得异常臃肿即便是在索引库里进行匹配由于检索维度太多速度也快不起来。⚡ Everything直接读取系统中的主文件表MFTEverything 之所以快是因为它的作者 Voidtools 放弃了传统的文件遍历直接绕过了文件系统 API去读取硬盘的主文件表MFT。1. 首先直接读取系统中的主文件表MFT如果你使用的是 NTFS 文件系统现在 Windows 默认且最常用的硬盘格式硬盘上会有一个隐藏的系统文件叫做MFT (Master File Table主文件表)。把整个硬盘想象成一个巨大的图书馆你的各种文件相当于这个图书馆里的书MFT 就是这个图书馆的书名目录。硬盘里的每一个文件和文件夹在 MFT 中都有一条对应的记录里面保存了文件名、大小、创建时间以及文件在物理硬盘上的存放位置。Everything 的做法是启动时直接请求管理员权限绕过常规 API直接读取并解析整个硬盘的 MFT 数据。由于 MFT 是连续存放在硬盘上的结构化数据读取它是一个顺序 I/O 操作。即便你有 100 万个文件MFT 的大小也就几十 MB读取并加载到内存中只需要短短几秒钟。加载到内存后Everything 会在内存中构建一个高效的搜索树。当你输入关键词时它其实是在内存中直接比对字符串这速度当然很快了。冷知识这也是为什么 Everything 在早年间必须要求 NTFS 格式的硬盘。如果你在 FAT32 或 exFAT 格式的 U 盘上用 Everything它也只能退化成和 Windows 文件管理器的搜索一样去慢慢遍历目录虽然现在它支持对这些格式建立缓存但首次加载依旧会慢。2. 文件变更后的更新读取 USN 日志当文件发生变化新建、删除、重命名时如何保持索引的实时同步也是个难题。如果不停地扫描硬盘又会变成 Windows 搜索那样吃资源。但是 Everything 再次利用了 NTFS 的一个特性USN Journal (更新序列号日志)。NTFS 文件系统本身自带了操作日志功能。硬盘上任何文件的增删改查NTFS 都会在 USN 日志里默默记下一笔比如上午 10 点在 D 盘新建了test.docx。Everything 只需要在后台监听这个 USN 日志就可以了。系统一有风吹草动Everything 瞬间就能知道然后以极低的资源消耗更新自己的内存索引。整个过程几乎不占用 CPU 和磁盘读写。 差异对比总结特性对比Windows 自带搜索Everything搜索目标文件名 文件内容 元数据仅限文件名及大小、日期等属性底层原理目录 API 遍历 后台爬取全文索引直接读取 NTFS MFT 内存检索更新机制监听系统事件 / 定时扫描重构实时监听 NTFS USN 日志资源占用高经常引发高 CPU 和高磁盘占用极低几十 MB 内存占用适用场景想找某段文字存在哪个文档里时知道文件名想要立刻找到该文件时其实说 Windows 搜索“垃圾”多多少少有些冤枉微软。两者的功能定位不同Windows 搜索是一个“内容搜索引擎”它的目标是让你能通过一句台词找到一个文档。Everything 是一个“文件名定位器”它的目标是将文件名的检索效率推向物理极限。但在我们日常绝大多数的使用场景中我们的文件搜索需求其实都只是根据文件名或文件名包含的部分关键字来找到对应的文件路径而已。在这种需求下放弃了沉重历史包袱、把底层特性利用到极致的 Everything自然就成了封神的效率工具。 你平时的文件查找更习惯用 Windows 自带搜索还是 Everything除了 Everything你还知道哪些能快速搜索文件的神仙工具欢迎在评论区分享交流
