索引实验结果的边界与解读
索引建议无论来自人工还是工具，都只是待验证的假设。单条 SQL 在小数据集上变快，不能说明整体数据库会受益；新索引会占用存储和写入资源，也可能改变其他查询的执行计划。对自动生成的建议尤其如此：它可以帮助整理候选项，却不应直接获得生产变更权限。
先明确要优化的工作负载
验收一项索引建议时，记录原始 SQL 的参数形态、调用频率、数据量、表分布、写入压力和当前执行计划。不要只保存一条替换了具体值的语句，因为选择性、范围条件和排序方式会影响优化器选择。热点 SQL 还要看同时运行的相邻查询：某个索引可能帮助一类读取，却增加另一类写入或缓存竞争。
EXPLAIN是重要证据，但不是简单的通过/失败开关。出现 filesort 或临时表并不必然意味着错误，缺少它们也不保证开销低；需要结合扫描行数、实际耗时、内存与磁盘使用、返回行数以及数据库版本解读。不同引擎与版本的输出含义并不完全相同，规则不能取代对实际计划的审查。
候选索引 → 受控环境建模 → 计划与实测对比 → 写入代价评估 → 灰度与回退这个过程的目的，是把一次“看起来更快”的实验变为可复查的变更决定。测试环境应尽量接近生产的表结构、数据分布和并发模型，必要时使用经过脱敏的样本或影子副本。测试库只有少量行时，全表扫描与索引扫描的差异可能根本显现不出来。
关注复合条件和全局影响
复合索引的字段顺序取决于等值、范围、排序、分组和覆盖需求的组合，不能套用一句口诀。IN、范围条件和ORDER BY的组合需要用实际计划验证；即使某次计划能利用索引排序，参数变化、统计信息更新或查询改写后也可能不同。建议中应写清假设，而不是声称某种列顺序一定适用于所有语句。
创建索引还会影响写入延迟、锁定行为、备份与存储量。大表上的 DDL 操作需要根据数据库能力选择在线方式、维护窗口和失败回退方案，不能让智能体或脚本自行执行。若建议需要删除旧索引，先确认它是否仍服务于其他查询或约束，并保留恢复路径。
将自动化限定在提案和验证
工具可以收集慢查询、归类相似模式、生成候选列和提醒缺少证据，但执行权限应由数据库变更流程控制。提案应包含来源、适用语句、预期收益、潜在写入代价、测试结果和负责人。无法取得足够数据时，工具应标记不确定性，而不是编造确定结论。
进入灰度后，观察目标 SQL 与相关工作负载的延迟分布、错误、资源和写入指标，并设置明确的撤回条件。一次查询变快而整体 CPU 或锁等待上升时，应回退并重新分析。发布后更新索引清单和文档，避免下一次调优者不知道为什么它存在。
索引优化并非只追求更低的单次耗时。把执行计划、数据规模、写入代价和灰度结果放在同一份记录里，团队才能判断建议是否真正改善了工作负载，也能在条件变化后重新验证，而不是把偶然结果当作长期规则。
