force index 是优化器误判时的针对性干预手段：统计失真致全表扫描、数据分布不均致索引被弃、复合索引未被覆盖、join中驱动表错选，此时强制索引可快速修正执行计划。
FORCE INDEX 不是日常优化的常规手段，而是在优化器明显误判、且你已确认索引完全匹配查询逻辑时的针对性干预。它必须用，往往意味着“不用就出问题”。
优化器因统计失真选了全表扫描
当表经历大批量 INSERT/DELETE 后未执行 ANALYZE TABLE，优化器仍按旧统计估算，可能认为索引查 10 万行比扫全表还贵，直接走 type=ALL。此时 EXPLAIN 显示 key=NULL 或 rows 接近总行数，但 WHERE 条件明显可命中高选择性索引（如 user_id = 123），FORCE INDEX 就是最快绕过误判的方式。
数据分布极端不均，优化器主动放弃索引
比如 status 字段只有 'pending' 和 'done' 两种值，其中 'pending' 占 95%。优化器计算后认为走 idx_status 索引要回表 95% 的行，不如全扫。但业务上你只查那 5% 的 'done' 订单——这时 FORCE INDEX 是唯一能确保走索引的写法，否则只能靠加 LIMIT 或改写查询逻辑。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
复合索引被忽略，但实际能覆盖全部查询需求
例如有索引 idx_user_status_created(user_id, status, created_at)，查询为 SELECT user_id, status FROM orders WHERE user_id = 123 AND status = 'done'。理论上这是完美覆盖索引，但优化器可能因成本模型偏差或排序干扰没选它，EXPLAIN 中 Extra 缺少 Using index。FORCE INDEX 能强制进入覆盖路径，避免多余回表。
多表 JOIN 中某张驱动表被错误当作被驱动表
在 LEFT JOIN 场景中，优化器有时会把本该用索引驱动的左表当成被驱动表，导致对左表做全表扫描。比如 SELECT * FROM users u LEFT JOIN orders o ON u.id = o.user_id，若 u 表没走主键，而是全扫，可在 users 后加 FORCE INDEX (PRIMARY) 锁定其驱动角色，让 JOIN 顺序回归预期。
