出现慢SQL本质:是业务对数据量增量没有感知导致。
刚开始开发很容易功能优先,并不考虑数据量。数据量少于10W,再差劲的SQL也不慢,这就导致测试阶段不容易暴露问题,只有上线一段时间后才发现。
解决慢SQL问题不仅仅是技术问题,是项目管理,架构,开发多方互动的过程。尤其在工作职位拆分比较细,且相互沟通不畅的组织中出现较多。
以下是个人针对避免慢SQL的解决:
开发前:
1. 做好CodeCheck,以及架构设计
2. 部分会导致慢SQL的脚本就不应该出现
3. 对于涉及数据量大的功能就应该直接控制,而非出了问题再学习
4. 方案考虑数据库对性能的影响,并设置告警预置
上线运行中:
1. 做好慢SQL的监控和分析,对数据量超过一定阈值就得进行功能上的重构和方案设计来规避
-- 如:导入导出异步化,并控制并发数据和重复点击次数,或者读写分离
2. 做好降级准备:如果慢SQL影响核心功能,应主动断连,并做好客户端提示和后续运维
-- 如:某功能导致SQL影响核心交付功能,那么就直接中断功能,并给予用户提示和运维告警,即使予以干预
3. 监控数据库数据量:每天或者每小时查询数据库,并跟预置进行比对
出现问题:
1. 在数据库侧查看慢SQL,并分析对应功能,有必要则进行人工干预
-- 如:kill db查询进程,并重启服务
2. 针对出问题慢SQL功能,进行分析和重构,防止后续问题出现