技能提升网上月只需两百毫秒的查询，这周要八秒。开发准备加索引，运维担心锁表，业务提出把数据按月分区。三个方案都有成本，先对比查询当时做了什么，会比按表大小猜更可靠。
本文用假设计划说明诊断方法，具体数据库版本和引擎决定命令与能力。AI辅助读计划及整理测试，生产上的执行、建索引和结构变更由管理员批准。
把旧查询与新查询放在可比条件下
保存SQL文本、绑定参数、执行时间、数据库版本、索引定义和统计资料状态。参数不同可能命中不同数据分布，不能只因为语句一样就认为两个计划可比。应用发布、数据量、热点变化及数据库配置分别记录，避免把所有变化归于增长。
先查等待、锁、磁盘、缓存和资源饱和。计划没有变化但仍变慢，可能是运行条件不同；计划变化也不一定就是性能下降原因。慢查询日志脱敏，敏感参数替换为保持分布特征的测试值，不能向外部模型发送客户原始记录。
incident-response可协助整理影响、时间线和验证路径，并保留可回退操作。它不替数据库执行优化。排查先用只读且低风险的资料，不把AI生成的DDL直接复制到生产。
计划里的估计和实际不要混读
以PostgreSQL为例，普通EXPLAIN展示计划估计，EXPLAIN ANALYZE会实际执行语句。后者可能带来资源消耗和数据副作用，尤其是修改语句，不能为取得计划在生产随意运行。优先使用已有监控、普通计划及批准的测试环境，事务回滚也不保证消除所有外部副作用。
计划节点看扫描方式、连接顺序、过滤、排序以及行数。代价估计不等于毫秒，节点累计关系与loops也要按数据库语义理解。实际行数与估计明显不符，可能需要检查统计、参数和数据相关性，不能直接推断索引缺失。
假设某节点估计返回一千行，测试中实际十万行，误差倍数为一百。另一个节点扫描五百万行才留下两万行，保留比例百分之零点四。这提示检查选择性、统计和过滤方式，但还需看实际耗时、重复执行次数及整个计划影响。
索引与SQL改写各有验证条件
候选索引要对应连接、过滤或排序需求，核对列顺序、选择性和是否覆盖查询。多一个索引会占空间并影响写入，不能只看单次查询变快。字段上的函数、隐式转换和取值范围可能让现有索引无法按预期使用，先验证再决定新增。
SQL改写检查结果语义，包括重复行、空值、聚合和分页顺序。把相关子查询改连接可能扩大行数，修改条件位置也可能影响外连接。AI提出版本时保留原版，测试结果集与边界案例，不只比较运行时间。
数据按月分区只有在查询、保留策略及维护条件适合时才值得评估。查询不带有效分区条件时可能仍扫描多个分区。分区迁移有索引、约束和应用兼容成本，不能因为表大就默认立即实施。
业务请求的分页深度和返回列也纳入测试。第一页快速不证明后续页同样快速，宽字段返回可能增加网络与序列化时间。执行计划分析之后仍要对照应用端总延迟，确认数据库之外没有遗漏的瓶颈。
一次受控测试要同时测读写
Metrics Review可辅助比较同条件的耗时分布、资源与错误。多轮测试覆盖常见和边界参数，冷热缓存分开说明。只选最快一次报告，会掩盖偶发锁等待与计划不稳定。
评估目标查询、关联查询及写入影响，保留测试数据规模和限制。索引创建采用该版本支持且经过批准的方式，事前确认锁与资源、事后确认使用情况。失败或副作用达到预设条件时回退，AI不擅自调整生产权限或删除现有索引。
最终建议写成可批准的变更
建议单列慢因证据、候选措施、验证结果、上线窗口与回退步骤。证据不足时明确下一步采样，不把计划截图当完整结论。实际瓶颈是下游等待的项目，不应靠重复加索引关闭。
上线后按同一业务参数观察延迟、吞吐、资源和错误，检查结果语义没有变化。保留旧新计划及定义，长期监控统计和数据分布。性能恢复的结论应回到业务请求完成情况，而不是某个计划节点已经换了名称。
