尧图网站建设 
系列导航目录 | 1️⃣ 噩梦 | 2️⃣ FTS5 | 3️⃣ 并发 | 4️⃣ 降级 | 5️⃣ 生命周期 | 6️⃣ 基准 | 7️⃣ 禁止开场用数据库的方式思考搜索前面我们看到暴力遍历的灾难。现在问题是用什么来解决如果我告诉你改一个搜索层就能让速度提升71 倍你信不信这不是营销。这是真实的基准测试数据❌ 暴力遍历500ms 平均✅ SQLite FTS57ms 平均原理很简单。但实现背后的工程深度会改变你对搜索这件事的理解。FTS5 是什么超级直观的类比普通数据库索引就像书的目录目录 第 42 页 ← 我要找第 42 页的内容 按页码排序搜索时我要找getUser ↓ 翻目录页码检索→ 找到第 42 页 ↓ 直接跳到第 42 页 ✓ 秒级查询FTS5 索引就像书的单词索引单词索引 getUser → [页 12, 42, 88, 156] get → [页 5, 12, 20, 42, 88, ...] 按相关性排序搜索时我要找getUser函数 ↓ 查单词索引 → 直接得到所有包含getUser的位置 ↓ 按相关性排序 → 最像函数定义的排第一 ↓ 返回用户 ✓ 毫秒级关键差异特性普通索引FTS5工作原理按 ID/键排序倒排索引 相关性算法搜索速度快但有前提超快支持模糊否精确匹配是词干化、通配符支持短语否是智能排序否按键排序是BM25 算法FTS5 的三个超能力1️⃣ 倒排索引Inverted Index传统表结构CREATETABLEcode_symbols(idINTEGER,nameTEXT,fileTEXT,lineINTEGER);-- 内容 --id │ name │file│ line ───┼─────────────┼───────────┼──────1│ getUser │user.ts │422│ getConfig │ config.ts │153│ getUserId │user.ts │884│setUser│user.ts │120搜索getUserSELECT*FROMcode_symbolsWHEREnamegetUser扫描1 → 2 → 3 → 4 → 找到 1 ✓ (虽然快但要检查 4 行)FTS5 倒排索引构建时自动生成 词表 ──────────────→ 文档映射 getUser ────────→ [id: 1, 3] getConfig ──────→ [id: 2] getUserId ──────→ [id: 3] setUser ──────→ [id: 4] set ──────→ [id: 4] user ──────→ [id: 1, 3, 4]搜索getUserSELECT*FROMcode_indexWHEREcontentMATCHgetUserSQLite 内部查倒排表 → getUser 映射到 [1, 3] ↓ 无需扫描直接返回这两条记录 ✓关键优势不需遍历所有行词越罕见搜索越快getUser比user快支持组合查询“getUser AND config”2️⃣ BM25 相关性排序问题搜user返回了 50 个结果。但用户最想要哪个搜user返回 1. getUser() ← 精确名字包含 2. validateUserInput() ← 也包含user 3. processUserData() ← 也包含user 4. user authentication ← 在注释中 5. const u User; ← 相关但不是函数 用户想要的大概率是 getUser()暴力方案results.sort((a,b){// 按名字字母序按文件名按行号// 都不对...returna.name.localeCompare(b.name);});BM25 算法信息检索领域的标准score IDF(term) × (频率 × k₁1) / (频率 k₁ × (1-b b×len/avglen)) 其中 IDF log(总文档数 / 包含term的文档数) ← user很常用IDF 小 ← getUserIdFromDatabase罕见IDF 大 频率 term在文档中出现的次数 ← 出现 3 次 vs 出现 1 次 len / avglen 文档长度归一化 ← 长函数名不应该被过度奖励真实例子搜索user 1. getUser() ├─ IDF(user) log(1000/500) ≈ 0.30 ├─ 频率 1在函数名中出现一次 ├─ 长度 8 个字符短 └─ score 0.30 × (1×2) / (1 1.2×...) ≈ 0.48 2. validateUserInput() ├─ IDF(user) 0.30同上 ├─ 频率 1 ├─ 长度 18 个字符长 └─ score 0.30 × (1×2) / (1 1.2×(1-0.75 0.75×18/12)) ≈ 0.25被长度惩罚 3. user authentication (注释) ├─ 在代码中相关性低 └─ score 0.15 排序结果getUser (0.48) validateUserInput (0.25) comment (0.15)用户获得最想要的结果无需手动过滤✓3️⃣ 词干化和通配符词干化Stemming输入查询getUsers ↓ FTS5 tokenizer (Porter stemming) getUsers → get, user 倒排表 get → [1, 3, 5, 8] user → [1, 3, 4, 7] 结果匹配 getUser, getUsers, setUser, etc 一次搜索多个变体 ✓通配符MATCHbuild*-- 匹配 build, builder, buildingMATCH^build-- 匹配以 build 开头的MATCHbuild query-- 两个词都要包含短语从代码看差异暴力方案第 1 篇classNaiveSearcher{asyncsearch(query:string):PromiseResult[]{constresults[];for(constfileofthis.workspace.getAllFiles()){// ❌ 每次都读constcontentawaitfs.readFile(file.path);// ❌ 每次都解析constastParser.parse(content,file.language);// ❌ 每次都遍历traverse(ast,(node){if(node.typefunctionnode.namequery){results.push({file:file.path,line:node.line});}});}returnresults;}}// 时间 O(n * m * k)// n 文件数 (200)// m AST 节点平均数 (5000)// k 每个节点检查时间 (1μs)// 总计 ≈ 500msFTS5 方案这一篇classFTS5Searcher{asyncinitialize():Promisevoid{// 一次性建索引只做一次awaitthis.db.exec(CREATE VIRTUAL TABLE code_index USING fts5( id UNINDEXED, name, content, -- 代码片段用于全文搜索 file UNINDEXED, line UNINDEXED, type UNINDEXED -- function / class / type ));// 扫描工作区填充索引for(constfileofthis.workspace.getAllFiles()){constsymbolsawaitthis.extractSymbols(file);for(constsymofsymbols){// 一条 INSERTawaitthis.db.run(INSERT INTO code_index (name, content, file, line, type) VALUES (?, ?, ?, ?, ?),[sym.name,sym.code,file.path,sym.line,sym.type]);}}}asyncsearch(query:string):PromiseResult[]{// 搜索时直接查表constrowsawaitthis.db.all(SELECT rank, -- BM25 分数SQLite 自动计算 name, file, line FROM code_index WHERE content MATCH ? ORDER BY rank -- 按相关性排序 LIMIT 50,[query]);returnrows;}}// 时间 O(log n) O(k·r)// log n 倒排表查询// r 结果数量通常 50// 总计 ≈ 7ms代码的故事暴力搜索逻辑复杂嵌套循环FTS5搜索逻辑简单一条 SQL✓SQLite 在后台做了所有繁重工作。性能对比表按工作区规模规模符号数文件数暴力遍历FTS5加速倍数数据库大小小50050100ms2ms50x1.2 MB中5K200500ms7ms71x12 MB大10K4001300ms10ms130x28 MB超大50K20008000ms35ms230x150 MB内存占用规模暴力遍历FTS5 数据库节省5K 符号50 MB15 MB70% ✓10K 符号110 MB30 MB73% ✓50K 符号600 MB150 MB75% ✓结论不仅快 71 倍还省 70% 的内存。代价和权衡成本项目成本是否可接受首次构建5-21 秒一次性✅ 可以磁盘占用10-50 MB✅ 可以一个视频100 倍增量更新改 1 个文件 → 10ms✅ 可以准确度权衡FTS5 是文本匹配不是 AST 语义搜get会返回函数定义getUser() ✓ 真匹配 注释 // get the user object ~ 可能噪音 字符串 please get me coffee ~ 可能噪音 变量 const get_data ... ~ 边界情况准确度对比暴力 AST100% 准确但 500msFTS5 文本98% 准确但 7ms2% 的假阳性值得 71 倍的速度提升。而且还可以二次过滤实战从零到有初始化阶段首次启动# 用户打开 LoopAgentVSCode 扩展启动1. 检测 .loopagent 目录是否存在 ├─ 存在 → 使用现有索引 └─ 不存在 → 创建 构建2. 扫描工作区所有文件 └─ 提取符号函数、类、类型3. 填充 FTS5 索引 └─ INSERT 每个符号到 code_index 表4. 验证索引完整性 └─ 检查行数、计算校验和 ⏱️ 总时间首次5-21s取决于项目大小 后续启动直接加载现有数据库100ms编辑阶段用户改代码// VSCode 文件变化事件workspace.onDidChangeTextDocument(async(event){if(!isRelevantFile(event.document))return;// 后台异步更新索引不阻塞编辑queueUpdate(async(){// 1. 删除旧的此文件符号awaitdb.run(DELETE FROM code_index WHERE file ?,[event.document.uri.fsPath]);// 2. 提取新符号constsymbolsawaitextractSymbols(event.document);// 3. 插入新索引for(constsymofsymbols){awaitdb.run(INSERT INTO code_index (...) VALUES (...),[sym.name,sym.code,...]);}});});⏱️ 时间改一个文件 → 后台 10-50ms用户无感知搜索阶段用户搜代码// 用户在搜索框输入asyncfunctionsearch(query:string){// 就一条 SQLconstresultsawaitdb.all(SELECT * FROM code_index WHERE content MATCH ? ORDER BY rank LIMIT 50,[query]);returnresults;}⏱️ 时间 10ms用户体验秒杀。一个完整的数据流示例用户行动序列 t0.0s 打开项目 ├─ 检查 .loopagent/code-index.sqlite └─ 不存在 → 开始构建 t0.5s 扫描文件 ├─ 找到 200 个文件 ├─ 提取符号AST 解析 └─ 进度条████░░░░░ 50% t5.0s 索引构建完成 ├─ 共 5,243 个符号 ├─ 数据库大小12.4 MB └─ 准备就绪 ✓ t5.5s 用户在搜索框输入 get ├─ 倒排表查询 ├─ BM25 排序 └─ 返回 [getUser, getUserId, getConfig, ...] 用户感受闪现10ms t6.0s 用户修改 user.ts ├─ VSCode 检测变化 ├─ 后台队列DELETE INSERT └─ 用户继续输入无感知 t7.0s 用户再次搜getUser ├─ 查询最新索引 ├─ 返回更新后的符号 └─ 1000% 准确 ✓为什么不用其他方案LuceneLucene是 Java 的企业级全文搜索库功能更强大。开销加 20 MB 依赖学习曲线陡VSCode 扩展环境不友好Electron 中无 JVMSQLite FTS5内置、轻量、够用。ElasticsearchElasticsearch是分布式搜索引擎支持集群。开销后台服务、网络通信适用场景多机、多用户协作对 IDE 来说杀鸡用牛刀SQLite单机、嵌入式、完美。其他搜索库大多数都涉及更多依赖、更复杂的 API、更多的维护成本。SQLite FTS5 是特定问题代码搜索在 IDE的最佳方案。下一篇预告现在我们知道 FTS5 有多快了。但有一个复杂的问题如果用户同时打开两个 VSCode 窗口都在编辑同一个项目SQLite 该怎么协调一个窗口在写索引另一个在搜索。会不会冲突会不会崩溃答案Writer/Reader 架构优雅降级。下一篇会讲并发控制如何避免数据竞态以及当 SQLite 不可用时怎么办。 第 2 篇：「从 500ms 到 7ms」— SQLite FTS5 的魔法
系列导航目录 | 1️⃣ 噩梦 | 2️⃣ FTS5 | 3️⃣ 并发 | 4️⃣ 降级 | 5️⃣ 生命周期 | 6️⃣ 基准 | 7️⃣ 禁止开场用数据库的方式思考搜索前面我们看到暴力遍历的灾难。现在问题是用什么来解决如果我告诉你改一个搜索层就能让速度提升71 倍你信不信这不是营销。这是真实的基准测试数据❌ 暴力遍历500ms 平均✅ SQLite FTS57ms 平均原理很简单。但实现背后的工程深度会改变你对搜索这件事的理解。FTS5 是什么超级直观的类比普通数据库索引就像书的目录目录 第 42 页 ← 我要找第 42 页的内容 按页码排序搜索时我要找getUser ↓ 翻目录页码检索→ 找到第 42 页 ↓ 直接跳到第 42 页 ✓ 秒级查询FTS5 索引就像书的单词索引单词索引 getUser → [页 12, 42, 88, 156] get → [页 5, 12, 20, 42, 88, ...] 按相关性排序搜索时我要找getUser函数 ↓ 查单词索引 → 直接得到所有包含getUser的位置 ↓ 按相关性排序 → 最像函数定义的排第一 ↓ 返回用户 ✓ 毫秒级关键差异特性普通索引FTS5工作原理按 ID/键排序倒排索引 相关性算法搜索速度快但有前提超快支持模糊否精确匹配是词干化、通配符支持短语否是智能排序否按键排序是BM25 算法FTS5 的三个超能力1️⃣ 倒排索引Inverted Index传统表结构CREATETABLEcode_symbols(idINTEGER,nameTEXT,fileTEXT,lineINTEGER);-- 内容 --id │ name │file│ line ───┼─────────────┼───────────┼──────1│ getUser │user.ts │422│ getConfig │ config.ts │153│ getUserId │user.ts │884│setUser│user.ts │120搜索getUserSELECT*FROMcode_symbolsWHEREnamegetUser扫描1 → 2 → 3 → 4 → 找到 1 ✓ (虽然快但要检查 4 行)FTS5 倒排索引构建时自动生成 词表 ──────────────→ 文档映射 getUser ────────→ [id: 1, 3] getConfig ──────→ [id: 2] getUserId ──────→ [id: 3] setUser ──────→ [id: 4] set ──────→ [id: 4] user ──────→ [id: 1, 3, 4]搜索getUserSELECT*FROMcode_indexWHEREcontentMATCHgetUserSQLite 内部查倒排表 → getUser 映射到 [1, 3] ↓ 无需扫描直接返回这两条记录 ✓关键优势不需遍历所有行词越罕见搜索越快getUser比user快支持组合查询“getUser AND config”2️⃣ BM25 相关性排序问题搜user返回了 50 个结果。但用户最想要哪个搜user返回 1. getUser() ← 精确名字包含 2. validateUserInput() ← 也包含user 3. processUserData() ← 也包含user 4. user authentication ← 在注释中 5. const u User; ← 相关但不是函数 用户想要的大概率是 getUser()暴力方案results.sort((a,b){// 按名字字母序按文件名按行号// 都不对...returna.name.localeCompare(b.name);});BM25 算法信息检索领域的标准score IDF(term) × (频率 × k₁1) / (频率 k₁ × (1-b b×len/avglen)) 其中 IDF log(总文档数 / 包含term的文档数) ← user很常用IDF 小 ← getUserIdFromDatabase罕见IDF 大 频率 term在文档中出现的次数 ← 出现 3 次 vs 出现 1 次 len / avglen 文档长度归一化 ← 长函数名不应该被过度奖励真实例子搜索user 1. getUser() ├─ IDF(user) log(1000/500) ≈ 0.30 ├─ 频率 1在函数名中出现一次 ├─ 长度 8 个字符短 └─ score 0.30 × (1×2) / (1 1.2×...) ≈ 0.48 2. validateUserInput() ├─ IDF(user) 0.30同上 ├─ 频率 1 ├─ 长度 18 个字符长 └─ score 0.30 × (1×2) / (1 1.2×(1-0.75 0.75×18/12)) ≈ 0.25被长度惩罚 3. user authentication (注释) ├─ 在代码中相关性低 └─ score 0.15 排序结果getUser (0.48) validateUserInput (0.25) comment (0.15)用户获得最想要的结果无需手动过滤✓3️⃣ 词干化和通配符词干化Stemming输入查询getUsers ↓ FTS5 tokenizer (Porter stemming) getUsers → get, user 倒排表 get → [1, 3, 5, 8] user → [1, 3, 4, 7] 结果匹配 getUser, getUsers, setUser, etc 一次搜索多个变体 ✓通配符MATCHbuild*-- 匹配 build, builder, buildingMATCH^build-- 匹配以 build 开头的MATCHbuild query-- 两个词都要包含短语从代码看差异暴力方案第 1 篇classNaiveSearcher{asyncsearch(query:string):PromiseResult[]{constresults[];for(constfileofthis.workspace.getAllFiles()){// ❌ 每次都读constcontentawaitfs.readFile(file.path);// ❌ 每次都解析constastParser.parse(content,file.language);// ❌ 每次都遍历traverse(ast,(node){if(node.typefunctionnode.namequery){results.push({file:file.path,line:node.line});}});}returnresults;}}// 时间 O(n * m * k)// n 文件数 (200)// m AST 节点平均数 (5000)// k 每个节点检查时间 (1μs)// 总计 ≈ 500msFTS5 方案这一篇classFTS5Searcher{asyncinitialize():Promisevoid{// 一次性建索引只做一次awaitthis.db.exec(CREATE VIRTUAL TABLE code_index USING fts5( id UNINDEXED, name, content, -- 代码片段用于全文搜索 file UNINDEXED, line UNINDEXED, type UNINDEXED -- function / class / type ));// 扫描工作区填充索引for(constfileofthis.workspace.getAllFiles()){constsymbolsawaitthis.extractSymbols(file);for(constsymofsymbols){// 一条 INSERTawaitthis.db.run(INSERT INTO code_index (name, content, file, line, type) VALUES (?, ?, ?, ?, ?),[sym.name,sym.code,file.path,sym.line,sym.type]);}}}asyncsearch(query:string):PromiseResult[]{// 搜索时直接查表constrowsawaitthis.db.all(SELECT rank, -- BM25 分数SQLite 自动计算 name, file, line FROM code_index WHERE content MATCH ? ORDER BY rank -- 按相关性排序 LIMIT 50,[query]);returnrows;}}// 时间 O(log n) O(k·r)// log n 倒排表查询// r 结果数量通常 50// 总计 ≈ 7ms代码的故事暴力搜索逻辑复杂嵌套循环FTS5搜索逻辑简单一条 SQL✓SQLite 在后台做了所有繁重工作。性能对比表按工作区规模规模符号数文件数暴力遍历FTS5加速倍数数据库大小小50050100ms2ms50x1.2 MB中5K200500ms7ms71x12 MB大10K4001300ms10ms130x28 MB超大50K20008000ms35ms230x150 MB内存占用规模暴力遍历FTS5 数据库节省5K 符号50 MB15 MB70% ✓10K 符号110 MB30 MB73% ✓50K 符号600 MB150 MB75% ✓结论不仅快 71 倍还省 70% 的内存。代价和权衡成本项目成本是否可接受首次构建5-21 秒一次性✅ 可以磁盘占用10-50 MB✅ 可以一个视频100 倍增量更新改 1 个文件 → 10ms✅ 可以准确度权衡FTS5 是文本匹配不是 AST 语义搜get会返回函数定义getUser() ✓ 真匹配 注释 // get the user object ~ 可能噪音 字符串 please get me coffee ~ 可能噪音 变量 const get_data ... ~ 边界情况准确度对比暴力 AST100% 准确但 500msFTS5 文本98% 准确但 7ms2% 的假阳性值得 71 倍的速度提升。而且还可以二次过滤实战从零到有初始化阶段首次启动# 用户打开 LoopAgentVSCode 扩展启动1. 检测 .loopagent 目录是否存在 ├─ 存在 → 使用现有索引 └─ 不存在 → 创建 构建2. 扫描工作区所有文件 └─ 提取符号函数、类、类型3. 填充 FTS5 索引 └─ INSERT 每个符号到 code_index 表4. 验证索引完整性 └─ 检查行数、计算校验和 ⏱️ 总时间首次5-21s取决于项目大小 后续启动直接加载现有数据库100ms编辑阶段用户改代码// VSCode 文件变化事件workspace.onDidChangeTextDocument(async(event){if(!isRelevantFile(event.document))return;// 后台异步更新索引不阻塞编辑queueUpdate(async(){// 1. 删除旧的此文件符号awaitdb.run(DELETE FROM code_index WHERE file ?,[event.document.uri.fsPath]);// 2. 提取新符号constsymbolsawaitextractSymbols(event.document);// 3. 插入新索引for(constsymofsymbols){awaitdb.run(INSERT INTO code_index (...) VALUES (...),[sym.name,sym.code,...]);}});});⏱️ 时间改一个文件 → 后台 10-50ms用户无感知搜索阶段用户搜代码// 用户在搜索框输入asyncfunctionsearch(query:string){// 就一条 SQLconstresultsawaitdb.all(SELECT * FROM code_index WHERE content MATCH ? ORDER BY rank LIMIT 50,[query]);returnresults;}⏱️ 时间 10ms用户体验秒杀。一个完整的数据流示例用户行动序列 t0.0s 打开项目 ├─ 检查 .loopagent/code-index.sqlite └─ 不存在 → 开始构建 t0.5s 扫描文件 ├─ 找到 200 个文件 ├─ 提取符号AST 解析 └─ 进度条████░░░░░ 50% t5.0s 索引构建完成 ├─ 共 5,243 个符号 ├─ 数据库大小12.4 MB └─ 准备就绪 ✓ t5.5s 用户在搜索框输入 get ├─ 倒排表查询 ├─ BM25 排序 └─ 返回 [getUser, getUserId, getConfig, ...] 用户感受闪现10ms t6.0s 用户修改 user.ts ├─ VSCode 检测变化 ├─ 后台队列DELETE INSERT └─ 用户继续输入无感知 t7.0s 用户再次搜getUser ├─ 查询最新索引 ├─ 返回更新后的符号 └─ 1000% 准确 ✓为什么不用其他方案LuceneLucene是 Java 的企业级全文搜索库功能更强大。开销加 20 MB 依赖学习曲线陡VSCode 扩展环境不友好Electron 中无 JVMSQLite FTS5内置、轻量、够用。ElasticsearchElasticsearch是分布式搜索引擎支持集群。开销后台服务、网络通信适用场景多机、多用户协作对 IDE 来说杀鸡用牛刀SQLite单机、嵌入式、完美。其他搜索库大多数都涉及更多依赖、更复杂的 API、更多的维护成本。SQLite FTS5 是特定问题代码搜索在 IDE的最佳方案。下一篇预告现在我们知道 FTS5 有多快了。但有一个复杂的问题如果用户同时打开两个 VSCode 窗口都在编辑同一个项目SQLite 该怎么协调一个窗口在写索引另一个在搜索。会不会冲突会不会崩溃答案Writer/Reader 架构优雅降级。下一篇会讲并发控制如何避免数据竞态以及当 SQLite 不可用时怎么办。