NineData社区版：先跑通 SQL 审核，更要做好慢 SQL 持续治理

很多团队一提数据库 DevOps，第一反应就是先把 SQL 审核跑起来。

工单有了，审批有了，权限有了，变更可追溯了，看上去该有的都有了。

但问题并没有因此消失。线上慢 SQL 还是在反复出现，DBA 还是每天被拉去排查，后端还是隔一段时间就会问一次：“这条 SQL 怎么又慢了？”

这时候团队才会意识到，自己原来只补上了数据库 DevOps 里的一半。

因为审核解决的是“别乱改”，慢 SQL 治理解决的是“已经慢了怎么持续处理”。这两件事都重要，但不是同一层级的问题。

如果一套数据库 DevOps 工具只把审核流做顺了，解决的只是变更控制，不是 DBA 的完整日常。

为什么很多团队审核流跑顺了，DBA 还是很累？

因为 DBA 真正持续消耗时间的，往往不是审批，而是排查。

以一次典型的慢 SQL 处理的通常动作为例：

告警来了，先上库捞 slow log

找到慢 SQL，再切到客户端跑 EXPLAIN

判断是索引问题、写法问题，还是数据量放大后的执行计划变化

把结论发给后端，再等对方验证

确认要改，再回工单系统提变更

审批通过以后，DBA 再回来执行

这条链路里，每一步都不复杂，但它们往往分散在不同工具里。审核流就算跑顺了，DBA 还是要在多个页面、多个系统、多个上下文之间来回切。慢 SQL 之所以反复，不只是因为问题难处理，也因为处理这件事本身没有被真正串起来。

如果有一套工具，能把这几步接到一起，从发现慢 SQL，到分析验证，再到提变更，都尽量放在同一套工作台里，DBA 处理问题时的切换成本就会明显下降。

NineData 慢查询

第一次分析慢 SQL 时，不建议直接查看单条 SQL。

更重要的是先确认：

慢查询是否突然增加

是否集中在某个数据库实例

NineData 的慢查询大盘会展示最近一段时间的慢查询趋势。

通过 SQL 模板定位高频问题

进入慢查询详情页后，列表并不会直接展示 SQL，而是先按 SQL 模板 聚合。

不同参数的 SQL 会归为同一个模板。这样可以更容易发现哪些查询模式在持续产生慢 SQL。排查时重点关注：

出现次数最多的 SQL 模板

执行时间较长的 SQL 模板

是否同一类 SQL 持续进入 slow log

使用诊断功能判断问题类型

在慢查询详情页里，NineData 支持对 SQL 模板和具体 SQL 样本查看诊断优化。

这样一来，SQL 审核就不再是孤零零的一步，而是被放回数据库日常治理链路里。

对 DBA 来说，以前是先发现问题，再手工跳转多个工具，把分析结果、执行计划和变更动作一点点串起来；现在是先在同一套环境里把问题定位清楚，再决定是否进入正式变更。

回到 SQL 窗口分析执行计划

确定需要优化的 SQL 后，可以在 SQL 窗口执行：EXPLAIN <SQL语句>。

重点查看：

是否使用索引

是否存在全表扫描

是否出现 filesort 或 temporary table

这一步至关重要：它把“发现问题”和“验证方案”真正接在了一起。

以前，从慢日志到客户端，中间要切一次工具、断一次上下文。现在，从慢查询分析里定位问题，到 SQL 窗口里验证方案，都在同一套环境里完成。

这也是为什么，对很多团队来说，免费本地部署数据库 DevOps 工具要补的，往往不是第 N 条审核规则，而是慢 SQL 这段高频、重复、最容易掉在地上的工作流。

如果团队现在的数据库 DevOps 还停留在“有工单、有审批”，那只解决了变更控制的一半。真正让 DBA 长期省时间的，不是再多一层审核，而是慢 SQL 这条链路终于能被持续治理。

审核管的是“别出事”，治理管的才是“一直顺”。