1. 四条主张的落脚点：一份技术分享为什么值得逐条拆开看
某次数据库技术圈的内部分享上，一位做数据技术产品的合伙人抛出了四条关于自研数据库发展的主张，现场反应很有意思——做内核的点头，做交付的摇头，做迁移的沉默。我后来把这几条主张在自己经手的几个项目里对照了一遍，发现它们不是宣传口径，而是四道施工顺序题：哪一块先做、哪一块必须同时做、哪一块急不得。这四条大致可以归纳为内核自主、生态兼容、工程可用、人才与社区，听上去都是大词，但拆到具体代码和数据上，每一条都有非常具体的判决标准。
这篇内容面向三类人：正在评估是否把业务迁到自研数据库上的架构师、正在做数据库内核或工具链开发的同学、以及刚入行想弄清楚"一个数据库产品到底难在哪"的开发者。我不打算复述那份分享本身，因为脱离具体版本的任何主张都容易变成空话；我更想聊的是——把这类主张放到真实的迁移、压测、故障演练现场，它究竟对应哪些技术决策，哪些决策一旦做错，后面要用十倍的成本补。
先说一个我反复验证过的结论：这四条主张之间存在严格的依赖顺序，但很多团队恰恰是倒着做的。先喊生态兼容，结果内核的语义边界自己都说不清楚；先做人才招募，结果文档写得连自己同事都跑不起来 Demo。下面按我理解的实际施工顺序展开，每条都配上能直接抄的做法和踩过的坑。
1.1 为什么"内核自主"被排在最前面，而不是最后
很多人对内核自主的理解停留在"代码是自己写的"，这其实是最低标准。真正决定一个数据库能不能长期活下去的，是你能不能在出问题时定位到确定的代码行，并且有权改动它。我见过一个很典型的场景：某个业务在高峰期出现规律性的写入延迟毛刺，每 37 分钟左右一次，持续 2 到 4 秒。用外部工具抓了半天，只看到刷盘线程在排队，看不到为什么排队。如果内核不可控，这个问题的结局通常是被归因为"硬件抖动"然后不了了之；内核可控的话，你可以把刷盘路径上的日志点加进去，两小时就能确认是检查点触发时脏页比例超阈值导致的集中回刷。
所以内核自主的核心价值不是"自主"这两个字，而是可观测性和可修改性。具体到工程上，它至少包含三层能力：第一层是编译构建链路完整，能自己出带调试符号的二进制包；第二层是关键路径有足够的内部指标暴露，比如 WAL 写入队列深度、脏页比例、页缓存命中率、锁等待分桶统计；第三层是能在不影响线上语义的前提下打补丁并灰度验证。缺任何一层，"自主"就只是源码托管在自己手里而已。
判断一个团队的内核能力到什么程度，我一般会问三个很土的问题：你们能不能在测试环境打开全量调试日志跑一整晚不把磁盘写爆？你们的慢查询能不能追到具体的算子耗时而不只是总耗时？你们上一次修复内核级 bug 从定位到上线用了多久？三个问题的答案比任何架构图都有说服力。
1.2 兼容、可用、生态这三条其实是同一条链上的三个环
分享里另外三条主张看起来是并列的，但只要做过一次真实迁移就知道它们是串联的。兼容性决定了迁移能不能启动，工程可用性决定了迁移能不能收尾，生态决定了迁移之后有没有人愿意继续用。这三件事任意一环断了，前功尽弃。
我经历过一个很典型的连环坑：语法兼容做得不错，迁移工具也能把 DDL 和 DML 转过去，业务方很高兴，一周之内切了三个系统。结果第二周开始出问题——某个报表系统的分页查询在数据量涨到两千万行后从 200 毫秒变成 40 秒，原因是优化器对这个特定的ORDER BY ... LIMIT组合选了错误的索引。这不是兼容性问题，是工程可用性问题，但业务方的感受是"这个库不行"。再往后，运维团队发现没有对应的监控插件，只能靠通用采集器凑合，告警规则全要重写，于是抗拒情绪起来了——这就是生态缺口。
所以我把这三条重新表述成一句更可执行的话：兼容性要覆盖到语义层，可用性要覆盖到运维层，生态要覆盖到习惯层。语义层的典型例子是空值排序和除法行为，运维层的典型例子是备份恢复的粒度，习惯层的典型例子是原有客户端工具能不能连上来。下面几节我按这个顺序逐个拆。
2. 存储引擎与优化器：内核自主最先要啃下的两块硬骨头
聊内核绕不开这两个组件，但它们的难度性质完全不同。存储引擎难在边界条件多，写对容易，写到极端负载下依然正确很难；优化器难在信息不完备，永远在猜，猜错的代价直接体现在业务响应时间上。很多自研产品在第一版会把精力全压在存储引擎上，优化器凑合一个规则式的，然后在真实业务里被各种奇怪的执行计划教育。
2.1 LSM-Tree 与 B-Tree 的选型账本
选哪种结构没有绝对答案，只有匹配度问题。我把实际项目里最容易踩的判断点整理成一张表，这张表我给过好几个团队，反馈是比看论文有用。
| 对比维度 | LSM-Tree 类结构 | B-Tree 类结构 |
|---|---|---|
| 写放大 | 高，取决于层数与压缩策略 | 相对低，但页分裂有额外开销 |
| 读放大 | 高，需要多层查找加布隆过滤器 | 低，树高通常 3 到 4 层 |
| 空间放大 | 中到高，取决于压缩算法与回收时机 | 低到中，碎片需要定期整理 |
| 范围扫描 | 较差，多路归并开销明显 | 好，叶子节点天然有序 |
| 写多读少场景 | 明显占优 | 需要调优页填充率 |
| 读多写少场景 | 需要精心调参 | 天然占优 |
| 长事务与大事务 | 处理成本高 | 相对友好 |
| 运维复杂度 | 压缩、合并策略需要持续观察 | 碎片与膨胀需要关注 |
我个人的经验是：如果业务的写入模式是持续高并发的追加型（日志、时序、消息落库），LSM 的收益非常明显；如果是大量的点查加范围扫描、并且事务较长，B-Tree 更省心。最怕的是拿着 LSM 去做大量更新加范围扫描的混合负载，然后靠堆机器硬扛，压缩线程和查询线程抢 CPU，表现就是"平时挺快，一到合并就抖"。
一个可落地的判断方法是做一次写放大的粗算。假设单条记录 1KB，LSM 的层数压缩比为 10 倍、共 4 层，最坏情况下一条记录会参与 4 次压缩写入，写放大就是 4 倍；如果压缩比设成 4 倍、层数 6 层，写放大能到 6 倍以上。这个数字直接决定了你的 SSD 寿命和后台带宽占用。我见过一个项目把压缩比从 10 调到 4 想换取更低的读放大，结果写放大翻了一倍多，磁盘 IO 打满，最后又调回去。这种参数不能凭感觉改，一定要先算。
2.2 优化器的问题从来不是"聪明不聪明"，而是"信息够不够"
很多人以为优化器难是因为算法复杂，其实自研数据库里优化器最先崩的地方是统计信息。CBO 要估算代价，前提是知道每张表多少行、每列多少不同值、数据分布偏不偏。统计信息不准，再好的算法也是瞎猜。
举个我在测试环境复现过的例子。一张订单表两千万行，status字段有 5 个取值，但其中'DONE'占了 96%。查询WHERE status = 'PENDING'只命中 0.8% 的行，走索引非常合适；查询WHERE status = 'DONE'命中 96%，全表扫描反而更快。如果统计信息里只有"5 个不同值"，优化器会认为每个值命中 20%，两个查询都选索引，第二个查询就慢得离谱。这就是直方图存在的意义。
实际做法上，我建议在迁移评估阶段就跑一遍下面这类检查，把高风险的表和列提前标出来：
-- 检查关键列的分布偏斜情况（示例写法，具体函数名按产品文档调整） SELECT status, COUNT(*) AS cnt FROM orders GROUP BY status ORDER BY cnt DESC; -- 对比优化器估算行数与实际行数，偏差超过 10 倍就要警惕 EXPLAIN (ANALYZE, VERBOSE) SELECT * FROM orders WHERE status = 'PENDING';估算行数和实际行数差十倍以上，说明统计信息需要调整采样率或者补直方图。这件事在测试环境做成本很低，在生产上做可能要等一次业务低峰。还有一个更省事的办法：对已知的偏斜列，在迁移前就把查询改写成不依赖优化器猜测的形式，比如把IN拆成多个确定性的查询，或者加显式的执行计划提示。虽然不够优雅，但比上线后半夜被叫起来查慢 SQL 强。
2.3 WAL 与刷盘策略：几个必须算清楚的数字
WAL 相关的参数是最容易被随手改、也最容易出事的。核心就三个量：日志缓冲区大小、刷盘时机、检查点频率。它们之间互相牵制，改一个另一个大概率要跟着动。
我的做法是先算最坏情况下的日志产生速率。假设业务峰值 5000 TPS，每事务平均产生 1.5KB 日志，那么日志速率约 7.5MB/s，一分钟就是 450MB。如果日志缓冲区只给 16MB，那么每两秒左右就要刷一次，每次刷盘都会让提交线程等待。把这个数算出来，缓冲区该给多大心里就有底了。
检查点频率更是要算。检查点间隔太短，脏页刷不过来会积压；间隔太长，崩溃恢复时间会拉长。一个粗略的估算方式：如果数据文件总量 500GB，恢复速度按 200MB/s 算，全量恢复要 2500 秒，接近 42 分钟——这个恢复时间大多数业务都无法接受，所以必须靠增量检查点把恢复窗口压到分钟级。这个账在选型阶段就该算一遍，而不是等出故障才想起来。
提示：调刷盘相关参数前，先把峰值 TPS、平均日志量、可接受的数据丢失窗口、可接受的崩溃恢复时间这四个数写下来贴在墙上。四个数定不下来，参数怎么调都是碰运气。
3. SQL 兼容与迁移：真正烧钱的地方在方言和类型映射
兼容性是四条主张里最容易被低估的。原因是它看起来是个"转换"问题，实际上是个"语义"问题。语法转换工具满天飞，但真正让迁移项目翻车的，几乎都是那些文档里没写、只有踩过才知道的语义差异。
3.1 兼容性要分四层看，只做第一层等于没做
我在评估兼容性时习惯分四层，每层的验收方式都不一样：
第一层是语法层，能不能解析。这一层最容易，工具也最多。第二层是语义层，同样的语句在不同库里结果是不是一致，比如字符串拼接遇到 NULL、除法除零、日期加减的边界、GROUP BY对非聚合列的容忍度。第三层是协议层，原有驱动能不能直接连、连接池行为是不是一致、事务隔离级别的默认值是不是一样。第四层是生态层，备份工具、监控采集、ORM 框架、BI 连接器能不能无缝接上。
四层里最容易出事的是第二层和第三层。我遇到过一个很典型的案例：业务代码里的 SQL 在旧库上WHERE name = NULL这种写法居然能查出数据（因为旧库对这个位置做了隐式转换），迁到新库后一条都查不出来。代码里这样的位置有几十处，靠代码审查根本找不完，最后是靠在测试环境开全量 SQL 日志、跑一周真实流量回放才捞出来的。
第三层的坑更隐蔽。某个连接池默认会发送一个初始化语句设置会话变量，旧库认识这个变量，新库不认识，直接报错，而且报错信息里看不出是哪一步失败的。这类问题在单元测试里基本发现不了，必须是集成环境全链路跑。
3.2 一份能直接用的迁移前评估清单
我把迁移评估拆成可以逐项打勾的清单，每项都有明确的通过标准，避免"感觉差不多了"就上线。
| 检查项 | 具体做法 | 通过标准 |
|---|---|---|
| 对象兼容 | 导出全部 DDL，逐条比对字段类型与约束 | 无类型降级，无精度丢失 |
| 数据量核对 | 迁移前后逐表COUNT(*)加关键表校验和 | 行数完全一致，校验和一致 |
| SQL 全量收集 | 从数据库性能视图导出近 30 天全部 SQL 指纹 | 覆盖率 100%，逐条过语法与语义 |
| 慢 SQL 专项 | 取原库 Top 200 慢 SQL 在新库重跑 | 执行计划合理，耗时偏差在可接受范围 |
| 驱动与连接池 | 用生产同版本驱动做长连接压测 | 连接创建、回收、超时行为一致 |
| 事务行为 | 构造并发场景验证隔离级别表现 | 与业务预期一致，无脏读或幻读差异 |
| 备份恢复 | 全量加增量备份、恢复到新实例 | 恢复点一致，耗时在 RTO 之内 |
| 运维接入 | 监控、告警、巡检脚本全部接上 | 关键指标齐全，阈值可配置 |
这张表里我最看重"SQL 全量收集"这一项。很多团队只测了应用层暴露的接口，但定时任务、报表脚本、运维手工执行的 SQL 完全没覆盖。我通常建议直接用数据库自身的语句统计视图导出全部 SQL 指纹，按执行次数和总耗时排序，前 95% 覆盖不到的 SQL 就当作没测过。
3.3 三个最容易被忽略的语义差异
第一个是空值参与运算。NULL + 1在几乎所有库里都是 NULL，但CONCAT类函数的行为差异很大，有的库遇 NULL 返回 NULL，有的库会跳过 NULL 拼剩下的。业务里拼接地址、拼接姓名的场景特别多，一旦行为不同，导出的报表就会出现诡异的空行。
第二个是隐式类型转换。字符串和数字比较时，有的库转数字，有的库转字符串。转数字的话'abc' = 0可能成立，转字符串的话123 = '123'才成立。这类差异在 WHERE 条件里会直接改变结果集大小，而且不报错，非常难查。
第三个是分页的稳定性。ORDER BY的字段如果有重复值，不同库返回的行顺序可能不同，分页就会出现重复行或漏行。正确做法是排序键里加上唯一列做兜底，这个改动很小，但能省掉大量排查时间。
提示：迁移前让开发同学把
ORDER BY全部检一遍，凡是排序键不能唯一确定行的，一律补上主键或唯一列。这个动作成本极低，收益极高。
4. 分布式事务与一致性：分片键选错，后面全是补丁
我见过的分布式数据库项目里，出问题最多的不是事务实现本身，而是分片键设计。分片键选错之后，跨分片查询变多、分布式事务变多、性能掉一个数量级，然后团队开始加缓存、加只读副本、加各种中间层，最后系统复杂度爆炸。
4.1 分片键要过四个判断维度
第一个维度是基数。分片键的取值数量要足够多，否则数据倾斜无法避免。用省份做分片键，只有三十几个值，再怎么分也就那么多片。用订单号做分片键，基数够大，但范围查询全废。
第二个维度是访问模式匹配度。业务里 80% 的查询是不是都带这个字段？如果不带，就意味着大量跨分片查询。我一般会从慢 SQL 里统计 WHERE 条件字段的分布，命中率低于 70% 的分片键要重新考虑。
第三个维度是数据增长的可预测性。按时间分片看着很自然，但会导致新数据全落在最新分片上，热点问题严重。按用户 ID 哈希分片分布均匀，但按时间范围的查询要广播到所有分片。
第四个维度是业务隔离需求。有些业务天然按租户隔离，用租户 ID 做分片键既能保证均匀，又能让大部分查询落在单分片内，代价是头部大租户会形成热点，需要额外的拆分策略。
我通常的做法是：先列出业务 Top 20 查询，标注每个查询的过滤字段；再统计每个候选分片键在这些查询里的命中率；最后选命中率最高且基数足够的那个。这个分析一两天就能做完，比上线后重构分片策略便宜太多。
4.2 事务模型的选择要看业务能容忍什么
不同的事务实现方式代价差别很大，没有普适最优解，只有匹配度。
| 方案 | 适用场景 | 主要代价 |
|---|---|---|
| 单机事务加只读副本 | 强一致写入集中在单分片 | 扩展性受单机上限约束 |
| 两阶段提交 | 跨分片写较少、延迟敏感度低 | 协调者故障时阻塞，需要超时与补偿 |
| 基于时间戳的并发控制 | 冲突较少、读多写少 | 冲突多时重试率高 |
| 全局时钟加多版本 | 需要全局一致性快照读 | 依赖时钟精度，时钟偏差影响正确性 |
我的经验是：先问业务能容忍多少写延迟和多少重试，而不是先问哪种方案更先进。金融类的记账场景通常能接受两阶段提交的额外延迟，换取明确的原子性；互联网类的点赞、计数场景更在意吞吐，宁可接受最终一致加对账补偿。最怕的是把需要强一致的场景放到最终一致模型上，然后靠业务代码打补丁，补丁越打越多。
4.3 一致性级别的名词要落到可观测的行为上
很多产品文档里会写"支持强一致、会话一致、最终一致"，但真正要看的是切换之后业务能观测到什么。我习惯用三个具体测试来验证：
第一个测试是"写后立刻读"。在同一个会话里写完立即读，能不能读到。这个如果读不到，很多业务代码会直接出问题。
第二个测试是"跨会话可见延迟"。A 会话写入，B 会话什么时候能读到。这个延迟的分布比平均值重要，P99 延迟才是业务真正感受到的。
第三个测试是"故障切换后的数据完整性"。主动杀掉一个节点，切换完成后检查已提交事务是否全部保留，未提交的是否全部回滚。这个测试必须做，而且要反复做，因为切换路径上的边界条件特别多。
我一般会把这三个测试写成脚本，每次版本升级都跑一遍。跑了两三次之后，你会发现一些只在特定时序下才出现的问题，比如切换过程中恰好有事务处于两阶段提交的准备阶段，恢复后可能长时间持有锁。
5. 从能跑到敢上生产：可观测性和故障演练决定成败
一个数据库能不能上生产，功能测试说了不算，压测说了也不算，故障演练说了算。我见过太多系统在实验室里跑得飞快，一上生产就被各种非功能问题打回原形。
5.1 慢 SQL 之外的等待事件才是真问题
大部分人排查性能只看慢 SQL 列表，但慢 SQL 只是结果，原因在等待事件里。我建议至少把这几类等待事件做到可查询、可分桶统计：锁等待（按锁类型和等待时长分桶）、IO 等待（按读/写、随机/顺序拆开）、日志刷盘等待、网络等待、CPU 排队。
举个具体例子。某次压测发现 QPS 上不去，慢 SQL 列表是空的，所有语句都很快。把等待事件拉出来一看，大量的会话卡在日志刷盘等待上，根因是刷盘线程只有一个，而并发提交的事务很多，提交线程全在排队。改成组提交之后，QPS 直接翻了三倍。如果没有等待事件的细分，这个问题只能靠猜。
5.2 压测要造"脏数据"和"歪查询"
标准压测工具跑出来的数字往往偏乐观，因为它造的负载太干净：数据分布均匀、查询全部命中索引、没有长事务、没有大范围扫描。真实业务恰恰相反，总有一批历史遗留的奇怪查询、总有一些超长事务、总有一些分布极偏的字段。
我的做法是在标准压测之外额外加三组"脏负载"：第一组是历史遗留 SQL 集合，从生产环境采集的真实慢查询；第二组是大事务，故意构造影响几万行的事务看锁和回滚段表现；第三组是倾斜数据，把某个字段构造成 95% 集中在同一个值上，看优化器和执行计划还能不能扛住。
这三组跑下来，暴露的问题往往比标准压测多得多。特别是倾斜数据这一组，经常能测出统计信息更新不及时导致的执行计划突变。
5.3 故障演练要脚本化，别靠人肉演练
"演练"这两个字很多人理解成挑个周末手工操作一遍，这种演练价值很低，因为不可重复、不可回归。正确做法是把每个故障场景写成脚本，纳入常规回归。
至少要覆盖这几类场景：单节点进程被强杀、磁盘写满、网络分区、时钟跳变、主从切换时的高并发写入、备份期间的高负载。每个场景都要有明确的验收标准，比如"强杀主节点后，RTO 小于 30 秒，已提交事务零丢失"。
# 故障演练脚本骨架示意 # 1. 打底负载 run_benchmark --tps 2000 --duration 600s & # 2. 记录基线 collect_metrics --output baseline.json # 3. 注入故障（示例：模拟节点异常退出） inject_fault --type process_kill --target node-2 # 4. 采集切换过程指标 collect_metrics --output during_fault.json # 5. 校验数据完整性 verify_consistency --check committed_transactions这类脚本跑一次可能只要二十分钟，但能把大部分切换路径上的问题提前暴露出来。我个人的体会是，第一次跑故障演练几乎一定会发现问题，第二次能发现一半，跑到第五次之后系统才算真正稳。
6. 文档、示例与贡献路径：生态不是发布会讲出来的
最后这条主张听起来最"软"，实际上最硬。技术产品留存用户的从来不是参数表，而是别人照着你的文档能不能在半小时内跑起来。
6.1 文档的第一读者是三个月后的自己
我见过太多文档写着"简单配置即可启动"，然后新人花两天都起不来。一个好文档的标准其实很土：从零开始，不跳步，每一步都写清楚前提。操作系统版本、依赖库版本、端口占用、权限要求、常见报错和处理办法，这些都不能省。
我习惯在文档开头放一个"五分钟快速验证"章节，目标非常明确——让读者在五分钟内看到一条数据成功写入并读出来。这个章节必须用真实可复制的命令，不能有任何"根据实际情况调整"的占位符。等读者跑通了再往下看架构设计，心理门槛就完全不一样了。
6.2 示例库比 API 文档更能留住人
API 文档告诉人"有什么"，示例库告诉人"怎么用"。我建议示例库按业务场景组织而不是按功能模块组织：订单分库分表怎么做、报表大查询怎么优化、消息落库怎么保证不丢、多租户怎么隔离。每个示例都要能一键跑起来，包含建表、造数据、查询、性能对比。
一个很实用的做法是给每个示例配一份"错误示范"。比如分页查询的示例里，同时给出没有唯一排序键的写法和加了唯一排序键的写法，跑出来的结果差异一目了然。这种对比比任何文字说明都有效。
6.3 贡献路径要短，第一次提交不能超过一天
如果希望外部开发者参与共建，第一条要解决的问题不是"怎么吸引人"，而是"第一个 PR 怎么在一小时内提出来"。具体做法是维护一批标记清楚的入门任务：文档错别字、示例补充、边界测试用例、错误信息优化。每个任务都要写清楚改哪个文件、怎么验证、参考哪个已有实现。
我个人在实际操作中的体会是，新人第一次贡献的体验决定了他会不会来第二次。如果第一个 PR 卡在代码规范、CLA 签署、CI 配置上超过一天，绝大多数人就不会有第二次了。所以把 CI 做到"提交即出结果"，把规范检查做成自动修复，把评审响应时间压到 24 小时以内，这三件事的优先级比写多少宣传材料都高。
7. 把这四条主张变成可执行的路线图
回到最初那个问题：四条主张怎么落地。我现在给团队的版本是这样的——内核层先保证可观测和可修改，具体到能出调试包、能打补丁、关键路径有指标；兼容层按语法、语义、协议、生态四层分别验收，其中语义层必须用真实流量回放来验证，不能只靠静态审查；工程层把故障演练脚本化纳入常规回归，每次版本升级必跑；生态层从文档和示例入手，把第一次上手时间压到五分钟，把第一次贡献时间压到一天。
这几件事之间还有一个容易被忽视的先后关系：可观测性必须早于性能优化。没有指标就优化，等于闭着眼睛调参数，改好改坏全凭运气。我见过团队花两个月重写存储引擎的合并逻辑，上线后性能没变化，因为真正的瓶颈在日志刷盘上，而他们没有指标能看出来。
还有一个反直觉的经验：不要一开始就追求全场景兼容。全兼容的成本是指数级的，而收益集中在那 20% 的高频语法和语义上。我的做法是先划定一个明确的兼容边界，边界外的东西直接报错并给出迁移建议，比模棱两可地"支持一部分"要好得多。报错至少是确定的，模棱两可会让使用者反复试探，最后失去信心。
至于分布式能力，我的建议是能单机解决的不要上分布式。分布式带来的复杂度是持续的，不是一次性的：每次扩容、每次故障、每次版本升级都要重新面对。只有当单机的容量、吞吐或可用性确实到顶了，再考虑跨分片。这个判断标准写下来很简单，但在实际项目里，因为"未来可能会增长"而上分布式、最后被复杂度拖垮的案例，我见得太多了。
