索引不会自动生效，需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 走索引了，结果发现另一条相似查询反而更慢，就是因为没同步评估索引维护成本和覆盖度。