MySQL中LIKE模糊查询性能优化的核心是避免前导通配符、合理设计索引并必要时改用全文索引或预处理方案；例如'abc%'可走索引，'%abc%'则引发全表扫描，应结合EXPLAIN验证索引使用效果。
MySQL 中 LIKE 模糊查询（尤其是以 % 开头的）容易导致全表扫描，性能急剧下降。优化核心是：**避免无法使用索引的写法，合理设计索引，必要时改用更高效方案**。
避免前导通配符（%在开头）
这是性能杀手。例如 WHERE name LIKE '%abc' 或 WHERE name LIKE '%abc%'，MySQL 无法利用 B+ 树索引的有序性，只能逐行匹配。
- 能改写就改写：比如搜索“以 abc 开头”，用
LIKE 'abc%'—— 这可以走索引 - 若业务必须支持“包含 abc”，考虑是否真的需要数据库层模糊匹配，还是前端/应用层预处理或引入搜索引擎
为 LIKE 'prefix%' 创建合适的索引
当使用 LIKE 'abc%' 这类左匹配时，普通 B+ 树索引有效，但要注意：
- 索引字段要放在
WHERE条件最左侧，且不能被函数包裹（如UPPER(name) LIKE 'ABC%'会失效） - 联合索引中，
LIKE字段需位于索引最左前列，且其右侧字段无法用于范围查询（B+ 树索引只支持最左前缀匹配） - 示例：索引
(status, name)，查询WHERE status = 1 AND name LIKE 'tom%'可用；但WHERE name LIKE 'tom%'单独用则不可用
考虑全文索引（FULLTEXT）替代 %...%
对长文本字段（如文章标题、描述），LIKE '%keyword%' 效率极低。可改用 MySQL 原生全文索引：
- 仅支持
MyISAM和InnoDB（5.6+），建表时添加FULLTEXT(name) - 查询改用
MATCH(name) AGAINST('keyword' IN NATURAL LANGUAGE MODE) - 注意：不支持通配符前缀，但支持布尔模式（
AGAINST('+key*' IN BOOLEAN MODE)），且对停用词、最小词长有限制（可通过ft_min_word_len调整）
其他实用技巧
在不改变 SQL 逻辑的前提下提升响应速度：
- 加覆盖索引：把
SELECT中用到的字段也加入索引，避免回表（如INDEX(name, id, created_at)） - 限制结果集：加上
LIMIT，尤其分页场景，避免扫描大量无用行 - 区分大小写：如果业务不敏感，用
COLLATE utf8mb4_general_ci等忽略大小写的排序规则，避免隐式转换导致索引失效 - 数据预处理：如地址搜索，可拆出“省”“市”“区”独立字段，用等值查询替代模糊匹配
不复杂但容易忽略的是：先用 EXPLAIN 看执行计划，确认 type 是否为 range 或 ref，key 是否命中索引，rows 是否明显减少——这是验证优化是否生效的唯一标准。
