-- 优化器明明有更好的索引，却选了错误的
EXPLAIN SELECT * FROM orders
WHERE status = 'paid' AND created_at > '2024-01-01';
-- key: idx_created_at（错误选择）
-- 实际应该用 idx_status_created

-- 建议优化器使用 idx_status_created
SELECT * FROM orders USE INDEX (idx_status_created)
WHERE status = 'paid' AND created_at > '2024-01-01';

-- 多个索引建议
SELECT * FROM orders USE INDEX (idx_status_created, idx_status)
WHERE status = 'paid' AND created_at > '2024-01-01';

- 只是"建议"
- 优化器仍然可以**选择不使用**
- 如果优化器认为全表扫描更好 → 全表扫描
- 优先级低于优化器自身的评估

-- 强制使用 idx_status_created
SELECT * FROM orders FORCE INDEX (idx_status_created)
WHERE status = 'paid' AND created_at > '2024-01-01';

-- 强制使用主键
SELECT * FROM orders FORCE INDEX (PRIMARY)
WHERE id BETWEEN 1000 AND 2000;

-- 多个强制（优化器在指定列表中选择）
SELECT * FROM orders FORCE INDEX (idx_status, idx_status_created)
WHERE status = 'paid' AND created_at > '2024-01-01';

- 优化器必须从指定索引中选择
- 不能全表扫描（除非指定索引都无法使用）
- 如果指定索引都不适用 → 全表扫描（兜底）

-- 索引：idx_created(created_at), idx_status_created(status, created_at)

-- 查询：优化器选了 idx_created，但应该用 idx_status_created
EXPLAIN SELECT * FROM orders
WHERE status = 'paid' AND created_at > '2024-01-01';
-- key: idx_created（只用到了 created_at 条件）

-- 强制使用复合索引
EXPLAIN SELECT * FROM orders FORCE INDEX (idx_status_created)
WHERE status = 'paid' AND created_at > '2024-01-01';
-- key: idx_status_created（status 也参与了索引查找）

-- 表数据量 1000 万，status='pending' 占比 0.1%
-- 但优化器不知道（Cardinality 统计不准）

-- 优化器选择了全表扫描
EXPLAIN SELECT * FROM orders WHERE status = 'pending';
-- type: ALL, rows: 10000000

-- 强制用索引
EXPLAIN SELECT * FROM orders FORCE INDEX (idx_status)
WHERE status = 'pending';
-- type: ref, rows: 10000（快了 1000 倍）

-- 索引 idx(a, b, c)

-- MySQL 可能只用了 a，但其实 b, c 也很有用
-- 通过其他方式解决（不是用 FORCE INDEX 就能解决的）
-- 这种情况 FORCE INDEX 也帮不了你

-- 1. 确认优化器确实选错了
-- 先不用 FORCE INDEX 执行一次
-- 再用 FORCE INDEX 执行一次
-- 对比执行时间

-- 2. 使用 EXPLAIN 验证
EXPLAIN SELECT * FROM orders FORCE INDEX (idx_status_created)
WHERE status = 'paid' AND created_at > '2024-01-01';
-- 确认 key 确实用了 idx_status_created

-- 3. 长期方案：更新统计信息或用查询重写
ANALYZE TABLE orders;
-- 如果 ANALYZE 后优化器选对了 → 就不需要 FORCE INDEX

-- 今天：status='paid' 占 10%
FORCE INDEX (idx_status) -- 效果好

-- 一个月后：status='paid' 占 80%
FORCE INDEX (idx_status) -- 反而不如全表扫描！
-- 但 FORCE INDEX 还在，查询变慢了

-- 更好的做法
-- 1. 更新统计信息（ANALYZE TABLE）
-- 2. 优化索引设计（比如建更好的复合索引）
-- 3. 改写 SQL 语句
-- 4. 最后才用 FORCE INDEX 兜底

-- 每次索引变更、索引名修改、索引删除
-- 都要同步修改 SQL 代码

-- 建议：只在必要时用，并添加注释
SELECT * FROM orders FORCE INDEX (idx_status_created)  -- 2024-01-15: 优化器选错，待分析
WHERE status = 'paid' AND created_at > '2024-01-01';

-- 方案 1：ANALYZE TABLE 更新统计
ANALYZE TABLE orders;

-- 方案 2：删除或设为不可见那个"坏"索引
ALTER TABLE orders ALTER INDEX idx_created INVISIBLE;

-- 方案 3：写更精确的 SQL
-- 用 AND 代替 OR
-- 避免在索引列上使用函数
-- 保持 WHERE 条件顺序清晰

-- 方案 4：IGNORE INDEX（反选，建议不要用的索引）
SELECT * FROM orders IGNORE INDEX (idx_created)
WHERE status = 'paid' AND created_at > '2024-01-01';