慢SQL处理

出现慢SQL本质：是业务对数据量增量没有感知导致。 

刚开始开发很容易功能优先，并不考虑数据量。数据量少于10W，再差劲的SQL也不慢，这就导致测试阶段不容易暴露问题，只有上线一段时间后才发现。 

解决慢SQL问题不仅仅是技术问题，是项目管理，架构，开发多方互动的过程。尤其在工作职位拆分比较细，且相互沟通不畅的组织中出现较多。

以下是个人针对避免慢SQL的解决：

开发前：
1. 做好CodeCheck，以及架构设计
2. 部分会导致慢SQL的脚本就不应该出现
3. 对于涉及数据量大的功能就应该直接控制，而非出了问题再学习
4. 方案考虑数据库对性能的影响，并设置告警预置

上线运行中：
1. 做好慢SQL的监控和分析，对数据量超过一定阈值就得进行功能上的重构和方案设计来规避
    -- 如：导入导出异步化，并控制并发数据和重复点击次数，或者读写分离
2. 做好降级准备：如果慢SQL影响核心功能，应主动断连，并做好客户端提示和后续运维
    -- 如：某功能导致SQL影响核心交付功能，那么就直接中断功能，并给予用户提示和运维告警，即使予以干预
3. 监控数据库数据量：每天或者每小时查询数据库，并跟预置进行比对

出现问题：
1. 在数据库侧查看慢SQL，并分析对应功能，有必要则进行人工干预
    -- 如：kill db查询进程，并重启服务
2. 针对出问题慢SQL功能，进行分析和重构，防止后续问题出现