慢查询解决思路

目标

稳定性治理专项

不在sql白名单里的需求，具体要求

数量目标：

要求sql慢查询降低, ,各个项目，慢查询每周不能出现超过3个不同类型慢查询sql。

每个数据库的慢查询总数不能查过X哥， 总的慢查询耗时不能超过Ys。

解决效率目标：

项目周期内：

当日提出技术方案，改造完成，提测，并且明确测试时间以及上线时间， sql负责人来R。

项目结束后：

核心功能关联sql：当日提出技术方案，给出明确的排期时间

非核心功能关联sql:  给出明确的排期以及负责人。

现状

当前每日慢查询200左右（不准确统计，待DBA验证），分为如下几类：

1. 索引创建不当：
1. 无索引
2. 未命中索引
3. 索引区分度不高
2. 关联查询
1. 报表类
2. 核心功能类
3. 非核心功能(不包含报表)
3. 数据量过大
1. 表中数据超过3000万
4. 外部影响
1. 其他查询导致数据库性能降低，引发了慢查询
2. 其他非业务原因导致的数据库问题，引发慢查询
1. 机器的系统升级？
2. 网络延迟

实施路径

发现问题

1. 慢查询日报表(1ms→ 500ms )
1. 现阶段人肉维护，希望dba工具化
2. 表信息扫码
1. 表结构，索引，字段合理性
2. 数据量
3. sql排查
1. 扫描项目中的join,  like,。（P1）
2. 排查循环调用， 通过sql的调用量排查。（P0）
3. 排查sql中的事务， 确认是否有大事务。（P0）
4. mapper中的条件组合梳理，一个sql干一类事情（工作量较大P2）

解决问题

通用解决方法

1. sql优化类
1. 添加索引
2. 调整sql, 命中联合索引
3. sql拆分，一条拆分成多条
4. 批量查询，循环改为批量
5. 最小结果集：查询列数最少，查询行数最少
6. 缓存，降低sql 查询频次
7. 避免大数据集的聚合
8. 查询中不能没有where或者条件仅有 1=1
2. 数据库优化
1. 分库分表
2. 是否需要扩容
3. 物理隔离
1. 业务隔离
2. 复杂查询隔离--报表独立从库
3. 业务优化
1. 业务流程调整，避免或者减少查询
1. 流程优化，减少复杂逻辑
2. 防止重复提交
2. 业务调整，功能的使用频率以及必要性

 

 

慢sql解决流程图（待补充）

排查慢查询->业务使用场景是否合理->有没有其他的实现方式->索引是否命中->索引区分度适合够->数据量是否过大。

预防问题

1. dml规范以及review
2. 代码review机制，出来规范， 
3. 监控告警
1. 慢查询监控告警
2. 数据库服务指标监控告警，
3. 主从延迟报警

诉求

1. 提供按日慢查询统计报表： 邮件和查询工具均可。
2. 数据库性能分析工具： 用于日巡检使用。
1. cpu
2. 内存
3. io
4. 网络
5. qps
6. tps
7. wps
8. 数据延迟情况
3. dba支持最大结果集1000限制 （将来要实现）。
4. 耗时超过5秒， 自动kill, 同步消息给业务方（未来要实现）。

执行优先级

待补充讨论

报表独立从库

 

待整理

TODO, EC那边存在强制走主库的方式，可能会先包一个事物。我们的业务需要check.

本月对saas功能定级跟产品一起确定大事务的日志，可以找dba一起排查确认阿里云的功能， 具体能够给我们提供哪些数据和报表

 

对dba的诉求1. 慢查询日报，其他性能报表2. 是否需要扩容3. 拆分的参考依据

sql 排查中，关注order by

sql注入的风险

执行计划

日期	目标	备注
日期	目标	备注
2019-10-14	制定明确的慢查询解决办法并讨论 done 排查验证13号慢查询的解决情况， done 查看14号上午的慢查询 done 了解阿里云提供的数据库功能。未完成	慢查询数据不准确，需要dba更大的支持 大事务目前还不太清晰， 目前仅有钉钉报警
2019-10-15	梳理报表的短期解决方案以及执行计划 done。 整理15号慢查询报表 done。 解决P2中>100次的慢查询 ing。	明天中午提测报表优化 慢查询报表存在问题，需要讨论，应该拉DBA一起讨论
2019-10-16	跟dba沟通，排查大事务 分析500ms以上的慢查询 定位大表，先看1000万以上的
总体	制定慢查询标准：控制每个数据库的总数， 总的秒数控制 对功能进行分级，按照功能的优先级来区分关键和非关键，依赖关键流程梳理