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

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

一为什么要做这个事情 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报表