引子：SQLite 自曝其短

SQLite 官方文档《SQLite 的适用场景》中写了一段话：SQLite 官网由 Fossil 版本控制系统驱动，Fossil 生成的每个动态页面大约执行 200 条 SQL 语句。

这话说得大大方方——不是对手挖的，不是安全研究者扒的，SQLite 自己写在官网文档里。

然后读者炸了：

• "一个页面两百条 SQL？糟糕透顶的设计。"
• "两百条查询是太多太多了。"
• "N+1 查询问题是教科书级反面教材，SQLite 团队不知道吗？"

骂得有理有据。每条 SQL 就是一次网络往返，200 次往返叠在一起，页面响应直奔天际——这是数据库优化课的常识。

整个推理链条完全正确，每个环节都没问题——只漏掉了一个前提：批评者们默认了一个自己甚至没意识到的假设——数据库一定跑在另一台服务器上。

一、N+1 为什么是反模式？"为什么"比"是什么"重要

什么是 N+1 查询

应用程序先执行一条查询拉出列表（1 次），再对列表中每一项分别执行查询（N 次），总计 N+1 次。

典型场景：查出 50 条时间线条目，再对每条分别查标签、权限、父节点。

为什么在 C/S 数据库上是要命的

在 MySQL / PostgreSQL 的世界里，应用程序和数据库跑在不同机器上，每条 SQL 要走一遍完整的网络路径：

应用打包 SQL → OS 网络栈 → 网卡 → 交换机 → 数据库服务器网卡 → OS → 数据库引擎 → 计算结果 → 原路返回

这个流程每执行一次叫一次消息往返（message round-trip）。即使是本地网络，每次往返延迟也以毫秒计。

粗算一下：

还没算查询本身的计算时间，光网络开销就已经超标了。所以在传统 C/S 架构下，N+1 确实是要命的设计，骂得对。

为什么在 SQLite 上不是问题

SQLite 的架构完全不同：

函数调用和网络往返之间的性能差距，大约是六个数量级。

用 SQLite 作者 D. Richard Hipp 的话：

SQLite is not client/server. Queries do not involve message round-trips, only a function call.

翻译成人话：你们骂的那个东西，SQLite 里根本没有。

二、25 毫秒：用数据说话

SQLite 团队的回应方式很硬核——不发优化指南，不教你怎么把 200 条降到 20 条，而是直接贴出真实页面的完整 SQL 执行日志。

2016 年 9 月 16 日，用户访问时间线页面，数据库引擎实际执行的每一条 SQL，200 多行日志全文公开，附上一行标注：

50 条条目的时间线页面，总生成时间不到 25 毫秒。

Fossil 的查询模式

第一步：主查询，拉出所有时间线条目（多表 JOIN、嵌套子查询、聚合）：

INSERT OR IGNORE INTO timeline SELECT
  blob.rid AS blobRid,
  uuid AS uuid,
  datetime(event.mtime,toLocal()) AS timestamp,
  coalesce(ecomment, comment) AS comment,
  coalesce(euser, user) AS user,
  blob.rid IN leaf AS leaf,
  bgcolor AS bgColor,
  event.type AS eventType,
  (SELECT group_concat(substr(tagname,5), ', ')
    FROM tag, tagxref
    WHERE tagname GLOB 'sym-*' AND tag.tagid=tagxref.tagid
      AND tagxref.rid=blob.rid AND tagxref.tagtype>0) AS tags,
  tagid AS tagid,
  brief AS brief,
  event.mtime AS mtime
FROM event CROSS JOIN blob
WHERE blob.rid=event.objid
  AND NOT EXISTS(SELECT 1 FROM tagxref
    WHERE tagid=5 AND tagtype>0 AND rid=blob.rid)
ORDER BY event.mtime DESC LIMIT 50;

这条查询证明：SQLite 完全有能力执行复杂大查询——多表 JOIN、嵌套子查询、GROUP_CONCAT 聚合，MySQL 能做的它都能做。

第二步：N+1 查询，对每个条目分别查标签、父节点、权限：

-- 条目 68028
SELECT value FROM tagxref WHERE tagid=8 AND tagtype>0 AND rid=68028;
SELECT pid FROM plink WHERE cid=68028 AND pid NOT IN phantom ORDER BY isprim DESC;
SELECT 1 FROM private WHERE rid=68028;

-- 条目 68026
SELECT value FROM tagxref WHERE tagid=8 AND tagtype>0 AND rid=68026;
SELECT pid FROM plink WHERE cid=68026 AND pid NOT IN phantom ORDER BY isprim DESC;
SELECT 1 FROM private WHERE rid=68026;

-- ... 50 个条目，每个至少 3 条小查询

200+ 条 SQL，整整齐齐。任何 MySQL DBA 看到都会心脏骤停。

但页面底部赫然写着：生成耗时 < 25 ms。

25 毫秒意味着什么

进一步的性能拆解：在这 25 ms 里，真正花在 SQLite 引擎内部的时间只占少数几毫秒，其余消耗在 HTTP 处理、模板渲染、HTML 输出上。200 多条 SQL 的查询开销，在性能剖面图里甚至排不进前三。

