索引失效主因是WHERE条件对列使用函数/表达式、LIKE通配符前置、隐式类型转换、联合索引顺序不当及统计信息过期；应将函数移至右侧、建函数索引、用前缀LIKE、更新统计信息并合理设计联合索引顺序。
WHERE 条件用了函数或表达式导致索引失效
MySQL 和 PostgreSQL 都不会对 WHERE name UPPER(column) 或 WHERE id + 1 = 100 这类带函数/运算的左侧列走索引——因为索引存的是原始值，不是计算结果。
实操建议：
- 把函数移到右侧：
WHERE column = UPPER('abc')而不是WHERE UPPER(column) = 'ABC' - 对必须函数查询的字段，建函数索引（PostgreSQL 支持
CREATE INDEX ON t ((UPPER(name)))；MySQL 8.0+ 支持函数索引但语法是CREATE INDEX idx_name_upper ON t ((UPPER(name)))） - 避免在索引列上做隐式类型转换，比如
WHERE status = '1'（status 是 INT），MySQL 可能放弃索引
LIKE 查询以通配符开头触发全表扫描
WHERE name LIKE '%abc' 或 WHERE name LIKE '%abc%' 无法使用 B-tree 索引的前缀匹配特性，只能从头扫。
实操建议：
- 前缀固定时用
LIKE 'abc%'，能走索引 - 需要全文模糊查，优先考虑
tsvector（PostgreSQL）或FULLTEXT（MySQL），而不是硬扛 LIKE - 短文本且查询频繁，可加生成列 + 索引：例如
ALTER TABLE t ADD COLUMN name_rev TEXT GENERATED ALWAYS AS (REVERSE(name)) STORED，再建索引查WHERE name_rev LIKE REVERSE('%abc')
EXPLAIN ANALYZE 输出里 key 为 NULL 或 type 为 ALL/INDEX
这是索引没被用上的直接证据。key: NULL 表示优化器根本没选索引；type: ALL 是全表扫描，type: INDEX 是全索引扫描（仍很慢）。
实操建议：
- 先确认是否真走了索引：执行
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 123，看key字段是否显示索引名 - 注意
rows值远大于实际匹配数？可能是统计信息过期，运行ANALYZE TABLE orders（MySQL）或ANALYZE orders（PostgreSQL）更新 - 如果
possible_keys有多个但key只选了一个，说明优化器认为它“最便宜”，未必是你想要的——可用FORCE INDEX（MySQL）或/*+ IndexScan(t idx_name) */（PostgreSQL via pg_hint_plan）临时干预
联合索引顺序错、中间列缺失或范围查询后列失效
联合索引 (a, b, c) 只对 WHERE a = ? AND b = ? AND c = ?、WHERE a = ? AND b = ?、WHERE a = ? 有效。一旦出现 WHERE a = ? AND c = ?（跳过 b），或 WHERE a > ? AND b = ?（a 是范围），c 就不再走索引。
实操建议：
- WHERE 条件列顺序不重要，但索引列定义顺序至关重要：高频等值查询的列放前面，范围查询列放最后
- 不要迷信“覆盖索引”就一定快——如果
SELECT *且索引太宽（比如含大 TEXT 字段），反而可能比主键回表还慢 - 用
SHOW INDEX FROM t（MySQL）或\d t（PostgreSQL）确认索引实际字段顺序，别只看命名
索引失效往往不是“有没有建”，而是“建得对不对、用得巧不巧”。最常被忽略的是统计信息陈旧和联合索引中范围查询的截断效应——这两点在数据量突增或上线新查询后最容易冒出来。
