飞利浦·斯塔克|慢 SQL 治理分享( 三 )

判断执行计划采用的索引长度：key_len的长度计算公式(=5.6.4)
char(10)允许NULL = 10 * ( character set：utf8mb4=4utf8=3gbk=2latin1=1) + 1(NULL)char(10)不允许NULL = 10 * ( character set：utf8mb4=4utf8=3gbk=2latin1=1)varchr(10)允许NULL = 10 * ( character set：utf8mb4=4utf8=3gbk=2latin1=1) + 1(NULL) + 2(变长字段)varchr(10)不允许NULL = 10 * ( character set：utf8mb4=4utf8=3gbk=2latin1=1) + 2(变长字段)int允许NULL = 4 + 1(NULL)int不允许NULL = 4timestamp允许NULL = 4 + 1(NULL)timestamp不允许NULL = 4datatime允许NULL = 5 + 1(NULL)datatime不允许NULL = 5 3 被人影响
用到了索引却依然被爆出扫描2千万行：

索引字段区分度很高：

同时期常规SQL变为了慢查询：

DB数据盘访问情况：

排查共用物理机其他实例的情况，发现有个库在问题时间附近有很多慢sql需要排序，写临时文件刚好写入了2GB：

多个MySQL实例leader节点混合部署在同一台物理机，虽然通过docker隔离了CPU、MEM等资源，但目前还没有做到buffer io的隔离。

4 无法解决
通过汇总分析高频的查询并结合业务得出合适的索引往往能够解决日常遇到的慢查询，但这并不是万能的。
比如有可能索引越加越多，乃至成了这样：

有些场景，比如支持多个字段组合查询，又没有必填项，如果都要通过索引来支持显然是不合理的。

查询场景下，将区分度较高的字段设定为必填项是个好习惯；查询组合很多的情况下考虑走搜索支持性更好的存储或者搜索引擎。
六日常化处理随着各个CTO-D线的深入治理，各项指标较之前均有非常大的改观，比如核心应用完成慢查询清零，影响最大的一些慢SQL被得以解决，而我所在的团队排名也由最初的尾部top3进入到头部top3 。
慢SQL治理进入日常化，通过每周固定推送慢SQL工单、owner接手处理、结单，基本形成了定期清零的习惯和氛围，慢SQL治理专项也被多次点名表扬。
七小结这是一篇迟到的总结，现在回头看觉得这里面的策略制定、问题分析和解决的过程还是蛮值得拿出来和大家分享下。
作者 | 史伟民
本文为阿里云原创内容，未经允许不得转载。