那条突然变慢的 SQL，到底经历了什么？

凌晨三点，运维群炸了。

一个跑了大半年、稳如老狗的查询，就在昨晚数据库例行重启之后，慢了整整 40 倍。

代码一行没改，数据量也没暴涨，可它就是慢了。有人怀疑是缓存，有人怀疑是网络，折腾到天亮，真相才浮出水面——

执行计划，变了。

优化器在重启后重新"思考"了一遍，然后挑了一条看起来更聪明、实际上更慢的路。而这一切，没有任何日志、没有任何告警，它就那么悄无声息地发生了。

一个防不胜防的"无声杀手"

这种现象，业内叫执行计划漂移。

它是数据库世界里最难缠的性能问题之一：不报错、不告警，你永远不知道它什么时候来，也不知道它动了哪条 SQL。等到业务报警、CPU 飙红，往往已经错过了最佳排查时机，只能靠经验一条条 SQL 去猜。

说白了，过去我们面对执行计划退化，手里缺了四样东西：

• 升级/重启后计划漂移了，看不见
• SQL 计划变了，却定位不到是哪条、变成了啥样
• 同一条 SQL 优化前后的效果，没法量化
• 想拿历史计划做对比，根本没有数据

GreatSQL 8.4.4-5 决定，给这个"无声杀手"装上监控探头。

思路朴素，却直击要害

新特性「执行计划变更异常捕获」的做法说穿了很简单——对付这种突然变慢的SQL，GreatSQL 8.4.4-5的做法是给每条 SQL 的执行计划留一份"档案"，然后定期查岗。：

数据库运行时，它以 SQL Digest 为维度，持续把每条 SQL 当前走的执行路径记录成基线；到了重启后、或运行一段时间后，拿新旧两份"档案"一比对，哪条计划"变心"了、cost 变高了，立刻标记出来，连带对应的存疑 SQL 一起摆到你面
前。

从"事后靠猜"，一步跨到"事前预警"。

两步启用，几乎零负担

它以插件形式工作，装个插件、开俩开关就能跑：

-- 安装插件
INSTALL PLUGIN plan_baseline SONAME 'libgreatdb_plan_baseline.so';

-- 开启采集
SET GLOBAL plan_baseline_enable_summary    = ON;
-- 开启持久化
SET GLOBAL plan_baseline_enable_persistent = ON;

之后，执行计划基线、历史计划、原始 SQL 信息会自动沉淀到专门的数据表里，配合内置的差分比对能力，同一条 SQL 前后的 cost 变化一目了然。

而最让人安心的，是它的工程设计——采集与查询解耦、内存缓存优先、异步落盘、查询无锁访问。这套"监控探头"几乎不占用数据库干正事的主链路，高并发下照样稳。就算某条 SQL 采集时出了岔子，也只是被静静跳过，绝不拖累整体
。

真正做到了：抓 Bug，不添乱。

写在最后

如果说以前排查执行计划退化，靠的是"运气 + 经验 + 一身冷汗"，那么现在，GreatSQL 给了你一双随时在线的眼睛。

在性能问题爆发之前，就把那条"变心"的 SQL，抓个现行。

想了解更多细节，可查阅 GreatSQL 官方用户手册 8.4.4-5 版本