FORCE INDEX用于强制MySQL使用指定索引，适用于优化器选择低效执行计划、覆盖索引未被采用或性能分析场景；例如SELECT * FROM orders FORCE INDEX (idx_user_id) WHERE user_id = 123 ORDER BY order_date DESC；需注意避免滥用、确保索引存在、维护性差及与USE INDEX的区别，应结合EXPLAIN验证效果并持续监控性能。
在 MySQL 中，FORCE INDEX 是一种查询提示（hint），用于强制查询优化器在执行 SELECT、UPDATE 或 DELETE 语句时使用指定的索引，即使优化器认为其他索引或全表扫描更高效。
FORCE INDEX 的基本语法
在 SELECT 查询中使用 FORCE INDEX 的语法如下：
SELECT * FROM table_name FORCE INDEX (index_name) WHERE conditions;也可以用于 UPDATE 和 DELETE 语句：
UPDATE table_name FORCE INDEX (index_name) SET column = value WHERE conditions;DELETE FROM table_name FORCE INDEX (index_name) WHERE conditions;
什么时候应该使用 FORCE INDEX
1. 优化器选择了低效的执行计划
当 MySQL 优化器误判数据分布，选择了全表扫描或其他低效索引时，可以通过 FORCE INDEX 引导其使用更合适的索引。
2. 索引覆盖查询
如果你有一个复合索引能覆盖查询所需的所有字段（即“覆盖索引”），但优化器未选用它，可强制使用以提升性能。
3. 调试和性能分析
在分析查询性能时，强制使用某个索引可以帮助你对比不同索引的实际执行效果。
实际使用示例
假设有一张订单表 orders：
CREATE TABLE orders (id INT PRIMARY KEY,
user_id INT,
order_date DATE,
amount DECIMAL(10,2),
INDEX idx_user_id (user_id),
INDEX idx_order_date (order_date)
);
你想按用户查询最近的订单，期望使用 idx_user_id 索引：
即使存在 order_date 索引，MySQL 也会优先走 user_id 索引，避免全表扫描。
注意事项与潜在风险
1. 不要滥用
MySQL 优化器通常能做出合理选择。强制使用索引可能在数据量变化后导致性能下降。
2. 索引不存在会报错
如果指定的索引名拼写错误或已被删除，查询将失败并提示 “Unknown key” 错误。
3. 可能影响维护性
硬编码索引名会使 SQL 语句与表结构强耦合。后续重构索引时需同步修改 SQL。
4. 与 USE INDEX 的区别
- USE INDEX 只是建议优化器使用某个索引（可不采纳）
- FORCE INDEX 是强制使用，优化器不能忽略
总结
FORCE INDEX 是一个有用的工具，适合在确认优化器选择错误索引时进行干预。但在生产环境中应谨慎使用，最好配合 EXPLAIN 分析执行计划，验证强制索引是否真的提升了性能。一旦问题解决，建议持续监控，避免因数据增长导致强制索引反而变慢。
基本上就这些，关键是在理解索引机制的基础上合理使用。
