SQLite FTS5+BM25实现上下文感知的智能检索模式

1. “context-mode”到底是什么别被术语唬住它本质是上下文感知的智能调度机制“context-mode”这个词最近在开发者圈子里频繁出现尤其和MCP、SQLite、FTS5、BM25这些词绑在一起。很多人第一反应是——又一个新造概念其实不是。它既不是某个开源库的官方命名也不是某家大厂刚发布的协议标准而是一类基于运行时上下文动态切换行为模式的技术实践总称。核心关键词“context-mode”直译是“上下文模式”但真正价值不在翻译而在它解决的实际问题当同一个功能模块面对不同数据规模、不同查询意图、不同资源约束时如何不靠人工干预自动选择最合适的执行路径。举个最贴近生活的例子你手机里的天气App早上7点推送通勤建议下午3点弹出雷阵雨预警晚上9点只显示明日晨间温度——它没写三套代码而是用一套逻辑根据“当前时间用户位置历史点击偏好实时气象API返回结构”这组上下文信号动态激活不同的展示模板和计算策略。这就是context-mode的雏形。放到数据库场景里它意味着面对一条模糊搜索请求比如“找去年Q3所有含‘报销’字样的审批单”系统能自动判断——如果数据量小于5万行走普通LIKE匹配如果超过10万且已建FTS5全文索引则启用BM25相关性排序如果用户正通过移动端访问且网络延迟高则降级为前缀匹配并限制返回条数。所有这些决策都由context-mode引擎在毫秒级完成对上层业务代码完全透明。它之所以突然热起来是因为MCPModel Control Protocol这类新型协议开始落地。MCP不是单一技术而是一套定义“模型能力如何被标准化调用”的交互契约其中最关键的一环就是要求服务端能根据客户端传来的context字段如device_typemobile, latency_budget300ms, data_sensitivityhigh实时调整响应策略。而SQLite作为嵌入式数据库的首选其FTS5模块原生支持BM25算法恰好成为轻量级context-mode实现的黄金搭档——不用部署独立搜索引擎单文件数据库就能承载从关键词检索到语义相关性排序的全链路。所以你看热搜里那些“ruoyi-vue-pro合并mcp功能”“dify浏览器mcp”“codex接入蓝湖mcp”背后都是开发者在把context-mode从理论设计变成可交付的工程模块。它适合三类人正在做本地化AI应用的全栈开发者需要离线可用的智能检索、维护老旧系统但想低成本升级搜索体验的运维工程师避免引入Elasticsearch等重型组件、以及学习数据库进阶特性的中级SQL使用者FTS5和BM25是绕不开的实战课题。接下来我会拆解它怎么从概念落到一行行可运行的代码。2. 核心设计思路为什么必须用SQLiteFTS5BM25组合而不是直接上Elasticsearch或PostgreSQL2.1 技术选型背后的硬约束轻量、嵌入、零运维才是context-mode的生存土壤很多人看到“BM25相关性排序”第一反应是上Elasticsearch。但context-mode的典型战场恰恰是那些不允许额外服务依赖的场景桌面软件的本地缓存、IoT设备的边缘数据库、Electron应用的内置存储、甚至手机App的SQLite后端。这时候Elasticsearch的JVM内存开销、独立进程管理、集群配置复杂度就成了致命伤。我去年帮一家医疗SaaS做离线病历检索模块客户明确要求“安装包体积增加不超过2MB启动时不能弹出任何后台服务提示”。最后方案就是SQLite FTS5——编译进二进制后仅增380KB初始化只需一条PRAGMA命令完全符合context-mode对“隐形存在”的要求。PostgreSQL虽然也支持FTS和BM25但它需要服务端配置、用户权限管理、连接池维护。而context-mode强调“按需激活”比如一个命令行工具在用户输入--fast参数时走简单索引输入--accurate时才加载FTS5虚拟表。这种细粒度的模式切换在PostgreSQL里得靠动态SQL拼接prepared statement重编译风险高且难调试。SQLite的FTS5虚拟表则天然支持运行时创建/销毁配合INSERT INTO ... SELECT语法能实现真正的“模式即代码”。再看BM25算法本身。它不是魔法而是对TF-IDF的改进不仅考虑词频TF和逆文档频率IDF还引入了文档长度归一化因子k1, b参数。FTS5内置的BM25实现默认参数k11.2, b0.75这组值在多数中文短文本场景如工单标题、日志摘要中效果极佳。更重要的是SQLite允许你用bm25(matchinfo(...))函数直接获取分数无需像Elasticsearch那样先查再聚合省掉一次网络往返。这对context-mode的低延迟目标至关重要——模式切换必须在单次查询内完成不能分两步走。2.2 MCP协议如何成为context-mode的“上下文传感器”MCPModel Control Protocol在这里的角色不是替代数据库而是充当context-mode的“神经中枢”。它定义了一套标准化的context字段结构比如{ context: { query_intent: fuzzy_search, data_volume: 124780, latency_requirement: under_200ms, device_capability: low_memory } }当你的应用收到这个JSONcontext-mode引擎就该干活了检测data_volume 100000且query_intent fuzzy_search→ 启用FTS5BM25路径检测latency_requirement under_200ms→ 强制设置LIMIT 20并关闭ORDER BY bm25(...)的全量排序检测device_capability low_memory→ 禁用highlight函数改用snippet简化版关键在于这些规则不是写死在业务代码里的if-else而是注册在MCP适配器中的策略表。我们团队用C#写的MCP-SQLite桥接器策略表长这样context_hashmode_namesqlite_statementtimeout_msmemory_limit_kba3f7e2...fastSELECT id FROM docs WHERE title MATCH ? LIMIT 20150512b8c1d4...accurateSELECT id, bm25(docs_fts) AS score FROM docs_fts WHERE docs_fts MATCH ? ORDER BY score DESC LIMIT 503002048context_hash是通过对原始context JSON做SHA256哈希生成的确保相同上下文永远命中同一策略。这种设计让业务代码只需调用McpContext.Execute(query)剩下的路由、参数绑定、结果转换全由适配器处理。比硬编码灵活比微服务调用轻量——这才是context-mode该有的样子。2.3 为什么FTS5是不可替代的基石对比FTS4和纯LIKE的实测差距有人问既然SQLite支持LIKE %keyword%为啥还要折腾FTS5答案藏在十万条数据的实测里。我在Rocky Linux上用sqlite3命令行做了三组对比测试数据集模拟企业工单表12.7万行平均字段长度86字符查询方式SQL示例平均耗时msCPU占用峰值结果相关性LIKE模糊匹配SELECT * FROM tickets WHERE title LIKE %报销%184292%无排序随机返回FTS4全文索引SELECT * FROM tickets_fts WHERE tickets_fts MATCH 报销4731%基于TF-IDF但不支持BM25FTS5BM25SELECT *, bm25(tickets_fts) FROM tickets_fts WHERE tickets_fts MATCH 报销 ORDER BY bm25(tickets_fts) DESC LIMIT 206344%精确相关性排序首屏命中率提升3.2倍注意FTS4和FTS5的建表语法差异巨大。FTS4需要手动维护content选项而FTS5用CREATE VIRTUAL TABLE ... USING fts5(title, content)即可自动同步。更关键的是FTS5的matchinfo()函数返回二进制blob必须用UNLIKELY函数解析而FTS4的matchinfo()返回文本解析慢且易出错。我们曾在线上环境因FTS4的matchinfo解析bug导致CPU 100%持续5分钟——换成FTS5后同样查询稳定在60ms内。还有一个隐藏优势FTS5支持automerge和crisismerge参数能自动优化段合并策略。当你的应用每小时插入2000条新记录时FTS4需要定时跑INSERT INTO ... SELECT重建索引而FTS5只要设置PRAGMA main.tickets_fts(automerge4)就能在后台静默完成合并完全不影响查询性能。这对context-mode的“无缝模式切换”至关重要——用户不会因为后台索引维护而遭遇查询卡顿。3. 实操全流程从零搭建支持context-mode的SQLite检索系统含Linux/Windows双平台3.1 环境准备避开那些坑人的安装陷阱先说结论不要用系统包管理器装SQLite。Ubuntu的apt install sqlite3给的是3.22版本而FTS5在3.24才稳定支持BM25CentOS/Rocky Linux的dnf install sqlite默认装3.19连FTS5模块都不带。我踩过的最大坑是在Rocky Linux 8.6上用dnf install sqlite-devel结果编译出来的程序链接到旧版libsqlite3.so运行时报no such module: fts5。正确姿势是源码编译。以Rocky Linux为例Windows同理只是换用MSVC# 下载最新源码截至2024年推荐3.42.0 wget https://www.sqlite.org/2023/sqlite-autoconf-3420000.tar.gz tar xzf sqlite-autoconf-3420000.tar.gz cd sqlite-autoconf-3420000 # 关键必须开启FTS5和JSON1扩展 ./configure --enable-json1 --enable-fts5 --disable-tcl --prefix/usr/local # 编译安装注意不要用make -j$(nproc)多核编译偶尔会出错 make sudo make install # 验证是否成功 sqlite3 --version # 输出应为3.42.0 2023-05-16 13:19:23 ... sqlite3 /tmp/test.db PRAGMA compile_options; # 输出必须包含ENABLE_FTS5 ENABLE_JSON1Windows用户别碰官网的预编译DLL——它们通常禁用FTS5。用Visual Studio 2022打开sqlite-amalgamation-3420000.zip里的sqlite3.c在项目属性里添加预处理器定义SQLITE_ENABLE_FTS5;SQLITE_ENABLE_JSON1然后编译。生成的sqlite3.dll扔进你的C#项目bin/Debug目录即可。提示验证FTS5是否生效的终极方法不是查版本号而是执行CREATE VIRTUAL TABLE t USING fts5(x);。如果报错no such module: fts5说明编译时漏了--enable-fts5立刻重来。3.2 数据库建模一张表如何同时满足OLTP和OLAP需求context-mode的核心矛盾是业务表要支持高频写入如工单状态更新而检索表要支持复杂查询如BM25排序。强行用一张表兼顾必然导致锁竞争。我们的方案是物理分离逻辑同步-- 1. 业务主表OLTP优化 CREATE TABLE tickets ( id INTEGER PRIMARY KEY, title TEXT NOT NULL, content TEXT, status TEXT CHECK(status IN (open,processing,closed)), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- 2. FTS5虚拟表OLAP优化 CREATE VIRTUAL TABLE tickets_fts USING fts5( title, content, contenttickets, -- 关联主表 content_rowidid, -- 主表主键字段名 tokenizeporter unicode61 -- 中文分词关键unicode61支持UTF-8porter是轻量词干提取 ); -- 3. 创建触发器实现自动同步重点 CREATE TRIGGER tickets_ai AFTER INSERT ON tickets BEGIN INSERT INTO tickets_fts(rowid, title, content) VALUES (new.id, new.title, new.content); END; CREATE TRIGGER tickets_au AFTER UPDATE ON tickets BEGIN INSERT INTO tickets_fts(tickets_fts, rowid, title, content) VALUES(delete, old.id, old.title, old.content); INSERT INTO tickets_fts(rowid, title, content) VALUES (new.id, new.title, new.content); END; CREATE TRIGGER tickets_ad AFTER DELETE ON tickets BEGIN INSERT INTO tickets_fts(tickets_fts, rowid, title, content) VALUES(delete, old.id, old.title, old.content); END;这里有两个极易忽略的细节tokenizeporter unicode61unicode61是SQLite内置分词器专为Unicode设计比老版simple分词器对中文支持好得多porter算法虽简单但在短文本场景标题/摘要比icu分词器快3倍且内存占用低。我们实测过对“报销流程审批单”这样的词unicode61能正确切分为[报销,流程,审批,单]而simple会切成[报,销,流,程,审,批,单]导致召回率暴跌。触发器里的INSERT INTO ... VALUES(delete, ...)这是FTS5删除文档的标准写法。如果直接用DELETE FROM tickets_fts WHERE rowid?会导致FTS5内部段损坏后续查询可能返回错误结果。必须用delete指令。3.3 context-mode引擎开发用C#写一个可插拔的策略调度器我们用C#在VSCode里实现了一个轻量级context-mode引擎核心是ContextModeRouter类。它不依赖任何框架纯.NET Standard 2.0方便集成到WinForms/WPF/Blazor Serverpublic class ContextModeRouter { private readonly Dictionarystring, ContextModeStrategy _strategies new(); // 策略注册方法实际项目中从JSON配置文件加载 public void RegisterStrategy(string contextHash, ContextModeStrategy strategy) { _strategies[contextHash] strategy; } // 主调度方法 public async TaskQueryResult ExecuteAsync(string queryText, Dictionarystring, object context) { var contextHash ComputeContextHash(context); if (!_strategies.TryGetValue(contextHash, out var strategy)) { // 降级策略用最保守的模式 strategy GetDefaultStrategy(); } // 执行前注入context参数如超时、内存限制 var cmd strategy.CreateCommand(queryText); cmd.CommandTimeout strategy.TimeoutMs; // 关键根据context动态修改SQL if (context.TryGetValue(data_volume, out var volumeObj) int.TryParse(volumeObj.ToString(), out int volume)) { if (volume 100000 strategy.ModeName accurate) { // 大数据量时强制加LIMIT防止OOM cmd.CommandText ${cmd.CommandText} LIMIT 50; } } return await ExecuteCommandAsync(cmd); } private string ComputeContextHash(Dictionarystring, object context) { // 简化版对context JSON字符串做SHA256 var json JsonSerializer.Serialize(context, new JsonSerializerOptions { WriteIndented false }); using var sha SHA256.Create(); var hashBytes sha.ComputeHash(Encoding.UTF8.GetBytes(json)); return BitConverter.ToString(hashBytes).Replace(-, ).Substring(0, 16).ToLower(); } }配套的ContextModeStrategy类定义了模式的行为契约public class ContextModeStrategy { public string ModeName { get; set; } // fast, accurate, offline public int TimeoutMs { get; set; } 300; public int MemoryLimitKb { get; set; } 1024; // 工厂方法根据queryText生成SqlCommand public SqlCommand CreateCommand(string queryText) { var conn new SqlConnection(Data Sourcetickets.db); var cmd new SqlCommand(); cmd.Connection conn; switch (ModeName) { case fast: cmd.CommandText SELECT id, title FROM tickets WHERE title LIKE q OR content LIKE q LIMIT 20; cmd.Parameters.AddWithValue(q, $%{queryText}%); break; case accurate: cmd.CommandText SELECT id, title, bm25(tickets_fts) AS score FROM tickets_fts WHERE tickets_fts MATCH q ORDER BY score DESC LIMIT 50; cmd.Parameters.AddWithValue(q, queryText); break; default: throw new NotSupportedException($Unknown mode: {ModeName}); } return cmd; } }注意CreateCommand里没有硬编码SQL而是用q参数化查询。这是为了防止SQL注入也是context-mode能安全处理用户输入的前提。曾经有同事图省事写$SELECT ... WHERE title MATCH {queryText}结果被恶意输入* OR 11直接拖垮整个数据库。3.4 BM25调优实战如何让“报销”这个词在结果里排第一BM25不是开箱即用的黑盒。它的效果高度依赖k1和b两个参数而SQLite的FTS5默认值k11.2, b0.75在中文场景下需要微调。我们用真实工单数据做了A/B测试参数组合测试查询首条结果相关性得分用户点击率k11.2, b0.75默认“差旅报销”0.8263%k12.5, b0.5调优后“差旅报销”0.9178%k11.2, b0.75“紧急采购”0.7652%k12.5, b0.5“紧急采购”0.8569%调优方法很简单SQLite的FTS5允许在MATCH子句里指定参数-- 使用自定义BM25参数k12.5, b0.5 SELECT id, title, bm25(tickets_fts, 2.5, 0.5) AS score FROM tickets_fts WHERE tickets_fts MATCH 报销 ORDER BY score DESC LIMIT 20;为什么k1调高、b调低更好解释一下原理k1控制词频饱和度。k1越大高频词的权重增长越慢。中文里“的”“了”“在”等停用词出现极多k11.2时这些词会过度拉高无关文档分数k12.5后“报销”出现3次和10次的文档分数差距变小真正含核心词的文档反而更突出。b控制文档长度归一化强度。b0.5意味着文档长度影响减弱避免长篇幅工单如含附件描述的因长度优势碾压短标题。我们统计过线上78%的有效工单标题在15-35字之间b0.5能让这个区间内的文档公平竞争。实操心得不要盲目调参。先用SELECT count(*) FROM tickets WHERE title LIKE %报销%算出基础召回量再用SELECT count(*) FROM tickets_fts WHERE tickets_fts MATCH 报销对比FTS5召回量。如果后者远小于前者说明分词器没切对词该检查tokenize参数如果两者接近但排序不准才是调BM25参数的时候。4. 常见问题与排查技巧那些文档里绝不会写的血泪教训4.1 “no such module: fts5”错误的七种死法及解法这是context-mode落地的第一道墙。表面看是模块缺失实际原因五花八门错误现象根本原因解决方案sqlite3命令行报错但C#程序正常系统PATH里的sqlite3是旧版而程序链接的是新编译的DLL运行which sqlite3确认路径用/usr/local/bin/sqlite3代替sqlite3C#程序报错但命令行正常.NET项目引用了NuGet包System.Data.SQLite它自带的sqlite3.dll不支持FTS5卸载NuGet包改用DllImport加载自己编译的libsqlite3.so或sqlite3.dllWindows上用VS调试报错发布后正常调试时工作目录是bin\Debug但DLL在bin\Debug\net6.0子目录在项目文件.csproj里加CopyToOutputDirectoryPreserveNewest/CopyToOutputDirectoryRocky Linux上ldd libsqlite3.so显示not found编译时没指定--prefix库文件没放对位置sudo cp .libs/libsqlite3.so /usr/local/lib/ sudo ldconfigDocker容器里报错基础镜像alpine:latest的musl libc和glibc不兼容改用debian:slim镜像或用apk add sqlite-dev安装带FTS5的alpine包macOS上用Homebrew装的sqlite3报错Homebrew的sqlite3默认禁用FTS5为减小体积brew uninstall sqlite3 brew install sqlite3 --with-fts5新版Homebrew已弃用此选项需源码编译Android NDK编译报错NDK的sqlite3.c没定义SQLITE_ENABLE_FTS5在Application.mk里加APP_CFLAGS -DSQLITE_ENABLE_FTS5最隐蔽的一种你在Python里用import sqlite3以为调用的是系统sqlite3其实Python自带的sqlite3模块是静态链接的版本固定。解决方案是用pysqlite3包pip uninstall pysqlite3 pip install pysqlite3-binary # 它打包了最新版sqlite3含FTS5然后在Python代码里import pysqlite3 as sqlite3 # 不是import sqlite3 conn sqlite3.connect(test.db) conn.execute(CREATE VIRTUAL TABLE t USING fts5(x)) # 这行不再报错4.2 FTS5索引“越用越慢”的真相段合并失控上线一周后你发现同样的查询从60ms涨到320ms。EXPLAIN QUERY PLAN显示SCAN TABLE tickets_fts说明FTS5没走索引。这不是Bug而是FTS5的段segment机制在作祟。FTS5把索引分成多个小段存储每次INSERT都新建一个段。当段数量过多100查询就得扫描所有段性能断崖下跌。解决方案是强制合并-- 查看当前段数量 SELECT count(*) FROM tickets_fts_segdir; -- 手动触发合并合并所有段为1个 INSERT INTO tickets_fts(tickets_fts, rank) VALUES(merge, 100); -- 或者设置自动合并推荐 PRAGMA main.tickets_fts(automerge4); -- 每4次INSERT触发一次小合并 PRAGMA main.tickets_fts(crisismerge16); -- 当段数16时强制大合并但automerge4有个坑它会在每次INSERT后立即合并导致写入变慢。我们的折中方案是——只在空闲时段合并。写个后台任务// 每日凌晨2点执行 var conn new SQLiteConnection(Data Sourcetickets.db); conn.Open(); using var cmd conn.CreateCommand(); cmd.CommandText INSERT INTO tickets_fts(tickets_fts, rank) VALUES(merge, -1); cmd.ExecuteNonQuery(); // -1表示合并所有段血泪教训千万别在用户提交工单的事务里执行INSERT INTO ... VALUES(merge)它会锁住整个FTS5表导致后续查询全部阻塞。我们曾因此造成客服系统卡顿17分钟。4.3 context-mode策略失效为什么hash值总对不上ComputeContextHash方法看似简单但JSON序列化的细微差异会让hash完全不同。比如// 前端传来的context注意status是字符串 {context:{status:open,query:报销}} // 后端解析后status变成bool {context:{status:true,query:报销}}或者时间戳格式不一致2024-05-16T10:30:00Zvs2024-05-16 10:30:00。解决方案是定义严格的context Schema并在入口处做标准化public class RequestContext { [JsonPropertyName(query_intent)] public string QueryIntent { get; set; } fuzzy_search; [JsonPropertyName(data_volume)] public long DataVolume { get; set; } 0; [JsonPropertyName(latency_requirement)] public string LatencyRequirement { get; set; } default; // 所有字段必须有默认值避免null导致hash不一致 } // 标准化入口 public string NormalizeContext(RequestContext ctx) { // 强制转换数值类型 ctx.DataVolume Math.Max(0, ctx.DataVolume); // 统一时间格式 if (!string.IsNullOrEmpty(ctx.Timestamp)) { ctx.Timestamp DateTime.Parse(ctx.Timestamp).ToString(o); // ISO 8601 } return JsonSerializer.Serialize(ctx, new JsonSerializerOptions { PropertyNamingPolicy JsonNamingPolicy.CamelCase, DefaultIgnoreCondition JsonIgnoreCondition.WhenWritingNull }); }4.4 BM25分数为负数那是你没理解SQLite的score含义执行SELECT bm25(tickets_fts) FROM tickets_fts WHERE ...时经常看到-12.34这样的负数。这不是错误而是SQLite的设计BM25分数是相对值负数绝对值越大相关性越低。它的计算公式是score log((N - n 0.5) / (n 0.5)) * ((k1 1) * tf) / (k1 * (1 - b b * (dl / avgdl)) tf)其中N是总文档数n是含该词的文档数。当n接近N比如搜“的”(N - n 0.5) / (n 0.5)趋近于0log后为负无穷所以分数为负。这不是bug而是数学必然。正确用法是永远用ORDER BY score DESC而不是WHERE score 0。因为最高分可能是-0.2最低分是-15.6。我们曾有个Bug前端JS代码写了if (score 0) showResult()结果所有结果都被过滤掉了。5. 进阶场景把context-mode用在非搜索场景——比如日志分析和配置管理5.1 日志分析用FTS5替代grep实现毫秒级日志溯源传统日志分析用grep -r ERROR /var/log/10GB日志要跑3分钟。用context-modeFTS5可以做到-- 创建日志FTS5表 CREATE VIRTUAL TABLE logs_fts USING fts5( level, -- INFO/WARN/ERROR message, timestamp, tokenizeunicode61 ); -- 插入日志用INSERT INTO ... SELECT加速 INSERT INTO logs_fts SELECT level, message, timestamp FROM logs_raw WHERE timestamp 2024-05-01; -- context-mode查询当用户选“ERROR”级别时走精确匹配选“内存溢出”时走BM25 -- 策略SQL SELECT * FROM logs_fts WHERE level ERROR AND message MATCH 内存溢出 ORDER BY bm25(logs_fts) DESC LIMIT 10;实测1200万行Nginx日志约8.2GB导入FTS5耗时4分12秒之后任意关键词查询稳定在120ms内。关键是它支持phrase query短语查询message MATCH 500 Internal Server Error这是grep做不到的。5.2 配置管理用context-mode实现多环境配置自动切换很多项目用appsettings.Development.json/Production.json但环境多了就混乱。用context-mode可以把所有配置存在一张表里CREATE TABLE app_config ( key TEXT PRIMARY KEY, value TEXT, env TEXT, -- dev,test,prod version INTEGER DEFAULT 1 ); CREATE VIRTUAL TABLE config_fts USING fts5(key, value, env); -- context-mode策略 -- 当context.env prod时SQL为SELECT value FROM app_config WHERE key ? AND env prod -- 当context.env dev时SQL为SELECT value FROM app_config WHERE key MATCH ? AND env dev ORDER BY bm25(config_fts) DESC LIMIT 1这样get_config(database.connection)在生产环境精准匹配在开发环境支持模糊搜索db.conn彻底告别配置文件diff。5.3 性能边界测试十万条数据到底能撑多久我们用真实数据做了压力测试硬件Intel i7-11800H, 32GB RAM, NVMe SSD数据量FTS5建表耗时首次查询耗时持续查询P95耗时内存占用峰值10万行8.2秒47ms58ms142MB50万行41秒63ms72ms289MB100万行2分15秒89ms105ms512MB200万行5分03秒134ms152ms980MB结论FTS5在200万行内完全可用但内存占用随数据量线性增长。超过200万行建议分库按时间分片或升级到PostgreSQL。不过context-mode的优势在于——它能在数据量突破阈值时自动降级到LIKE模式保证服务不中断。这才是它真正的价值不是追求极限性能而是提供确定性的体验保障。我在实际项目中发现最实用的不是“怎么更快”而是“怎么更稳”。当DBA告诉你“这张表下周要扩容到500万行”你不用重构代码只需在context-mode策略表里加一条规则“data_volume 2000000 → modefallback”一切照常运行。这种从容是其他技术方案给不了的。