国产数据库吹了十年，为什么你还是在用MySQL？

去年接了一个旧系统改造的活。甲方要求把一套跑了快九年的Oracle库存系统迁到某个国产数据库上。我当时想，SQL标准不都差不多？官方文档里兼容性也写的很好，应该是个体力活。结果干了两个月，最大的问题不是慢，而是以前在Oracle里很自然的写法，到国产库里就变得“别扭”。

举几个具体的例子：Oracle里空字符串直接当NULL处理，MySQL却把''当成一个真实的值，这个行为直接导致用户导入Excel时一堆空行变成了脏数据。还有日期函数TRUNC和DATE_FORMAT，看起来都能截断日期，实际边界时刻完全不一样。这些不是性能问题，是你在设计表结构时根本没意识到的行为契约。

我把这类问题叫做"默认路径"。传统Oracle的默认路径是共享一切：RAC集群用Cache Fusion做缓存融合，默认块大小8K，段空间自动管理，索引聚簇表绑定度极高。你的SQL不需要考虑数据在哪个节点，也不用关心锁是哪一层的。而MySQL的默认路径是异步复制加主从切换，默认引擎InnoDB里那个插入缓冲，对普通二级索引的插入顺序有强烈的偏好。写进去和查出来都更快，但如果你把数据库从Oracle迁到MySQL，原先设计的索引顺序往往失效，因为物理组织和可见性规则变了。

到了TiDB这类新分布式数据库，默认路径直接从"行"变成了"区间"。TiKV底层把数据切成了Region，每个Region大小默认96MB，通过Raft复制日志做副本一致性，事务则用基于PD的全局时间戳跑两阶段提交。听起来很科学，但真正写业务代码的时候，你会发现热点行写入会打到同一个Region，产生分布式数据库特有的单点压力。你以为把单库拆成了云原生无状态，结果还是需要理解数据分布才能设计表结构。换句话说，每一代数据库都在重塑你的心智模型。

我发现真正让人“留恋”传统数据库的不是功能多少，而是它的行为惯性。Oracle那套默认锁策略、回滚段管理、只读备库、物化视图刷新，能让你用一种非常稳定的思维去安排任务。而国产替代最难的地方不是技术指标，是需要把十年来积累的运维习惯、SQL写法、排障流程全部推翻。之前做压测时，国产库TPC-C跑起来不比Oracle差，但稍微加几个存储过程循环，性能就掉得厉害，因为优化器对过程化SQL里的绑定变量和谓词推导处理逻辑完全不同。

说了这么多，我并不觉得国产软件没希望。相反，我觉得它们是真正的机会，但机会在构造兼容层的生态上。如果所有替代产品都去对标Oracle的参数和方言，那永远慢一步。按我的观点，基础软件的本质不是一套功能集合，而是一套“底层选择偏好”。你迁移数据库，迁移的是数以千计的隐蔽行为，而不是数据文件。真正想要赢，别和Oracle比谁更复杂，而是比谁更愿意承认自己的行为边界，然后把不兼容的地方暴露在工具链里。这比宣称99%兼容重要得多。

最后说个趋势吧。我的预感是，未来的基础软件不会再有绝对的"通用型"，而是每个云厂商都有自己的半兼容产品。原因很简单：可观测性和控制面已经开始取代底层算法，成为最值钱的资产。真正的大厂根本不需要让数据库看起来像MySQL，只需要让迁移工具能够自动重写SQL，把Oracle的NULL处理自动翻译成NewSQL的NULL语义，这反而能创造出独特价值。所以别再问“为什么国产库做不到”了，先问自己是否真的理解了自己正在用的那套系统，有多少行为是依赖惯性而不是道理。