一 为什么要做这个事情
1 什么是慢SQL？
这里指的是MySQL慢查询，具体指运行时间超过long_query_time值的SQL。
我们常听常见的MySQL中有二进制日志binlog、中继日志relaylog、重做回滚日志redolog、undolog等。针对慢查询，还有一种慢查询日志slowlog，用来记录在MySQL中响应时间超过阀值的语句。
大家不要被慢查询这个名字误导，以为慢查询日志只会记录select语句，其实也会记录执行时间超过了long_query_time设定的阈值的insert、update等DML语句。
# 查看慢SQL是否开启 show variables like "slow_query_log%"; # 查看慢查询设定的阈值 单位:秒 show variables like "long_query_time";
对于我们使用的AliSQL-X-Cluster即XDB来说，默认慢查询是开启的，long_query_time设置为1秒。
2 慢查询为何会导致故障？
真实的慢SQL往往会伴随着大量的行扫描、临时文件排序或者频繁的磁盘flush，直接影响就是磁盘IO升高，正常SQL也变为了慢SQL，大面积执行超时。
去年双11后，针对技术侧暴露的问题，菜鸟CTO线推出多个专项治理，CTO-D各领一项作为sponsor，我所在的大团队负责慢SQL治理这个专项。
二 要做到什么程度
1 怎么来衡量一个应用的慢SQL严重程度？
微平均
sum(aone应用慢SQL执行次数) ----------------------- sum(aone应用SQL执行次数)
我们认为，该值越大，影响越大；该值越小，影响可能小。
极端情况就是应用里每次执行的SQL全是慢SQL，该值为1；应用里每次执行的SQL全不是慢SQL，该值为0。
但是这个指标带来的问题是区分度不佳，尤其是对SQL QPS很高且大多数情况下SQL都不是慢查询的情况，偶发的慢SQL会被淹没。
另外一个问题，偶发的慢SQL是真的慢SQL吗？我们遇到很多被慢查询日志记录的SQL，实际上可能受到其他慢SQL影响、MySQL磁盘抖动、优化器选择等原因使得常规查询下表现显然不是慢SQL的变成了慢SQL。
宏平均
sum(慢SQL 1执行次数) sum(慢SQL n执行次数) ----------------- + ------------------ sum(SQL 1执行次数) sum(SQL n执行次数) --------------------------------------- n
这个算法建立在被抓到的慢SQL有一定执行次数的基础上，可以减少假性慢SQL的影响。
当某些应用QPS很低，即一天执行SQL的次数很少，如果碰到假性SQL就会引起统计误差。
执行次数
sum(aone应用慢SQL执行次数) ----------------------- 7
统计最近一周平均每天的慢SQL执行次数，可以消除掉宏平均带来的假性SQL问题。
慢SQL模板数量
以上维度均有个时间限定范围，为了追溯慢SQL历史处理情况，我们还引入了全局慢SQL模板数量维度。
count(distinct(aone应用慢SQL模板) )
2 目标
核心应用：解决掉所有的慢SQL
普通应用：微平均指标下降50%
3 CTO报表
以CTO-D为单位根据以上多维度指标统计汇总应用的加权平均，由低到高得出排名，突出头尾top3，每周播报。
三 为什么由我来做
猜测可能与我的背景有关，有C/C++背景，曾在上家公司负责过公司层面异地多活架构的设计和落地，对于MySQL比较了解一些。
另外可能是利益无关，我所在小团队业务刚起步，不存在慢SQL，这样可以插入到各个业务线去。
四 行动支撑
1 集团MySQL规约
索引规约摘录部分：
【强制】超过三个表禁止join。需要join的字段，数据类型保持绝对一致；多表关联查询时，保证被关联的字段需要有索引。
说明：即使双表join也要注意表索引、SQL性能。
【强制】在varchar字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度。
说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为20的索引，区分度会高达90%以上，可以使用count(distinct left(列名, 索引长度))/count(*)的区分度来确定。
【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。
说明：索引文件具有B-Tree的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。
【推荐】防止因字段类型不同造成的隐式转换，导致索引失效。
【参考】创建索引时避免有如下极端误解：
1） 索引宁滥勿缺
认为一个查询就需要建一个索引。
2） 吝啬索引的创建
认为索引会消耗空间、严重拖慢更新和新增速度。
3） 抵制唯一索引
认为唯一索引一律需要在应用层通过“先查后插”方式解决。
2 DB变更标准
DDL需要控制变更速度，注意灰度和并发控制，变更发布需要在规定的变更发布窗口内。
