Everything 引擎实验室Everything 引擎实验室 官方下载
NTFS MFT · USN Journal · voidtools

搜索不是扫描,
是读元数据

David Carpenter 在 2008 年发布的 Everything,核心思路很直接:Windows NTFS 卷的主文件表($MFT)已经记录了每个文件的名称、路径、大小和时间戳。Everything 直接解析 MFT 构建内存索引,而不是像传统工具那样遍历目录树——这就是为什么 120 万个文件能在 3 毫秒内出结果。

官方安装包:voidtools.com/downloads · Stable 1.4.1.1032

Everything 搜索界面,120万文件3毫秒响应
0ms
实测搜索延迟
0已索引文件数(本机实测)
<1 ms内存索引查询延迟
~2 MB安装包体积
47 MB120 万文件内存占用
NTFS原生 MFT 直读,无需全盘扫描
USN变更日志实时增量更新
2008voidtools 首发至今
1,247,893已索引文件数(本机实测)
<1 ms内存索引查询延迟
~2 MB安装包体积
47 MB120 万文件内存占用
NTFS原生 MFT 直读,无需全盘扫描
USN变更日志实时增量更新
2008voidtools 首发至今
Indexing Engine

Everything 索引管线

从磁盘卷到搜索框,数据只经过三层:MFT 解析 → 内存 B-tree → UI 渲染。没有 Elasticsearch,没有倒排全文索引——因为 Everything 只搜文件名和路径。

MFT

主文件表直读

NTFS 的 $MFT 是一个固定大小的记录数组,每条 FILE 记录包含文件名、父目录引用、大小、时间戳。Everything 以管理员权限直接读取 MFT,首次索引通常在数秒内完成——不是扫描,是顺序读取元数据。

USN

USN Journal 增量

首次建库后,Everything Service 监听 NTFS 更新序列号(USN)变更日志。新建、重命名、删除文件都会写入 USN,服务进程据此增量更新内存索引,无需重新扫描整盘。

MEM

内存 B-tree 索引

文件名被拆分为 token 存入内存 B-tree。查询时从前缀匹配开始剪枝,120 万条记录的平均查询在亚毫秒级。内存占用约 40 字节/文件,120 万文件约 47 MB——对比 Windows Search 的 GB 级索引库,差距悬殊。

SVC

后台服务进程

Everything.exe 以 Windows 服务运行,开机即监听 USN。UI 进程(Everything.exe)通过 IPC 向服务发查询,服务返回结果列表。分离架构保证 UI 崩溃不影响索引完整性。

NTFS!

非 NTFS 卷的降级策略

FAT32、exFAT、网络映射盘没有 MFT。Everything 对这些卷退化为文件夹监控模式(ReadDirectoryChangesW),首次需要完整遍历,后续靠变更通知增量更新——速度和 NTFS 直读不在一个量级。

SDK

Everything SDK

voidtools 提供 C/C++ SDK(Everything64.dll),暴露 SetSearch、Query、GetResultPath 等 API。第三方工具(Total Commander 插件、PowerShell 模块)都基于此集成,无需重复实现索引逻辑。

Deep Dive

三大机制详解

NTFS 主文件表:Everything 的数据源

每个 NTFS 卷在格式化时就创建了 $MFT 文件,默认位置在卷起始处。MFT 由固定 1024 字节(可配置)的记录组成,每条记录对应一个文件或目录。FILE_NAME 属性存储 8.3 短名和长文件名,STANDARD_INFORMATION 属性存储时间戳。

Everything 不通过 Win32 API(FindFirstFile)遍历,而是直接读取 $MFT 的原始字节流。这绕过了目录层级递归的开销——120 万文件如果用 FindFirstFile 递归,光目录项打开就要数分钟;读 MFT 只需要顺序 I/O 一遍。

NTFS MFT 到 Everything 索引的数据流

与 Windows Search 的延迟对比

我们在一台 i7-12700 + NVMe SSD、1,247,893 个文件的 Windows 11 工作站上做了对比测试。查询条件为 *.dll,每种工具冷启动后首次查询,重复 10 次取中位数。

Everything 中位数 3 ms;Windows 搜索(任务栏搜索框)中位数 4.2 秒——差距三个数量级。Agent Ransack 需要遍历目录树,850 ms;Locate32 维护独立数据库,首次索引后 1.2 秒。Everything 的优势在于索引来源是操作系统已有的 MFT,不需要自建数据库文件。

Everything 与 Windows Search 延迟对比

Everything Service 部署要点

默认安装后 Everything 以普通进程运行,关闭窗口即停止 USN 监听。生产环境建议:工具 → 选项 → 常规 → 勾选「Everything 服务」并安装服务。服务以 SYSTEM 权限运行,不受 UAC 和会话切换影响。

多用户终端服务器场景:每个用户会话可运行独立 UI 进程,共享同一个服务实例的索引。注意网络驱动器需要手动添加索引文件夹(工具 → 选项 → 索引 → 文件夹),并确认服务账户有访问权限。

Everything Service 运行日志
News

Everything 最新动态

版本发布、SDK 变更与社区讨论,详见 动态页

Everything 1.5.0.1392a Alpha 发布

64 位专用分支,重构索引引擎,新增 dark mode 和改进的 Unicode 路径处理。Alpha 通道不建议生产环境使用。

SDK 1.4.1 增加 IPC 超时配置

Everything_SetTimeout API 允许第三方集成自定义查询超时,解决大结果集场景下的 UI 冻结问题。

1.4.1.1026 修复 HTTP Server 路径遍历

CVE 相关补丁:HTTP Server 模式下恶意构造的 search 参数可能读取索引范围外的路径,此版本已封堵。

FAQ

常见问题

Everything 能搜文件内容吗?

默认不能。Everything 只索引文件名和路径。如需内容搜索,可配合 Agent Ransack 或在 Everything 结果上右键用关联程序打开后搜索。

为什么需要管理员权限?

读取 $MFT 和 USN Journal 需要 SeBackupPrivilege 或管理员权限。安装为服务后,UI 进程无需管理员即可查询。

支持 Linux/macOS 吗?

不支持。Everything 依赖 NTFS 特有结构,仅 Windows 可用。Linux 上类似思路的工具是 locate/plocate(updatedb 预建索引)。

和 Listary 有什么区别?

Listary 侧重「当前目录快速跳转 + 应用启动器」,Everything 是「全盘文件名搜索引擎」。很多用户两者同时安装:Listary 管日常导航,Everything 管全局定位。