索引不会自动生效，需WHERE匹配最左前缀且无函数/类型转换；JOIN驱动表选择、OR/IS NULL处理、数据分布变化均影响索引使用，优化需综合评估数据分布、查询频率与写入压力。
WHERE 条件没写对，索引根本不会用
MySQL 和 PostgreSQL 都不会因为表上有索引就自动走索引——前提是 WHERE 子句能匹配索引的最左前缀，且没有隐式类型转换或函数包裹。
常见错误现象：SELECT * FROM orders WHERE DATE(created_at) = '2024-01-01'，哪怕 created_at 有索引，也会全表扫描，因为 DATE() 函数导致索引失效。
- 改用范围查询：
created_at >= '2024-01-01' AND created_at - 避免在索引列上做计算、
UPPER()、LIKE '%abc'（前导通配符） - 检查执行计划：
EXPLAIN SELECT ...看key列是否非 NULL，rows是否明显偏大
MySQL 里 FORCE INDEX 不是万能解药
加 FORCE INDEX 能绕过优化器误判，但代价是失去统计信息更新后的自适应能力，而且只对单表生效，JOIN 场景下容易失效。
使用场景：确认某列有高选择性索引，但优化器因行数估算偏差选了全表扫描或错误索引。
- 语法：
SELECT * FROM users FORCE INDEX (idx_status_created) WHERE status = 1 AND created_at > '2024-01-01' - 必须确保
idx_status_created是复合索引，且字段顺序匹配 WHERE 中的过滤顺序 - 如果表数据分布突变（比如 status=1 的记录从 1% 涨到 90%），
FORCE INDEX反而让查询更慢 - PostgreSQL 不支持类似语法，得用
SET enable_seqscan = off临时关闭顺序扫描，但生产环境严禁这么做
JOIN 多表时，驱动表选错等于白优化
SQL 改写中常忽略：谁当驱动表（outer table）决定连接路径和索引是否生效。优化器可能选错，尤其当小表没走索引、大表被当作驱动表时。
性能影响明显：驱动表返回 10 万行，被驱动表每行都去索引查找，IO 和 CPU 成倍放大。
- 显式控制驱动顺序：MySQL 8.0+ 可用
STRAIGHT_JOIN，把确定能走索引的小表放前面，如SELECT ... FROM orders STRAIGHT_JOIN order_items ON ... - 确保被驱动表的 ON 条件列有索引，例如
order_items.order_id必须有索引 - 避免在 JOIN 条件里写函数或表达式，如
ON o.id = CAST(oi.order_id AS SIGNED)会废掉索引 - 用
EXPLAIN FORMAT=TREE（MySQL 8.0+）看实际连接顺序，比传统 EXPLAIN 更直观
WHERE 中 IS NULL 或 OR 条件容易触发全表扫描
IS NULL 在某些存储引擎（如 MyISAM）上不走索引，InnoDB 虽支持，但若索引列允许 NULL 且占比高，优化器仍可能放弃；OR 更危险——只要其中任一条件无法用索引，整个 WHERE 就大概率退化。
错误示例：WHERE status = 1 OR amount > 1000，即使 status 和 amount 各有单列索引，也常走全表。
- 拆成 UNION ALL：
SELECT ... WHERE status = 1 UNION ALL SELECT ... WHERE status != 1 AND amount > 1000（注意去重逻辑是否允许） - 改用 IN 替代多个 OR：
WHERE status IN (1, 2, 3)，前提是这些值都有索引支持 - 对 NULL 做业务规避：把默认值设为
0或'N/A'，用等值查询替代IS NULL - 复合索引要包含所有可能为 NULL 的列，并确认统计信息已更新（
ANALYZE TABLE）
真正难的不是加提示或改写语法，而是判断「这个查询到底该依赖哪个索引」——这需要看数据分布、查询频率、写入压力三者的平衡。很多人调完一条 SQL 走索引了，结果发现另一条相似查询反而更慢，就是因为没同步评估索引维护成本和覆盖度。
