答案是通过EXPLaiN分析执行计划，检查索引使用、统计信息和数据分布，结合慢查询日志定位问题。具体为：使用EXPLAIN查看type、key、rows和Extra字段，确认是否全表扫描或未用索引；通过FORCE INDEX测试索引效果；运行ANALYZE table更新统计信息；检查隐式类型转换和低基数索引；启用慢查询日志并分析Rows_examined，优化索引设计以解决执行异常。
当mysql中SQL执行计划异常时，通常表现为查询变慢、索引未命中或全表扫描等问题。要有效调试这类问题，关键是理解MySQL如何选择执行路径，并通过工具和语句分析其决策过程。
查看实际执行计划（使用EXPLAIN）
在sql语句前加上EXPLAIN或EXPLAIN format=JSON，可以查看MySQL执行该查询的计划。
- type：关注连接类型，如ref、range、index、ALL。若出现ALL，说明是全表扫描，需检查索引是否生效。
- key：显示实际使用的索引。若为NULL，表示未使用索引。
- rows：预估扫描行数。若数值过大，说明查询效率可能低下。
- Extra：关键字段，如出现using filesort或Using temporary，意味着排序或临时表操作，应尽量避免。
例如：
EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 'paid';
观察是否使用了(user_id, status)的复合索引。
强制使用索引排查优化器误判
如果怀疑优化器错误地选择了执行路径，可用FORCE INDEX测试特定索引的效果。
SELECT * FROM orders FORCE INDEX(idx_user_status) WHERE user_id = 100 AND status = 'paid';
对比执行时间与执行计划，判断原计划是否因统计信息不准导致。
注意：FORCE INDEX仅用于诊断，不建议长期使用。
检查索引与数据分布
执行计划异常常源于索引设计不合理或统计信息过期。
- 确认查询条件中的字段是否有合适索引，尤其是多条件组合查询。
- 运行ANALYZE TABLE table_name;更新表的统计信息，帮助优化器更准确估算成本。
- 检查是否存在隐式类型转换，如字符串字段与数字比较，会导致索引失效。
- 查看列的基数（cardinality），可通过SHOW INDEX FROM table_name观察，低基数可能导致优化器放弃使用索引。
启用慢查询日志定位异常SQL
开启慢查询日志，捕获执行时间较长的语句，便于后续分析。
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; SET GLOBAL log_output = 'TABLE';
执行后，通过以下语句查看记录：
SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10;
结合慢日志中的Rows_examined字段，判断是否扫描过多行。
基本上就这些。核心是用EXPLAIN看执行路径，结合索引设计、统计信息和实际执行表现逐步排查。多数执行计划异常都能通过调整索引或刷新统计信息解决。