SQL优化器选错索引主因是统计信息不准、代价估算偏差或查询写法不当；应优先更新统计信息、消除隐式转换、重构谓词，而非强制索引。
SQL优化器选错索引，本质是统计信息不准、代价估算偏差或查询写法触发了非最优路径。强制使用索引只是临时绕过问题的手段，真正要解决，得先定位原因再针对性干预。
为什么优化器会“看走眼”？
优化器依赖表和索引的统计信息（如行数、数据分布、NDV等）估算执行成本。以下情况容易导致误判：
- 统计信息过期：表数据大量增删改后未 ANALYZE 或 UPDATE STATISTICS
- 谓词条件选择性被低估：例如对低基数列（如 status IN ('A','B')）加了函数或隐式转换，导致无法准确评估过滤效果
- 复合索引顺序不匹配：WHERE 条件只用到了复合索引的后缀列（如索引是 (a,b,c)，但只查 WHERE c = ?），优化器可能放弃该索引
- 并行/内存参数干扰：work_mem、random_page_cost 等配置不合理，影响IO与CPU成本权衡
安全有效的强制索引方法
不同数据库语法不同，但原则一致：显式、可控、可回滚。
- PostgreSQL：用 /*+ IndexScan(tablename indexname) */（需启用 pg_hint_plan 扩展）；或改写为子查询+OFFSET 0 抑制某些计划，但不推荐
- MySQL：在 SELECT 后加 USE INDEX (idx_name) 或 FORCE INDEX (idx_name)；前者是建议，后者是强约束（即使全表扫描成本更低也优先用索引）
- Oracle：用 /*+ INDEX(table_alias index_name) */ 提示，配合别名使用更稳妥
- SQL Server：用 WITH (INDEX(idx_name)) 表提示，注意不支持函数索引提示
⚠️ 注意：强制索引会绕过优化器动态适应能力，一旦数据分布变化，可能从“救急”变“埋雷”。上线前务必在真实数据量下压测。
比强制更治本的优化动作
与其每次手动指定索引，不如让优化器自己选对：
- 定期更新统计信息：MySQL 运行 ANALYZE TABLE；PG 执行 ANALYZE table_name；Oracle 调用 DBMS_STATS.GATHER_TABLE_STATS
- 检查并修正隐式类型转换：比如 VARCHAR 字段传入数字参数，会导致索引失效；统一参数类型，或显式 CAST
- 重构低效谓词：将 WHERE DATE(create_time) = '2024-01-01' 改为 WHERE create_time >= '2024-01-01' AND create_time ，保留索引可用性
- 补充缺失索引：用 EXPLAIN ANALYZE 观察实际执行路径中的“Seq Scan on xxx”或“Rows Removed by Filter”，判断是否该建函数索引、覆盖索引或调整复合索引顺序
如何验证是否真需要强制？
别凭直觉，用数据说话：
- 对比强制前后的 EXPLAIN (ANALYZE, BUFFERS) 输出：重点看实际耗时、I/O 次数、是否出现大量回表或临时文件
- 检查 actual rows 与 rows removed by filter 比例：若过滤率低于 10%，说明索引区分度差，强制反而低效
- 在业务低峰期对目标 SQL 开启 auto_explain（PG）或 slow_query_log + long_query_time=0（MySQL），捕获真实负载下的执行计划变异情况
