慢SQL治理经验总结
增量慢SQL治理
我们希望增量慢SQL能在上线前得到解决，即分支内不要引入慢SQL或者风险SQL，所以结合3.2和3.3，我们建立了开发环境下增量慢SQL发现机制，并建立发布前卡点能力。整体流程如下：
增量慢SQL的修复代价是小于存量慢SQL的，因此这里我们添加了分支定位的能力。同一应用存在多个同学共同开发的情况，有效的分支定位，可以准确指派慢SQL引入人，实现快速推动治理。这里以git上代码改动为切入点，完成了引入慢SQL的sql_map与修改人之间的关系映射，大致逻辑如下：
a. 监听应用部署消息
b. 获取应用信息，拿到git地址
c. 将本次部署分支与master分支做分支diff
d. 解析sql_map文件，获取本次修改的sql内容
e. 记录被修改sql_id与分支的对应关系
f. 根据sql_id查询对应分支
……
这样就可以精准匹配到增量SQL的引入分支，从而指派到开发者，实现了定向问题指派和追踪，并且可以方便完成分支发布前的管控能力。如果存在增量慢SQL，分支发布，合并到master之前，会触发卡点，需要问题解决才能发布。
安全生产环境慢SQL治理
安全生产环境(SPE环境)，是集团层面为保障线上稳定性的灰度流量生产环境，安全生产环境执行过的慢SQL，在线上流量放大后，可能会对DB造成过大的压力。我们额外新增了安全生产环境慢SQL的管控，作为开发环境下SQL被引入到线上的最后一道防线。
总结
慢SQL可能引起很严重的系统性能问题，影响系统可用性和稳定性，因此，及时发现和治理慢SQL是十分重要的。我们建了一套完整的慢SQL发现-分析-推动治理的机制，极大减少了由慢SQL引发的系统问题。同时，在db稳定性上，我们还额外关注数据库CPU使用情况、活跃会话数情况等，建立及时的风险预警和快恢机制，第一时间解决数据库风险。