like '%abc'一定不走索引，因为b+树索引仅支持从左到右的最左前缀匹配，%在开头导致无法定位扫描起点，只能全表扫描；explain显示type: all、key: null即为典型表现。
LIKE '%abc' 为什么一定走不了索引
因为 B+ 树索引只支持从左到右的最左前缀匹配，% 在开头等于放弃所有索引定位能力。数据库无法预判“以任意字符开头、再跟 abc”的值在索引树里落在哪一段，只能逐行扫描整张表。
常见错误现象：EXPLAIN 显示 type: ALL、key: NULL，哪怕字段上建了 INDEX(name) 也完全不生效；FORCE INDEX 强制也没用——优化器清楚这个索引对 LIKE '%abc' 没价值。
- 只有
LIKE 'abc%'这类固定前缀才能利用索引范围扫描 -
LIKE '%abc%'或LIKE '%abc'都等价于全表扫描，数据量一过十万行，延迟就明显可感 - MySQL、PostgreSQL、SQL Server、Oracle 全部遵循这一行为，不是某一家的 bug
LOWER(name) LIKE LOWER('%abc%') 会让索引更糟
函数包裹列（如 LOWER()、TRIM()、SUBSTRING()）会直接导致索引失效——数据库必须先计算每行的函数结果，再做匹配，无法复用原始字段上的索引。
正确做法是统一用大小写不敏感的 COLLATION，比如 utf8mb4_unicode_ci 或 MySQL 8.0+ 推荐的 utf8mb4_0900_as_cs（区分大小写但支持索引优化），然后直接写 name LIKE 'abc%'。
- 检查当前字段 collation：
SHOW FULL COLUMNS FROM table_name LIKE 'name'; - 修改 collation 示例：
ALTER TABLE users MODIFY name VARCHAR(255) COLLATE utf8mb4_0900_as_cs; - 避免 WHERE 中混用不同 collation 的列比较，隐式转换会悄悄让索引失效
想支持任意位置匹配，别硬扛 LIKE '%xxx%'
真要查“包含某子串”，靠 LIKE '%xxx%' 是下策。它不光慢，还无法排序、无法分词、不支持权重和相关性评分。
更可行的替代路径取决于你的数据库和场景：
- MySQL：启用
ngram插件建FULLTEXT索引，改用MATCH(name) AGAINST('xxx')（注意不支持AND混合太多条件） - PostgreSQL：装
pg_trgm扩展，建GIN索引，ILIKE '%xxx%'就能明显加速（但索引体积大、写入略慢） - 高并发/复杂检索需求：直接上 Elasticsearch 或 Meilisearch，把模糊查询从 OLTP 数据库里剥离出去
- 更新少、查询极多的短字段（如商品编码）：可预生成反向索引表，例如把
sku拆成所有长度为 2–4 的子串存进sku_substring表，查'ABC'就SELECT * FROM sku_substring WHERE substring = 'ABC'
容易被忽略的细节：collation 和字符集影响索引实际效果
同一个 LIKE 'abc%'，在 utf8mb4_bin 和 utf8mb4_unicode_ci 下执行计划可能完全不同。前者严格二进制比较，后者按语言规则归并重音、大小写，可能导致索引扫描范围变宽甚至退化为全表扫描。
实操中，别只看“有没有索引”，得看 EXPLAIN FORMAT=JSON 里的 used_range_access 和 rows_examined_per_scan——这些才是真实反映索引是否被有效利用的关键指标。
