开发者学堂课程【云数据库优化经典案例：参数优化】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/67/detail/1162
参数优化
参数优化有很多客户问到 madc 参数是否可以自己去配置，我们有很多的参数，比如，内存的参数和数据安全的参数，这一块基本上用户是无法配置的。
我们可以配置 tapk , sortpython,等等，按照用户应用的特点可以去配置。
（一）一个参数引发的血案
这是一个参数引发的血案，背景介绍是某客户正在将本地的业务系统迁移上云，在 rads 上运行时间明显要比线下自建数据库运行时间要慢一倍，导致客户系统割接延期的风险。
所以我们当时就要排查为什么他的本地ck，这个ck为什么在用户本地自建。
第二，跨压力式。所以我们去分析，这也是非常经典的案例。
出现这样一个情况之后，我们才去分析一个 ck 从一个平台迁移到另一个平台，那我们去看是不是发生了第一个数据库跨平台迁移，比如 PG 是不是迁移到 MySQL ，ORALCE 迁到 MySQL。
第二个去看他的版本是不是发生了变迁，MySQL 5.1版本上升到5.5版本，5.5版本上升到5.6版本。
因为这样的大版本发生变迁最终会影响 ck 的执行计划， ck 的执行计划会受限于优化器，参数配置，包括其中硬件配置的影响。所以我们可以通过以上三个点的经验来一一排查。
如果没有出现跨数据库的迁移，用户是 rads 5.6，那我们再具体对一下优化器参数，因为这个优化器最终会影响 ck 的执行计划。那我们可以看到，备了用户本地的 ck 优化器，以及云上 RADS 这个优化器，基本上没有太大的变化。这个前面两个我们就排除了。
分析 CK 的执行计划
大家可以看到这个 ck 是非常复杂的，因为他有12行的执行计划，所以我们如何快速判断这个执行计划有没有问题呢，当然我们可以通过一个简单的方法，我们可以通过每一行的 ROWS 乘起来，因为 MyCQL 的执行计划的算法是签到循环，就是 rows 这个每一行的乘积，对比这个 rows 没有太大的变化。
所以前面这个优化器的参数，执行计划的总函数也去看一下，所以前面两个排除。
第三个我们来看一下参数配置，参数配置的时候我们就发现了一些端倪，我们发现用户在配置文件，用户在对这三个参数进行特别大的调高，相对云上 RDS ，tmp-table-size=256k，但是用户他 tmp-table-size=128M，那这个就是我们很大的一个疑点，那我们把这三个参数一一的去排查。
然后我们最终发现 tmp-table-size 由256k 调整至128MB 之后，这个性能从18.17sec下降至7.29sec，所以最终这个问题是由于这个参数调回128MB 之后，他的性能就比我们云上的要快。所以说到这个ck非常非常复杂，他会产生很多临时结构机，原来的256k 已经不满足 ck 中间的转换机，所以我们这时候调到128MB 的时候就和本地的数据和机了。
所以我们出现这样一个问题之后，一个ck跨平台出现数值下降，第一个看他的执行计划，第二个看他的数据库版本和优化器规则，然后我们要去对比这个参数设置以及可能他的硬件配置。
（二）参数最佳实践
在2015年的时候，在那个双十一，他的硬件配置是一个T的内存，cp 是64核的，按理来说他的数据库的配置是非常高的，但是怎么数据库他这边怎么都压不上去，但我们去看了之后发现，他的 MyCQL 的参数用了128MB，是非常低的配置，所以他整个一个T的内存都无法去使用，所以他那个参数配置太低了，而不能把硬件的配置发挥出来，所以我们把内存参数调整了之后，他那个数据库这个 tps 上升了几百倍，所以我们要综合去看。
所以这个参数我们还要提几个点，第一个关于 Query-cache-size，那个数据库做那个安全，有些ads是关于 Query-cache ， 有些用户本地 Query-cache是打开的，这个时候很显然执行一次就缓存，但是 Query-cache 是关闭的，ck 非常强，这个时候就要关注这个 Query-cache 。
第三个，非常容易出错的是我们支持 Tokudb-buffer 这个引擎，但是没有为这个Tokudb-buffer 配 pool-ratio，所以导致这个 Tokudb 插入非常慢，那这个时候我们即用了 Temp 引擎又 Tokudb 引擎，一定要为 Tokudb 配 pool-ratio。
第四个是 Back-log，Back-log 这个短连接，这个应用一定要去了解一下，我们的数据库建立链接的这个队列，如果我们的短连接设的比较频繁，要把这个 Back-log 设的长一点。
