在数据库国产化的时代里很多朋友染上了性能焦虑症，就怕一旦从Oracle迁移到国产数据库后性能有问题。存在这种顾虑是没问题的，因为从当前最优秀的数据库产品中迁移到任何一种其他数据库，这种顾虑都是应该有的。不过由于大多数人对性能的理解过于片面，因此某些顾虑变成了不合时宜的焦虑。因为很多人不知道该如何来评价一个系统的性能，进而无法了解我们需要用什么样的数据库系统来适配某个应用场景。
在这里我没有简单的说数据库，而是用了“数据库系统”这个词，因为性能与容量都不仅仅取决于一个RDBMS，而是一个系统性的问题。很多人正是因为对“性能”和“容量”问题的认知不足，因此产生了极大的焦虑。对于不同的应用系统与应用场景，性能的要求是不同的，性能并不等于 TPMC，也并不是等于并发访问的性能，也不等于某条特定SQL的执行效率。
这些年我遇到最多的是“TPMC焦虑症”，在他们眼里最令人焦虑的是TPMC指标。面对tpcc官网上动辄数百万上千万的数据，再看看自己的测试环境里可怜的几十万的指标，感到十分沮丧。前阵子有朋友和我说，他们目前十分难焦虑国产数据库测试的事情，因为在他们的环境中，无论如何优化都跑不出数据库厂商标称的TPMC。他们担心这是否会引起他们的系统上线后，性能无法达到要求。
实际上TPMC仅仅是一种基准，如果要在一个环境中跑出超高的指标，那么需要对系统做各种配合TPMC场景的优化，而这种场景往往与用户的应用场景无关，因此TPMC指标的高低并不说明今后你的系统性能就会好。节前和一个用户聊天，他就说一些国产数据库好像TPMC也不见得比Oracle差，不过用起来感觉应用性能差了不少，就是这个原因。
另外一个我们需要了解的是TPMC官方发布的指标与我们或者某个数据库厂商自己跑出来的TPMC完全没有可比性，因为官方的TPMC指标的判别标准十分严格，对每个交易的延时都有要求，而我们的测试很难达到如此苛刻的要求，甚至不知道还有这些要求。
另外一个需要我们注意的是，实际上大多数系统并不需要如此高的TPMC。比如说某个银行需要实现每秒钟3000笔核心交易，如果我们认为核心交易与BENCHMARK测试的场景消耗类似的话，那么折算成TPMC，大约是18万，哪怕高峰期是平均值的5倍，也不到100万。是不是看上去很LOW呢？实际上这可能就是我们的真实需要。
既然数据库的性能并不能通过TPMC很好地表现出来，那么我们该如何看待数据库的性能呢？实际上对于大多数应用系统来说，并发事务的性能都不是个问题，我们应该把目光放到其他的一些方面。比如：从Oracle迁移过来的兼容性与数据安全性；系统部署与配置的简易性；系统高可用方案的完备性与可靠性；系统备份恢复的便捷性与可用性；异构数据库之间数据交换的支持能力；字符集与时区的准确性；与云平台的IT基础设施的适配性；数据库运维的可观测性；等等，等等。
除此之外，如果我们的应用确实对SQL的响应时间特别敏感，比如一些关键的交易型业务，如果类似TPMC的并发交易能力不是问题，那么其他一些数据库的基本性能，可以关注一下。
首先是单表全表扫描的效率，包括并行扫描和串行扫描的效率。全表扫描是应用系统中很常见的操作，也是数据库中最简单的操作，这个扫描性能基准能否满足你的一些业务需求十分关键，因为在某种硬件条件下，这个基准是无法提升的。因此这个指标一定要能够达到你的应用的及格线要求。在测试这个性能指标的时候，要注意测试串行扫描与并行扫描，并对不同的并发度做一个全面的测试。不同的数据库，因为并行扫描的算法优化不同，以及存储引擎的不同，这方面会有较大的差异。
其次是批量输出数据的效率，这也是应用系统中经常有的场景，逻辑数据导出就是其中的一个场景。数据导出也需要测试串行和并行两种情况。不同的硬件环境，甚至网络环境都会有很大的差异，因此在做这个测试的时候要确保硬件环境没有成为瓶颈。
第三是各种表连接的执行计划与执行效率。大多数多表连接最终都会转化为双表连接，找出应用中最常用的表连接方式，一一进行测试，确定每种连接方式都能用正确的执行计划执行，并且效率都能达到你的应用的需要。在做这项测试的时候，数据最好使用你自己的生产数据或者生产数据的脱敏和模拟数据。
第四种是HINT/OUTLINES的能力测试，HINT是复杂应用系统不可或缺的基础能力，如果你的业务系统较为复杂，数据量也很大，经常有多张表关联的SQL，而选择的数据库产品不具备这个能力，或者这个能力不足，那么就要慎用。我们早期在使用Oracle的时候，也经常需要用HINT或者Outlines来纠正错误的执行计划，目前的大多数国产数据库的优化器没有Oracle那么高效，当出现错误的执行计划不能用表分析来解决或者表分析后也依然存在问题的时候，必须用HINT来解决问题，否则就必须拆分和改写SQL语句才能解决问题了。
实际上数据库系统的性能与容量除了与数据库本身有关外，还与数据库运行的环境有很大的关系，服务器、网络、操作系统等都是影响性能的重要因素。因此如果发现了某些测试无法满足要求，那么我们还可以考虑在你们的企业IT投资规模允许的前提下，是不是可以通过提升底层性能来解决当前测试时无法达到的一些性能指标的问题。有些时候数据库产品本身的性能不足，还是可以通过其他方式来弥补的，综合成本可能是我们更需要考虑的成本要素。
