1.4 适用边界与反例清单

1.4 适用边界与反例清单

本节摘要：判断一个工具的最好材料是它的失败案例。本节先快速过一遍 DuckDB 的理想场景，然后给出五类"用了会后悔"的反例，每类都指明坏在哪、为什么坏、该换什么。最后，主线案例在本节完成第一章的首次交付。

从一个翻车反例说起

有人把 DuckDB 当成网站的后端数据库：几百个用户的请求并发读写同一个库文件，结果隔三差五报锁冲突，API 响应像抽风。这不能怪工具——"进程内嵌入、单文件"的设计在诞生那天就写明了它的立场：一个写者、一个进程、以分析为主的负载。拿分析引擎去扛在线事务，就像拿跑车去搬砖，坏的不是车，是用途。反例比优点更能划清边界，所以我们从反例讲起。

五类反例与替代路径

逐条展开之前，先说明一个观察方法：五类反例的根因都能追溯到第1.1节的四个设计决定。这正好训练一个重要直觉——工具的边界不是经验规则，而是设计决定的必然推论。你在第2章学完架构后，回看这张表会有"原来如此"的二次领悟。

第一类的病根是"一个进程一个写者"。DuckDB 的并发模型是单进程内多线程：同一进程里查询可以充分并行，但多个进程不能同时写一个库文件。网站后端天然是多进程多机器的，硬塞给它就会在文件锁上排队。第二类的病根是列存：列式布局为了让"读一列"很快，牺牲了"取一行"的局部性，单行点查要拼接多个列段，天然吃亏。两条病根合起来还有一个衍生判断：负载的"读写比"是选型的第一判据——读多写少甚至是纯读的分析负载，列存的一切设计都在为你工作；读写均衡或写多读少的负载，每一项设计都在跟你作对。看负载先看读写比，比看任何性能评测都更接近本质。

第三类和第四类关乎定位。持续流式写入意味着小批量高频追加，而分析引擎最喜欢"攒一批、写一段"的批量模式；多人在线服务则需要网络层、连接池、用户鉴权——这些 DuckDB 干脆没有，它把位置留给了宿主应用。第五类是生态位问题：企业级数据库几十年的备份、审计、权限生态，不是一个轻内核应该背的包袱。

灰区辨析：两个"似反例而非"的场景

清单之外有两种场景经常被误判，值得单独辩一辩。其一，多人共读一份库文件。乍听撞了"单进程"红线，其实只撞了一半：写者必须唯一，但只读打开的读者可以有很多——把库文件放共享盘，写者每天刷新一次，分析师们只读模式各开各的会话，这种"读副本"模式完全成立。真正不成立的是多人同时写。其二，数据比内存大。"内存数据库"这个标签让人误以为超内存就没辙，但第2.2节会讲到：引擎的中间结果装不下时会溢出到磁盘继续算，代价是慢几倍而不是失败。所以"数据 40 GB、内存 16 GB"不是红线，是取舍——一次性分析可以接受溢出，天天跑的报表就该先做裁剪或聚合。两个灰区合起来的判断法：把"限制"读成"条件"，多数红线都会变成可满足的前提。

动手前的一分钟自检

把整节的判断力压缩成一分钟可用的问卷，新项目拿到手先过三问。**第一问：写者有几个？**超过一个进程要写，直接出局或改成"单写者加只读副本"的形态。**第二问：负载是扫描聚合还是单行事务？**看最核心的那几条操作——如果是按主键频繁读写单行，这是 SQLite 的地盘。**第三问：数据规模与交付时限匹配吗？**单机资源摆平得了的数据量、要得急的结论，是它的主场；亿行级持续写入、或要给几百人当在线服务，往前两问就已经出局了。三问全绿才动工——这个问卷便宜到可以养成习惯，而它拦截的每一单选型错误，代价都远超问卷本身。

理想场景：对照着记

反例的另一面就是甜点区，归纳起来四类。本地即席分析：拿到文件就要答案，主线案例是标准样本。应用内嵌分析：给桌面软件、边缘设备、浏览器内核塞一个分析引擎，随应用分发。数据管道节点：在 ETL 流程里做格式转换、清洗校验、小规模聚合，替代手写的脚本循环。教学与原型：零部署的特性让它成为学 SQL、验证数据想法的最短路径。四类场景共享同一个气质：单机、批量、读多写少、要得急。

主线案例：第一章的首次交付

回到退款集中时段的问题。用第1.1节那两条 SQL，我们已经拿到按小时分布的退款笔数。这里补上交付结论前该有的一步——先确认数据本身的完整性，别让结论建在残缺数据上：

-- 交付前的三个自检：行数守恒、空值规模、时间范围
SELECT count(*) AS 总行数,
       count(*) - count(refund_time) AS 非退款行数,
       count(refund_time) - count(CASE WHEN amount < 0 THEN 1 END) AS 异常组合数,
       min(trade_time) AS 起始时间,
       max(trade_time) AS 截止时间
FROM read_csv_auto('trades.csv');
​

自检结果没有大坑，第一次交付的结论可以给出：退款笔数在午后时段明显隆起，深夜占比很低。这个结论粗糙但正确——它的价值是给业务方一个即时反馈，同时给我们自己一个基线：后面所有章节的优化，都要能解释"结论没变、过程变好"。自检这个动作本身也值得留在流程里：它只花一条查询的时间，却把"数据残缺导致的错误结论"这一最尴尬的事故类型挡在了交付之前——第7.4节收官复盘时你会发现，这份自检 SQL 原封不动地活在了最终交付物清单里。第2章开始往下挖：当这份文件大到一次读不进内存时，DuckDB 的架构里备着什么后手。

边界是移动的：怎么跟上

清单给出的是此刻的边界，而边界本身在移动——每一代版本都在往外拱：内存管理在扩张（溢出让"超内存"不再是红线）、扩展在补生态（地理与全文检索从无到有）、并发写虽是硬约束但"读副本"模式让它弱化成流程问题。这带来两条使用建议。其一，别背旧结论：一年前读过的"它做不了某某"可能已经过期，真要用到某个边界能力时，先验证再说。其二，守住硬边界：不管版本怎么走，单写者、单机规模、分析型负载这三条是设计决定的根，短期看不到松动——绕开它们的方式是换形态（第6.3节的混合架构），不是等版本。分清"会动的边界"与"不动的根"，你对这类快速演进的工具就能既保持敏感又不被传言牵着走。

本节要点回顾

• 边界即设计：五类反例都能推导自四个设计决定，记根因比记清单更可靠。
• 高并发在线服务不归它管：单进程写者模型与无网络层，决定了它天然不是网站后端。
• 甜点区四类：本地即席分析、应用内嵌、管道节点、教学原型，气质是单机批量读多写少。
• 交付纪律：结论之前先自检行数守恒与空值规模，粗糙但自检过的结论好过精细但可疑的结论。