当每条查询的开销从"一次洲际航班"降级为"在家里走两步"，200 条查询就等价于 200 次从客厅走到厨房——谁会在意自己一天从客厅到厨房走了多少步？

三、N+1 的另一面：代码架构的选择

性能问题讲清楚了，但 Fossil 选择 N+1 的真正原因不是炫耀性能，而是代码维护成本。

时间线页面的复杂性

时间线页面展示多种内容类型，每种需要的信息不同：

两种代码组织哲学

巨型 SQL 方案——把所有数据塞进一条查询：

• 得到一条膨胀到几百行的 JOIN 语句
• 一个把所有渲染分支塞在一起的巨型模板函数
• 提交人和工单处理人的列名在同一个结果集里打架
• 状态字段语义互相污染
• 改一个工单显示逻辑，可能震塌整个时间线的 SQL 结构

N+1 方案——按类型分模块查询：

• 获取提交数据的代码放在提交渲染模块里
• 获取工单数据的代码放在工单渲染模块里
• 获取 Wiki 数据的代码放在 Wiki 渲染模块里
• 每种类型的开发人员只需理解自己那块的查询逻辑，互不越界

这是教科书级的关注点分离（Separation of Concerns），只不过它恰好和另一本教科书（数据库性能优化）撞了车。

两本教科书都对，但在 SQLite 的底盘上，关注点分离这本的分量更重。

四、核心洞察：迁移结论的人很多，迁移前提的人很少

这里有一个在所有技术争论中反复出现的认知陷阱：

把一门技术栈下形成的工程判断，当作所有技术栈下的物理定律。

N+1 是反模式，因为网络往返昂贵；SQLite 没有网络往返，所以 N+1 不是性能问题——这条推理链无懈可击。但在二十年的传播中，"因为"被磨掉了，只剩下一个光溜溜的结论：N+1 在任何时候、任何场景、任何数据库上都是坏的。

同样的剧本，反复上演

ORM 的诞生动机之一就是帮你自动合并 N+1 查询——Hibernate 的 @BatchSize、Entity Framework 的 Include()、Django ORM 的 select_related() 和 prefetch_related()，解决的都是同一个问题。但当数据库引擎变成 SQLite——一个连进程边界都不跨的函数库——这些为了减少查询数量而引入的抽象层、批处理策略、预加载配置，从"必要的基础设施"变成了"不必要的复杂度"。

SQLite 的并发误解

同样的现象在 SQLite 社区内部也有倒影。很多人的推理链：

SQLite 不支持并发写入 → 高并发场景下 MySQL 更好 → 所以 SQLite 是玩具

漏掉的关键事实：大多数网站和应用的实际写入并发量，远远低于开发者自以为的水平。

SQLite 官方数据：

Richard Hipp 对此的回应有一种外科手术式的精准：

SQLite does not compete with client/server databases. SQLite competes with fopen().

SQLite 的竞争对手不是 MySQL，是文件读写函数。 当你把复杂度基线从"一个分布式数据库集群"拉到"一次文件操作"时，200 条 SQL 的性能负担露出了真实面目：接近于零。

五、知识传播的结构性衰减

软件工程的代际传承存在一个结构性的信息衰减：

第一代工程师：在具体技术条件下发现了一个问题，设计了方案，写出了文档
    ↓
第二代工程师：读到了文档，记住了方案，未必知道当初的问题长什么样
    ↓
第三代工程师：方案成了铁律，问题成了历史，前提条件沉入海底
    ↓
水面上只剩下一条孤零零的戒律：N+1 是不好的

这种衰减不是某一代人偷懒，而是知识在大规模传播中的必然宿命。每一代传下去的，是结论，是规则，是面试题的标准答案，但当初那个"为什么"——那个让规则之所以成为规则的具体场景、具体约束、具体成本结构——传着传着就散了。

SQLite 的 200 条 SQL 恰好是一台完美的前提条件压力测试机，它对着所有面试过"N+1 问题怎么解决"的开发者发出同一个灵魂拷问：

你知道为什么 N+1 是问题吗？还是你只知道 N+1 是问题？

六、结论：理解查询成本，而非优化查询数量

关键认知框架

三条实践建议

1. 先搞清楚查询成本从哪来。N+1 的问题不在查询数量本身，而在每次查询的往返成本。SQLite 是进程内函数调用，没有往返成本，所以 N+1 不是性能问题。
2. 在 SQLite 场景下优先考虑代码组织。N+1 模式天然实现了关注点分离，每个模块只查自己需要的数据，互不耦合。强行合并查询换来的"优化"在 SQLite 上几乎没有收益，却显著增加了代码复杂度。
3. 迁移结论时，连同前提一起迁移。任何技术判断都绑定了前提条件，脱离前提照搬结论，就是教条主义。

与其优化查询数量，不如理解查询成本。

性能问题的本质不是"你执行了多少次查询"，而是"每次查询花了多少成本"。当成本趋近于零时，数量就不再是问题。

参考资料：SQLite 官方文档 - Appropriate Uses For SQLite、Fossil 时间线页面 SQL 日志