AI 查询回放平台：优化器改动前，先让历史 SQL 说话

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