这是学习笔记的第 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性能优化的雏形也算是出来了。