AI 查询回放平台：优化器改动前，先让历史 SQL 说话
一、优化器改动不能只跑单元测试
数据库优化器的一次改动，可能让某些查询变快，也可能让另一些查询选择错误计划。单元测试能覆盖规则逻辑，但无法覆盖真实业务 SQL 的复杂分布。优化器改动前，历史 SQL 回放非常关键。
AI 可以辅助分析回放结果，归类计划变化和性能波动。但前提是回放平台先把 SQL、参数、统计信息和执行环境管理好。否则模型只是分析一堆不可比较的噪声。
二、回放平台要保存上下文
flowchart TD
A[历史 SQL] –> B[脱敏与归一化]
B –> C[统计信息快照]
C –> D[旧优化器执行]
C –> E[新优化器执行]
D –> F[结果对比]
E –> F
SQL 文本不够。参数、表结构、索引、统计信息、数据规模和数据库版本都影响计划。回放时要尽量固定这些变量，否则差异无法归因。
脱敏也很重要。历史 SQL 可能包含业务 ID、用户信息和敏感条件。回放平台应保存结构和分布，同时保护数据安全。
三、对比要看计划和结果
replay_result:
sql_id: q_1024
plan_changed: true
latency_delta: "+38%"
rows_equal: true
risk: medium
计划变化不一定是坏事，延迟变化也可能来自环境抖动。需要同时看计划、耗时、扫描行数、返回行数和结果一致性。若结果不一致，优先级最高。
AI 可以帮助把变化分类：Join 顺序变化、索引选择变化、谓词下推变化、聚合策略变化。分类后，优化器开发者才能更快定位规则问题。
EXPLAIN FORMAT=JSON SELECT …
结构化执行计划比纯文本更适合分析。能用结构化格式，就不要只解析字符串。
四、回放要有准入门槛
优化器改动上线前，可以设置门槛：高风险 SQL 不退化，整体 p95 不上升，结果一致，关键业务查询计划可解释。门槛不通过就不能合并或上线。
回放样本也要维护。历史 SQL 会变化，业务场景会变化。平台需要定期更新样本，并保留一批事故 SQL 作为回归集。事故发生过一次，就不应该再靠运气避免第二次。
回放环境要尽量隔离。生产流量、后台任务、缓存状态都会影响耗时。若无法完全隔离，至少要多轮运行并记录方差。优化器回放最怕把环境抖动误判为计划退化。
参数绑定也要保存。相同 SQL 模板在不同参数下，选择性完全不同。只用模板回放，会掩盖参数敏感问题。应保留高频参数、慢查询参数和边界参数。
还要做计划 diff。结构化比较 Join 顺序、访问路径、索引选择、谓词下推和聚合策略，比只看耗时更有解释力。耗时告诉你变慢了，计划 diff 告诉你为什么可能变慢。
最后，AI 分析结论要回到具体计划节点。只说“可能索引选择不佳”不够，要指出哪个表、哪个索引、估算行数和实际行数的差异。
回放还要区分优化目标。某些改动追求平均延迟下降，某些追求尾延迟稳定，某些追求内存更低。不同目标下，同一个计划变化的评价不同。准入门槛必须和目标一致。
结果集对比也要考虑浮点和排序。没有 ORDER BY 的 SQL，返回顺序不同不一定是错误；浮点聚合微小差异也可能来自执行顺序。比较器需要理解 SQL 语义，否则会产生大量误报。
最后，回放平台要输出可复现包。包含 SQL、参数、schema、统计信息、版本和对比结果。优化器问题如果不能复现，就很难被修好。
五、总结
AI 查询回放平台要保存 SQL、参数、统计信息、结构化执行计划和结果对比，让优化器改动在历史负载上接受验证。
优化器改动前，让历史 SQL 先说话。真实负载比任何单个精心样例都更诚实。
