MySQL慢日志平台优化设计

这是学习笔记的第 1959 篇文章

 在之前做了第一版的慢日志平台

在这个基础上，想把慢日志的优化工作做得更透一些，需要对原来的慢日志信息从展示升华到优化建议，整体设计行做了如下的规划：

1．慢日志排行榜的联动

根据Query_ID得到SQL执行明细

实现：新增逻辑，根据Query_ID和基础信息（IP, port）实现指定时间范围的快照数据提取

2．列表中补充数据表的列表

可以显示SQL相关的表，根据表信息实现信息的关联

实现：根据Query_ID得到相关的table列表，在表格中显示，

3．得到表和索引的统计信息，提供优化基础

数据库的数据量变化历史

实现：查询数据库明细数据表，根据IP和端口，时间维度进行数据提取

表数据的数据量变化历史

实现：查询表明细数据表,根据IP和端口,数据库，时间维度进行数据提取

得到表结构信息和索引信息

实现：根据IP,端口，数据库，进行表结构信息提取和索引元数据信息提取

4．SQL执行计划信息查看

根据Query_ID去线上环境查看当前的执行计划信息

得到执行计划的补充信息

5．实现SQL性能历史跟踪

指定SQL的性能历史

实现：查询慢日志历史SQL表,根据Query_ID，IP和端口，时间维度进行数据提取

6．SQL性能模型和建议

是否存在冗余索引

实现：通过sys schema查询数据字典，匹配是否存在相关的表

是否存在全表扫描

实现：执行时间低于1秒以内，建议评估是否创建索引

实现：执行时间大于大于1秒以上，数据量达到一定量级，建议添加索引

慢日志关联：

实现：得到相关SQL列表

7．第三方建议整合

SOAR

SQL Advisor

8．慢日志预警

订阅慢日志报告，提供链接访问

如果把这些事情整合起来，我做了一个初版的原型。 如下是在第一个界面中点击相关的SQL之后弹出的辅助页面，页面的内容如下：

带着这个方案和前后端开发同学聊了下，发现有些细节和我们想的还是有很大的差别。 有些图表看起来不错，但是最终想表达的含义可能对于业务使用来说不是很实用，所以经过再三讨论和取舍，改进一版的原型设计如下：

总体上，SQL性能优化的雏形也算是出来了。