必须验证CodeBuddy推荐的复合索引是否被MySQL优化器采纳且适配真实数据分布，否则可能无效甚至拖慢写入；需通过EXPLAIN比对、抽样测试、字段顺序调换、pt-index-usage与Optimizer Trace交叉验证，并监控上线后I/O与缓冲池命中率。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在MySQL中执行一条耗时3.2秒的查询，EXPLAIN显示type=ALL、rows=287642，而CodeBuddy建议创建一个复合索引时，必须验证该建议是否真能被优化器采纳、是否适配你表中95%的vessel_id集中在10个值的真实分布——否则盲目建索引不仅无效，还会拖慢写入性能。
比对执行计划一致性
这一步是验证CodeBuddy索引建议是否落地有效的第一道门槛。AI可以推荐索引，但MySQL优化器是否买账，得看EXPLAIN说了算。
1、在MySQL客户端中执行原始慢查询前，务必加上EXPLAIN FORMAT=TREE（MySQL 8.0+）或EXPLAIN（兼容旧版），重点记录type、key、rows、filtered、Extra字段值。
2、将完整的建表语句、当前所有索引定义（用SHOW CREATE TABLE navigation_orders获取）、原始SQL及上一步EXPLAIN输出，一并提交给CodeBuddy，并明确指令：“请基于此执行计划分析缺失索引，仅输出CREATE INDEX语句，不解释原理”。
3、执行CodeBuddy返回的CREATE INDEX命令后，立即再次运行相同EXPLAIN，确认key列是否显示新索引名，且type从ALL/INDEX提升至range/ref/eq_ref；若rows值未显著下降，说明索引未被有效利用。
【统计信息过期会导致优化器拒绝使用新索引，此时必须手动执行ANALYZE TABLE navigation_orders】
复现真实数据分布测试
CodeBuddy训练数据中常见的“均匀分布”假设，在你的业务表里大概率不成立。比如navigation_orders表中vessel_id字段实际有严重倾斜——95%的记录集中在10个值上，这时它推荐的(idx_vessel_entry)可能完全失效。
方法一：抽样验证
1、从生产库导出10万条真实记录：mysqldump --where="id BETWEEN 100000 AND 200000" navigation_orders orders_sample > sample.sql。
2、导入到独立测试库test_nav，仅创建CodeBuddy建议的idx_vessel_entry (vessel_id, entry_time)，不建任何其他索引。
3、对高频vessel_id（如'VESSEL123'）执行相同WHERE条件查询，用SELECT BENCHMARK(1000, ...)跑1000次取平均耗时，对比全表扫描基准值。
方法二：顺序调换重测
若方法一提速不足3倍，立刻尝试调整字段顺序为(entry_time, vessel_id)重建索引并重跑测试——因为当vessel_id选择性极低时，按时间范围筛选再过滤vessel_id，往往比先过滤vessel_id再查时间更高效。
交叉验证Percona Toolkit与Optimizer Trace
单靠EXPLAIN和抽样测试仍不够。Percona Toolkit提供更底层的索引有效性评估，而Optimizer Trace能暴露优化器内部决策路径，二者交叉比对可定位AI建议与执行引擎之间的逻辑断层。
第一步：用pt-index-usage分析慢日志
1、确保MySQL已开启slow_query_log并设置long_query_time≤1，运行至少2小时收集真实负载。
2、执行pt-index-usage /var/log/mysql/slow.log --no-version-check --filter 'db:navigation_orders'，输出中若显示某索引“Never used”，则CodeBuddy建议的索引大概率不匹配实际查询模式。
第二步：启用Optimizer Trace捕获决策细节
1、在会话中执行：SET optimizer_trace="enabled=on,one_line=off";
2、运行原始慢查询，再执行SELECT * FROM information_schema.OPTIMIZER_TRACE;
3、检查trace字段中"considered_execution_plans"部分，确认优化器是否将CodeBuddy建议的索引纳入候选，以及最终弃用它的具体原因（如"cost"过高、“range_analysis_per_index”中显示该索引预估成本远超全表扫描）。
监控上线后I/O延迟与缓冲池命中率
索引上线不是终点，而是观察期的开始。如果QPS上升后I/O等待陡增、InnoDB Buffer Pool Hit Rate跌破95%，说明新索引引发大量随机读或内存争抢，需紧急干预。
1、在索引创建后24小时内，每5分钟采集一次关键指标：SHOW ENGINE INNODB STATUS\G中的"Buffer pool hit rate"、"I/O thread state"；iostat -x 5中的await、%util。
2、若发现buffer pool命中率持续低于92%且await > 15ms，立即检查是否因新索引导致大量二级索引页被频繁加载进内存，挤占了主键索引页空间。
3、执行SELECT * FROM sys.schema_index_statistics WHERE table_name = 'navigation_orders' ORDER BY rows_selected DESC LIMIT 5;，确认CodeBuddy建议的索引是否真的成为最常被选中的索引之一。
