LIKE '%abc'导致索引失效，需改用'abc%'前缀匹配或反向索引；OR条件易使单列索引失效，建议UNION或联合索引；对索引字段使用函数如YEAR()会使索引失效，应改用范围查询。
WHERE 条件用了 LIKE '%abc'，索引大概率不走
模糊查询开头带通配符，MySQL 和 PostgreSQL 都没法用 B-Tree 索引做范围扫描，只能全表扫。EXPLAIN 里看到 type: ALL 或 rows 接近表总行数，基本就是这问题。
- 改写成
LIKE 'abc%'（前缀匹配），B-Tree 索引能用上 - 真要查后缀，考虑加反向索引（如
CREATE INDEX idx_name_reverse ON t ((reverse(name)))，PostgreSQL 支持；MySQL 8.0+ 可用函数索引INDEX (reverse(name))） - 别对
name LIKE CONCAT('%', ?)这种参数拼接抱幻想——优化器通常不推导，照样失效
OR 连接多个字段条件时，单列索引可能集体失效
比如 WHERE a = 1 OR b = 2，即使 a 和 b 各有单列索引，MySQL 默认也不合并使用（5.7+ 有 index merge，但代价高、不稳定）。
- 优先改成
UNION：(SELECT ... WHERE a = 1) UNION ALL (SELECT ... WHERE b = 2 AND a != 1) - 或者建联合索引
(a, b)，但只对a = 1或a = 1 AND b = 2有效，OR本身仍难优化 - PostgreSQL 对
OR处理稍好，但依然建议用UNION显式控制执行路径
对索引字段做函数或运算，比如 WHERE YEAR(create_time) = 2023
只要在索引列上套了函数、表达式或类型转换，索引就断了。优化器无法把函数结果映射回索引树结构。
- 改成范围查询：
create_time >= '2023-01-01' AND create_time - MySQL 8.0+ / PostgreSQL 可建函数索引：
CREATE INDEX idx_year ON t ((YEAR(create_time)))（注意括号语法差异） - 隐式转换也踩坑，比如
WHERE user_id = '123'（user_id是INT），MySQL 会转成数字再比，但某些版本仍拒绝用索引
ORDER BY 字段不在索引覆盖范围内，导致 Using filesort
排序字段没包含在索引里，或顺序/方向不一致（如索引是 (a ASC, b DESC)，而语句写 ORDER BY a ASC, b ASC），就会触发临时文件排序，性能跳崖。
- 检查
EXPLAIN输出的Extra列是否含Using filesort - 联合索引要按查询中
ORDER BY的字段顺序和方向严格匹配，WHERE条件字段应前置 - 如果
SELECT *且索引不覆盖所有字段，即使排序走索引，也可能因回表多而慢——这时得权衡加覆盖索引还是接受 filesort
索引失效不是非黑即白，而是优化器在成本估算后放弃使用。最可靠的方式永远是看 EXPLAIN，而不是靠经验猜；另外，统计信息过期、小表阈值、索引选择性低这些隐性因素，往往比语法错误更难察觉。
