数据库市场最近很热闹。
每隔一段时间，就有一家厂商站出来说自己跑分全球第一。然后另一家站出来说兼容性业界最高。再然后又一家说迁移速度最快、两周上线。
发布会一场比一场盛大，PPT 一版比一版好看。
然后你的 DBA 顶着两个黑眼圈来找你，说迁移又卡住了，这次是存储过程不兼容。
我最近整理了一份数据仓库建设解决方案，里面详细梳理了企业从数据采集、数据建模、数仓分层、数据治理到分析应用建设的完整路径，对于正在推进数据库国产化、数据平台建设或者经营分析体系升级的企业，可以参考其中的数据架构设计思路，需要的可以自取：https://s.fanruan.com/7igmg（复制到浏览器）
一、先说清楚，跑分在测什么
TPC-C、TPC-H，这两个名字在数据库发布会上出现的频率，快赶上产品名本身了。
但你知道这两个基准测试是哪年定义的吗？上世纪九十年代。
用三十年前定义的标准，来测今天的分布式数据库，然后拿这个结论来指导你的选型决策——这件事，逻辑上就有点奇怪。
跑分在测什么？标准化场景下的吞吐量峰值。
跑分没在测什么？你的业务 SQL 在这个库上跑得怎么样。高并发写入时稳不稳。运维团队能不能驾驭得了。和你现有系统的集成难度。
买数据库的钱，是真实的。跑分的场景，不是你的生产环境。
跑分是给采购汇报用的。你的线上系统，不跑基准测试。
二、「兼容 99%」那剩下的 1%，藏在哪里
「全面兼容 Oracle」，这句话在国产数据库宣传里出现的频率，大概仅次于「自主可控」。
99.9% 兼容。听起来只差一点点。
但你有没有想过，那 0.1% 或者 1%，具体是什么？
是那些写了十几年、几千行的存储过程，里面用了 Oracle 特有的包和游标写法。
是隐式类型转换的边界行为——Oracle 对类型转换极其宽松，换个库之后，一些原来"能跑"的 SQL，行为悄悄变了。
是 NULL 值的处理逻辑，是分区表的细节策略，是字符集在中文环境下的排序规则。
每一个单独看都不大。但它们有一个共同特点：藏得最深、影响最核心的业务逻辑。
「兼容 Oracle 99%」的准确翻译是：「在我们自己的测试集上，99% 的 SQL 能跑通。」
你的核心业务逻辑在不在那个测试集里，没人知道。
这不是在黑某家产品。这是每一家宣称高兼容的数据库，都绕不开的客观现实。
唯一能验证兼容性的方式，不是看白皮书，是把你自己的数据和业务跑一遍。
三、「两周迁移上线」，有几个前提没说
两周。十四天。把一套运行了十年的 Oracle，迁移到国产数据库，上线。
我没有说这不可能。我只是想问几个问题。
你们有多少张存储过程需要重写？数据量是多少？有几套上层应用需要同步改造？
迁移的时间成本，不在「把数据从 A 搬到 B」。那个，确实可以很快。
真正耗时间的是应用层改造——ORM 配置、SQL 方言差异、连接池参数、超时行为。
是切换窗口的处理——新旧库并跑期间，数据一致性怎么保证？增量怎么同步？切换那一刻数据差了怎么办？
是性能调优——换了数据库，原来的索引策略不一定适用，执行计划要重新看。
「两周迁移」能成立的前提：数据量小，SQL 简单，应用架构干净，团队经验丰富，而且提前做了充分测试。
这些前提，发布会上不会说。
四、真正没人讲的问题：数据库换了，数据怎么接着流？
跑分、兼容率、迁移速度，这些是数据库厂商喜欢比的维度。
但有一件事，他们几乎从来不讲——
数据库换了之后，数据怎么接着流？
真实的企业 IT 环境，不是只有一个数据库。
Oracle 里的订单数据，要同步到 MySQL 的报表库，还要推一份到 Kafka 供下游消费，再汇进数据仓库做分析。
你换了数据库，这条链路，是断的还是通的？
迁移期间新旧库并跑，增量怎么同步过来？切换窗口里产生的数据差异怎么补齐？切完之后，下游那些依赖旧库的管道，指向新库了吗？
这是迁移项目里最容易翻车的地方。不是数据库本身出了问题，而是数据库和周围系统之间的管道，断了。
发布会 PPT 上没有这一页。
五、这就是为什么，选库的同时要选集成工具
一次完整的数据库迁移，至少需要四件事同时做好：
把历史数据从旧库搬到新库，一行不丢，一行不错。
迁移期间旧库还在跑业务，增量要实时同步过来，不能断。
迁完之后，新旧库的数据要逐行比对，确认一致，有差异立刻发现。
切换之后，原来从旧库往下游推数据的所有管道，要无缝接上新库，继续跑。
这四件事，数据库厂商的产品通常只解决第一件。
后三件，他们不管。
我们在迁移测试中用了FinedataLink 5.0来承担后三件事。
Oracle 这边走 LogMiner 解析变更日志，实时同步到新库，延迟在秒级，对源库几乎没有侵入。迁移窗口期间，新旧库数据持续比对，有偏差自动标记。切换之后，不管目标是达梦、人大金仓还是 ClickHouse，下游的数据管道不用重建——FinedataLink 5.0原生支持这些库，配置改一下，链路继续跑。
这不是在做广告。这是说，数据库选型和数据集成工具选型，是同一个决策的两面。
只看前者，不想后者，迁移项目出了问题大概率不是数据库的问题，而是这个问题的问题。
六、下一轮，希望大家卷这些
我真心希望数据库厂商的下一轮竞争，能从跑分和兼容率，转移到更实质的地方：
和主流数据集成工具的生态适配程度怎么样？
迁移过程中的数据一致性保障机制是什么？
出了问题，支持团队的响应速度和解决能力如何？
国产化场景下，和信创软硬件栈的真实兼容程度，有没有完整的验证报告？
这些问题的答案，不适合上 PPT，但会在你的生产环境里如实呈现。
买数据库，不是买跑分。买的是接下来五年，你的数据能不能稳定地从 A 流到 B，一直流下去。
