一个防不胜防的"无声杀手"
这种现象，业内叫执行计划漂移。

它是数据库世界里最难缠的性能问题之一：不报错、不告警，你永远不知道它什么时候来，也不知道它动了哪条 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，不添乱。

写在最后