数据库国产话这个话题已经谈了三四年了，至今依然热度不减。不过从这么高的热度上，我感受到的是数据库国产化的进度恐怕是比较慢的，因为今年大家关注的问题和前些年差别不大，都还是一些鸡毛蒜皮的事情，这些热点中最热的还是各种数据库之间，各种数据库架构之间谁好谁坏的比较。

每个人眼中都有自己的心头好，都会觉得某个数据库还行，某个不行，你的美味可能是别人眼中的砒霜。这让我想起了一句话，鞋合不合适只有自己的脚最清楚，这句话用在数据库上，就是数据库好不好，只有应用知道。

很多朋友都在研究国产数据库，其重点都集中在数据库的优点和缺点。不少在分析国产数据库的朋友都是数据库领域的专家，涉及数据库研发，运维，优化等领域。这些专家的观点都没毛病，确实没有一种数据库是完美的，连ORACLE也不例外，只是经过了三十年的演进，Oracle已经把大多数比较严重的毛病都改得差不多了。

我今天所说的观点可能会有些令人不爽，那就是说实际上很多专家的观点，仅供参考，用户真的不用太过考虑，其中也包括我这些年发表的一些观点 。因为数据库是拿来用的，而不是拿来研究和PK的。

我用的数据库流行度排名较低，技术水平较差，性能一般又如何?适合我，我的应用跑得好就行了。很多数据库存在问题的点或者其优势的地方可能和你的应用场景完全无关，那么你去关注这些点又有什么意义呢?

如果你的数据库原本就只有几百GB，几十个并发访问，那么你去比较横向扩展能力干什么?如果你的系统上跑的SQL慢个几毫秒不影响前端用户的体验，那么你为什么要为网络上几毫秒的延时而担忧呢?一个每秒钟交易不超过2000笔的系统，你重点去比较高并发下的性能衰减有意义吗?数据库只要能比较好的适配应用就可以了，不用太去关注那些极限测试下的差异。在这个问题上，我的建议是不要受到这些评测数据的影响，虽然这些很可能都是真实的，不过如果和你不相干，那么你可以完全忽略。真正需要做好的事情是把自己的常用场景，用真实数据对你的目标数据库做测试与分析。把常用的表连接方式和扫描方式都覆盖全面了。这样才能选出真正适合你的应用的数据库。

我有一个客户，最初选择数据库的时候，考虑的是必须选择具有类似RAC功能的数据库，上了某个国产数据库用了一段时间后又觉得核心系统的横向扩展能力十分重要。因此第二次选型时候选择了一款分布式国产数据库，迁移了一两个应用后发现和ORACLE的兼容性不够好，迁移成本太高。于是第三次做选型，选择了另外一款分布式数据库。前阵子和他们聊天的时候，他们也吐槽说这第三次选的数据库用起来问题也很多。我就问他们是不是准备继续选，他们说，不选了，因为有Oracle在那儿打底，选啥都不会特别满意，另外就是目前他们已经迁移了十多套系统到这个数据库上了，也都能跑起来。当初选型的时候总觉得选型很重要，实际上真正干起来了，用啥差别都不是很大，只要迁移时代码修改量可控就行了，其他以前选型时担心的问题都不是个事儿。

这个用户的经历其实是十分典型的，数据库国产化替代，想的时候都是问题，做的时候，都有方案。这句话在很多数据库国产化的大会上总会有人说起，事实上也是如此的。还是要再次强调一下前面所说的观点：“数据库好不好，只有应用最清楚”。只要数据库能够对你的应用有一个比较好的支撑就可以了，不要在意某些专家的评价。

其实一个企业做数据库选型也比较简单，首先和你的云平台、硬件平台的匹配度，一定要在你的目标平台上做相关测试，如果你们已经确定了基于ARM的国产化硬件，那么测试一定要在ARM服务器上做，因为一些国产数据库在ARM上和X86上的表现会有较大的差异。

第二点是如果你的原来用的是Oracle，那么要选择和Oracle有一定兼容性的数据库，从而减少迁移成本。迁移工具一定要完善，支持增量迁移，同时支持双向增量复制。因为核心系统迁移上线时需要有一定的并轨运行时间，也不排除临时回切的可能性。

第三点是针对数据库的基本功能进行测试，包括全表扫描、索引范围扫描、多索引下复杂WHERE条件执行计划选择的准确性，常用的表连接(重点考察执行计划)的性能、大数据量写入性能、大数据量查询性能、数据导入导出性能。

第四点是针对数据库的常用功能进行测试，根据你的应用特点，这个测试的范围可能不同。包括统计函数、存储过程、参数、特殊索引类型、物化视图、序列号、增量备份、透明数据加密、数据恢复功能等。

第五点是针对优化器修正能力的测试，比如hint、outlines 、spm等功能。因为优化器不总是能够自动选择正确的执行计划的，错误的执行计划对系统的危害很大，因此目标数据库在其他功能上可以将就，而在这方面不能将就。否则今后你的应用开发和运维都会面临很大的挑战。对于hint,outlines的测试不能仅仅限于有没有这个功能，而是一些常用的功能是否具备，并且能用。比如修改表连接的方式，PUSH/NOPUSH子查询，强制指定索引等。

数据库测试时的关注点还有很多，我今天只列出了五个必须覆盖的方面。如果你的系统比较简单，数据量也不大，那么实际上选择一个你们喜欢或者你们领导喜欢的数据库产品，开干就行了。如果你的系统比较复杂，今后数据量也是10TB以上级别的，那么根据你们应用的特点，以及你们开发团队的SQL编写习惯，做一些针对性的测试就可以了。对于超高并发、超大数据量、HTAP特性很强的应用的数据库选型，那肯定很复杂，而这些企业往往能够在测试与研发上投入巨资，这些系统反而不大会出现选型难的问题。

都已经进入2024年了，从2018年数据库国产化起步以来，已经进入第七个年头了，今年我希望看到更多如何在数据库国产化过程中解决遇到的问题，或者说国产数据库在应用中如何优化的案例，而不是还在不厌其烦的讨论数据库选型的事情，PK哪个数据库在哪方面更为优秀，期望我的愿望能够实现。