LIKE 'abc%'有时不走索引，是因为字段类型必须为VARCHAR/TEXT、排序规则需兼容（如大小写敏感时需匹配大小写）、且前缀区分度足够高（否则优化器主动放弃），三者缺一不可。
绝大多数 LIKE 查询慢，根本原因不是 SQL 写得不够好，而是压根没走索引——尤其是 LIKE '%xxx' 或 LIKE '%xxx%'，EXPLAIN 里 type 必定是 ALL。
为什么 LIKE 'abc%' 有时也不走索引？
它理论上能用 B+ 树索引，但实际是否命中，取决于三个硬性条件：
- 字段类型必须是
VARCHAR或TEXT；CHAR类型会补空格，导致LIKE 'abc '才匹配，而你写的是'abc%'，直接失效 - 排序规则（collation）必须兼容：比如字段用的是
utf8mb4_0900_as_cs（大小写敏感），那WHERE name LIKE 'Abc%'就不会命中索引，得写成'abc%'或显式加COLLATE utf8mb4_0900_as_cs - 前缀区分度太低时，优化器会主动放弃索引：比如
name LIKE 'A%'匹配了全表 40% 的行，MySQL 认为全表扫描更快，key列仍为NULL。可用SELECT COUNT(DISTINCT LEFT(name, 1)) / COUNT(*)验证选择性
LIKE '%abc' 怎么办？反向索引不是万能的
反向索引只解决后缀匹配，不是所有模糊场景都能套用：
- 建生成列：
ALTER TABLE users ADD COLUMN name_rev VARCHAR(100) AS (REVERSE(name)) STORED - 再建普通索引：
CREATE INDEX idx_name_rev ON users(name_rev) - 查询改写为：
WHERE name_rev LIKE 'cba%'（注意：关键词也要反转） - 但
LIKE '%abc%'无法用此法转化——反转后仍是LIKE '%cba%'，前后都有通配符，依然全表扫描 - 函数索引（MySQL 8.0+）可简化操作：
CREATE INDEX idx_name_rev_func ON users((REVERSE(name)))，但底层逻辑一致，不解决双向通配问题
什么时候该果断放弃 LIKE？
当业务明确需要 LIKE '%keyword%' 且数据量超过 10 万行时，继续在 MySQL 里硬扛只会拖垮整个查询链路：
-
FULLTEXT索引只对CHAR/VARCHAR/TEXT字段生效，且必须用MATCH() AGAINST()—— 写成WHERE name LIKE '%abc%'即使有全文索引也完全不生效 - 中文必须显式指定
WITH PARSER ngram，否则默认最小词长为 4，搜“李”或“AI”直接被过滤；停用词（如“的”“了”）也会被忽略，查不到先查INFORMATION_SCHEMA.INNODB_FT_DEFAULT_STOPWORD - 如果字段长度波动大、更新频繁、或需高亮/分词/相关性排序，
FULLTEXT也很快见顶——这时候就得考虑 Elasticsearch 或 Meilisearch 这类专用引擎
真正容易被忽略的点是：索引不是加了就一定生效，而是在具体 WHERE 条件、字段类型、collation、数据分布四者咬合严丝合缝时才起作用。一个 EXPLAIN 不够，得看 key、rows、filtered 三列联合判断。
