慢 SQL 是 MySQL 运维中较为常见的性能问题之一。很多人第一次接触慢查询分析工具时，不太清楚应该做什么。
慢 SQL 排查通常有一个比较固定的顺序：
1. 确认数据库是否持续产生慢查询
2. 找到出现频率最高的 SQL 类型
3. 查看具体 SQL 样本
4. 分析执行计划
5. 判断是否需要优化 SQL 或增加索引
针对以上流程，NineData 社区版提供了完整的慢查询分析能力，可以把这些流程集中在一个界面中完成。下面按照实际排查流程，走一遍完整的操作路径。
一：准备 MySQL 慢查询日志
任何慢查询分析工具都依赖 MySQL 的慢日志。如果数据库没有开启慢日志，工具也不会有数据。
先确认当前配置：
| Plain Text SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'log_output'; |
|---|
如果没有开启，可以执行：
| Plain Text SET GLOBAL slow_query_log = 1; SET GLOBAL log_output = 'TABLE'; |
|---|
为了更容易看到样本，也可以设置：
| Plain Text SET GLOBAL long_query_time = 1; #查询超过 1 秒记录为慢查询 SET GLOBAL log_queries_not_using_indexes = 1; #未使用索引的查询也会记录 |
|---|
如果希望配置在 MySQL 重启后仍然生效，可以执行：
| Plain Text SET PERSIST slow_query_log = 1; SET PERSIST log_output = 'TABLE'; |
|---|
慢查询记录会写入到 mysql.slow_log 中。
二：部署 NineData 社区版
社区版通过 Docker 单机部署，建议配置是 4 核 16G 内存 200GB磁盘。
然后用下面这条命令把服务拉起来即可：
| Plain Text docker run -p 9999:9999 --privileged \ -v /opt/ninedata:/u01 \ --name ninedata \ -d swr.cn-east-3.myhuaweicloud.com/ninedata/ninedata:<当前版本> |
|---|
三：接入 MySQL 并开启慢查询采集
登录 NineData 控制台后，先录入 MySQL 数据源。
MySQL 慢日志准备好之后，下一步不是先看报表，而是先把目标 MySQL 数据源录入 NineData 控制台。
然后单击数据库 Devops > 慢查询分析。
在慢查询分析页签里，找到目标数据源，把慢查询采集开关打开。
这一步如果出现提示信息，按照页面提示的内容排查。
四：先看慢查询趋势
第一次分析慢 SQL 时，不建议先查看单条 SQL。
更重要的是先确认：
• 慢查询是否突然增加
• 是否集中在某个数据库实例
NineData 的慢查询大盘会展示最近一段时间的慢查询趋势。
这一步的目标是先确定问题主要来自哪个实例。
五：通过 SQL 模板定位高频问题
进入慢查询详情页后，列表并不会先展示 SQL，而是先按 SQL 模板 聚合。
不同参数的 SQL 会归为同一个模板。这样可以更容易发现哪些查询模式在持续产生慢 SQL。 排查时重点关注：
• 出现次数最多的 SQL 模板
• 执行时间较长的 SQL 模板
• 是否同一类 SQL 持续进入 slow log
六：使用诊断功能判断问题类型
在慢查询详情页里，NineData 支持对 SQL 模板和具体 SQL 样本查看诊断优化。
诊断结果可以帮助判断问题类型，用于判断优化方向。
七：回到 SQL 窗口分析执行计划
确定需要优化的 SQL 后，可以在 SQL 窗口执行：EXPLAIN <SQL语句>。
重点查看：
• 是否使用索引
• 是否存在全表扫描
• 是否出现 filesort 或 temporary table
根据分析结果，可以通过新增索引、改写 SQL、调整查询条件等方式优化 SQL。
写在最后
NineData 的查询分析的作用不是替代分析，而是帮助更快找到问题 SQL。真正的优化仍然需要结合执行计划、索引设计和业务查询逻辑。
