最直接有效的干预手段是强制使用指定索引；因优化器依赖的统计信息存在数据倾斜、复合索引顺序不匹配、函数导致索引失效及统计陈旧等问题而选错索引。
当SQL报表执行缓慢，排查发现是优化器选错了索引（比如该走时间范围索引却走了状态字段索引），最直接有效的干预手段就是强制使用指定索引。
为什么优化器会选错索引？
优化器依赖统计信息估算成本，但报表场景常有以下偏差：
- 数据分布倾斜严重（如95%记录状态为“已完成”，统计信息误判过滤性）
- 复合索引列顺序与查询条件不匹配，导致部分字段无法生效
- 查询中存在函数或类型转换（如WHERE DATE(create_time) = '2024-01-01'），使索引失效后被迫退化选择
- 统计信息陈旧未更新，尤其在大批量导入/删除后
如何安全地强制索引？
不同数据库语法略有差异，核心原则是：只在明确验证过性能提升的前提下使用，且需配套监控和回滚机制。
-
MySQL：用USE INDEX或FORCE INDEX，例如
SELECT * FROM order_log USE INDEX (idx_create_time_status) WHERE create_time >= '2024-01-01' AND status = 1; - PostgreSQL：无原生强制索引语法，改用SET enable_seqscan = off配合SET enable_indexscan = on，或通过重写查询（如加AND ctid IN (SELECT ctid FROM ...)）引导路径
-
Oracle：使用INDEX(table_name index_name)提示，例如
SELECT /*+ INDEX(t idx_create_time) */ * FROM order_log t WHERE create_time >= SYSDATE - 7;
强制索引前必须做的三件事
- 对比执行计划：分别获取原SQL和加提示后的EXPLAIN结果，确认实际使用的索引、预估行数、是否出现临时表或文件排序
- 真实数据压测：在准生产环境用全量时间段数据运行，观察逻辑读、执行时间、CPU消耗，避免小数据量下“看似快实则隐患”
- 设置熔断机制：在应用层增加超时控制；DBA侧配置慢日志告警（如强制索引后执行时间反而增长200%立即通知）
比强制索引更可持续的解法
强制索引是止痛药，不是根治方案。长期应推动以下改进：
- 定期更新统计信息（如MySQL的ANALYZE TABLE，PostgreSQL的VACUUM ANALYZE）
- 重构低效查询：把WHERE DATE(create_time) = ...改为WHERE create_time BETWEEN ... AND ...，让索引可用
- 按报表高频条件设计覆盖索引，例如CREATE INDEX idx_rpt ON order_log (create_time, status, amount) INCLUDE (order_id, user_id);
