京东云TiDB SQL优化的最佳实践( 二 ) _生活百科

SQL优化案例最佳实践案例一：索引的错误选择导致SQL变慢的优化实践场景：数据库迁移到TiDB ， SQL在MySQL运行不到1S ，在TiDB运行超过30S
SQL执行计划如下：

文章插图
execution info列，有该执行计划的时间，这个SQL的表的连接顺序，要从最里面的循环开始看，如下图， m,d是最先开始进行连接的：

文章插图
关注下图的time变化，执行计划由毫秒级变成了秒级的地方，由71ms变成了33s ，所以瓶颈卡在（（m join d） join taskm）join taskd 这个地方，对应的SQL片段如下：

INNER JOIN taskdON taskd.no = d.no AND taskd.o_no = d.o_no AND taskd.d_no = d.d_no AND taskd.w_no = d.w_no AND taskd.g_no = d.g_no AND IF(NULL = d.MD5_VALUE, 1, d.MD5_VALUE) = IF(NULL = d.MD5_VALUE, 1, taskd.MD5_VALUE) AND taskd.yn = 0

●优化思路1、首先观察 explain analyze 结果，看到慢在最内 3 层的 join 上， (m join d) join taskd；
2、对比 MySQL 的执行计划，发现 MySQL 最内的 3 层的 join 是 (m join d) join taskm, 所以把相关的3张表提取出来，修改其join顺序；
3、修改顺序后， join 的时间能减少但是和 MySQL差距还是很大，再次观察，发现 taskd 上TiDB和MySQL使用的索引不一样，所以使用了 use index 来强制TIDB走和MySQL相同的索引。
案例二：表关联的错误选择导致SQL变慢的优化实践场景：在MySQL运行时间毫秒级别，在TiDB运行时间18S
在TiDB的运行时间及执行计划

文章插图
优化前后的执行计划

文章插图
优化后加了hint的SQL

文章插图
● 优化思路：1. TiDB执行耗时 10+s 的原因是对 wps 表的估算不准确，导致优化器认为 w表和 p表走 hash join 效率更高，然后我们看到的执行计划的主要耗时在 pri 表回表获取数据的耗时较长；
2. w 表估算不准确的原因为TiDB 会把 w 的条件有range scan 转换点查，然后利用这个索引的统计信息去估算；
3. 点查估算是会利用对应的 CMSketch 去进行估算，结合 p 表数据量很大，根据经验推测可能是 CMSketch 内部 hash 冲突导致。
●案例一、二的延伸扩展：在SQL优化的工作中，经常会通过加hint的方式改变SQL的执行计划，从而达到了优化的目的，但是缺点是对SQL进行了硬编码，如果业务程序使用了ORM框架， SQL的改造难度会增加。SQL Binding（SPM）则很好的解决了硬编码的问题，通过SQL Binding ， DBA可以在不改变SQL文本的情况下，优化sql的执行计划，从而达到优化的目标，从而使SQL优化变得更加优雅。