上周和一个数据库厂商交流的时候，我问他们最近在忙什么，他们说在抓紧开发TDE功能。我说TDE在你的客户里用得多吗？虽然Oracle的TDE功能很早就有，不过在我这二十多年的工作中，看到用TDE的案例少之又少。也许是有些客户用了TDE我也没有关注吧，在我印象里遇到的用户使用TDE的案例大多数都是与痛苦不堪的数据拯救案例相关的。给我留下最深印象的是一家企业的HR系统把几千个员工账户信息和薪资、奖励绩效信息存储在开了TDE的表空间里了，最后除了这些表之外其他数据都恢复了，而这些最为重要的数据无法恢复。

　　厂家听到我的回答，无奈的笑了笑，如果我们的数据库没有TDE功能，就怕招标时候被人挖坑啊。确实是的，在国产数据库如此内卷的今天，如果你的数据库里有一个哪怕是有一个八百年都不会被企业使用的功能，也有可能会在招标时被一票否定。前阵子帮一家企业做信创数据库对比测试时，甲方的研发单位提出来需要把目标数据库是否具有类似Oracle的profiler功能作为测试评价模型中的一项。不知道是这位甲方大佬是否看过我的书，在我的《Oracle DBA日记》里讲过这个案例之前，估计绝大多数Oracle用户和DBA恐怕都不知道Oracle还有这个功能，而目前常态化在使用profiler做存储过程性能分析的客户我还真的没有看到过。这不禁让我腹黑起来了，是不是某个国产数据库已经开发出了类似的工具呢？

　　经常有朋友问我一些关于数据库选型的事情，数据库选型的事儿，如果只从简单的了解和试用某个数据库，或者从文档中进行分析，那么得到的结论肯定是不准确的。哪怕你来问我，我也很难很客观的为你推荐合适的数据库。因为数据库选型不仅仅是一些技术因素，和你自己企业的文化、团队的水平、团队的技术积累厚度、业务系统的特点、数据量、数据类型特点、数据库运行环境、数据库备份系统的方案、业务连续性和高可用方面的要求、应用访问数据库的方式、应用访问数据库的并发量、使用的字符集、是否存在多时区、多字符集数据库之前的数据同步、DBA团队的技术积累和技术能力、DBA团队对新技术的学习能力、第三方服务的依赖程度，等等等等。我也只是列出了一部分常见的考量因素，就已经很复杂了，因此我也无法在与你数分钟的对话交流中，帮你选定你所需要的数据库产品。

　　看到这里，可能有些朋友会吐槽了，数据库选型有那么复杂吗？确实是的，不同的企业文化，不同的团队，对数据库选型合理性的容错能力是不同的，在绝大多数用户的应用场景中，数据库选型是否合理并不太重要。而且如果我们的自身技术能力不足，那么复杂的技术分析很难高质量完成，要请专业的团队来做深入的分析，又花不起这个钱，因此这项工作也没必要这么去做。

　　实际上多年前伟人就阐述过了，要知道猪肉的滋味，一定要炖一锅红烧肉来尝尝才行，其他的方法都是不靠谱的。要想知道某个数据库是否适合你使用，也只需要亲自去试一试就行了。可能有朋友要说了，我们能力不行，试不出来怎么办。实际上，你把问题看复杂了。用你自己的能力去试一试待选的数据库，才是最靠谱的测试方法。高手能把某个数据库用得很溜，不意味着你能把它用好啊。如果你自己使用这个数据库的时候感觉十分晦涩，短期内都无法入门，那么很可能说明这个数据库的使用难度太大，不太适合你。你是要选择最适合你使用的数据库，而不是去选择技术最好的数据库，是不是这个道理呢？

　　实际上如果你能接受我今天的观点，那么数据库选型也就不难了。找个待选的数据库产品，让自己的DBA根据安装手册装一套，然后开始找几张有特点的业务表做一下迁移。看看是否有比较友好的迁移工具可以帮你对老数据库进行评估，自动完成数据字典和数据的迁移。数据库表字段之间的兼容性如何，是否需要对数据字典做比较大的调整。如果你对比的是分布式数据库，那么还要看看迁移时表分区和SHARDING的定义是否很复杂，你能否接受这些复杂度。对于数据迁移，还要看起工具的覆盖面，是否存在比较友好的增量迁移方案和比较好的数据比对工具，能够对迁移前后的数据一致性进行比对。

　　完成数据迁移后，下一步就分析应用迁移的问题了。如果你使用了存储过程和大量的批处理作业，这些是否能够很好的迁移到目标数据库上。如果代码级兼容那是最好，不过代码级不兼容也没关系，是否有工具可以帮你完成整个迁移工作，或者说自动根据源数据的数据字典自动生成迁移脚本，只要使用起来不复杂，那么源代码级的兼容性是可以不太考虑的。因为数据库村村过程语法相对简单，开发人员哪怕重新学习一套新的写法，代价也不会很大。对于SQL，哪怕是兼容性很高的数据库之间，也会有一些小的差异，这是因为Oracle对SQL标准化方面一直是不太感冒的，都是大家来兼容它，它不太主动去兼容SQL标准。只要是大差不差，存在少量不兼容的语法，如果改起来不麻烦就无所谓了。

　　下一步就是性能问题了，很多朋友喜欢用TPCC来对比数据库的性能。我的观点完全相反，对于国产数据库来说，TPCC测试完全可以跳过不做，因为别人都帮你PK过了，只要是个国产数据库，就没有这个“不合格”的。其实不做TPCC测试是因为，这个测试可能真的和你的业务系统特征没半点相关。

　　实际上性能测试最主要的还是对一些基本SQL进行测试。比如常见的扫描方式：全表扫描、唯一性索引扫描、索引快速扫描、索引范围扫描、不回表和回表的索引范围扫描等，在测试这些的时候，别忘了加入并行扫描试一试，因为现代硬件CPU、IO都很强，不用并行会很亏。另外就是常见的表连接方式，各种应用中常用的表连接方式都找个把典型场景测试一下，确保执行计划和执行效率都是在你认可的范围内。

　　性能方面还有一个十分重要的特性要测试一下，那就是HINT或者其他等价的功能。这个功能在你的应用系统长期使用时十分重要，如果某些时候执行计划走错了，你可以通过这个功能来纠正一下，这方面的功能不行，那么今后运维时候就要吃大苦头了。

　　完成性能测试后，还有一个十分重要的测试内容就是高可用切换。现在所有的国产数据库都提供高可用切换的整套解决方案，如果你发现某种数据库都没有完整的成套方案，那么这个数据库技术再好你都放弃吧，因为不具备成套方案的数据库只是一个玩具，不是一个产品，连开源的MYSQL、PG都已经有十分成熟的成套方案了，一个商用数据库这方面还要像搭乐高一样手工凑一套方案出来，那说明什么呢？自己想一想就明白了。在做高可用测试的时候，我提一个小建议，那就是一定要让系统有一定的背景压力，在此情况下做切换测试才有意义。有个小技巧就是用BENCHMARK工具作为背景压力，把CPU压倒20%左右，在此情况下，进行高可用切换测试就可以了。

　　完成上述测试，对于大部分用户来说够用了，当日对于一些特殊场景要求的用户来说，还有很多方面没有测试。今天篇幅有限，我就先写到这里了。希望今天的分享能够对大家有点帮助。

原文标题：《一家馆子好不好吃不尝一下怎么知道》