mysql前缀匹配慢的根本原因是索引仅加速起始定位，不加速后续扫描；关键词短时需扫描大量行并回表，导致i/o和cpu压力大。
MySQL 前缀匹配为什么慢？
直接用 LIKE '关键词%' 看似能走索引，但实际常比预期慢——尤其当关键词短、匹配行多时。根本原因是：索引只加速“定位起始位置”，不加速“后续扫描”。如果前缀太短（比如搜 'a%'），MySQL 得从索引里扫出几万行再回表，I/O 和 CPU 都吃紧。
常见错误现象：EXPLAIN 显示 type=range 但 rows 高得离谱；并发稍高就锁住 SELECT；用户输到第2个字就开始卡。
- 确保字段有 B-tree 索引（
VARCHAR类型不能用哈希索引） - 避免在前缀匹配字段上做函数操作，比如
LOWER(name) LIKE 'abc%'会失索引 - 如果字段含中文或 emoji，确认排序规则是
utf8mb4_0900_as_cs或类似支持前缀比较的 collation
用 FULLTEXT 索引替代 LIKE 的适用场景
FULLTEXT 不是为补全设计的，但它对“词干匹配”和“相关性排序”更友好，适合用户输入已较完整（≥3 字）、且接受非严格前缀的结果，比如搜“数据库优化”想看到“数据库性能优化”“MySQL优化实践”。
使用前提很明确：必须是 MyISAM 或 InnoDB 表；字段类型为 CHAR/VARCHAR/TEXT；建索引语句是 ALTER TABLE t ADD FULLTEXT(name)。
- 查询必须用
MATCH(name) AGAINST('关键词*' IN BOOLEAN MODE)，末尾星号*表示前缀通配（注意：仅布尔模式支持） - 最小词长默认是 4，搜
'myq*'会直接忽略——需调innodb_ft_min_token_size或ft_min_word_len并重建索引 -
FULLTEXT不保证顺序，ORDER BY MATCH() DESC才能按相关性排，否则结果随机
真正适合补全的方案：倒排前缀 + 内存缓存
纯 MySQL 做实时补全，天花板低。工业级做法是预生成“前缀→候选词”映射，存在 Redis 或本地内存里，MySQL 只负责兜底查详情。比如用户输“mys”，服务查 redis.get('prefix:mys') 直接返回 ['mysql', 'mysqldump', 'mysqladmin']。
预计算不难：用脚本遍历词表，对每个词生成所有前缀（'m', 'my', 'mys'…），写入 Redis 的 SET 或 Sorted Set。更新频率低时，每天跑一次即可。
- 避免把整个词表塞进 MySQL 临时表再
GROUP_CONCAT——内存爆、速度慢、不可扩展 - 前缀长度建议截断到 10 个字符内，更长的前缀几乎没人输，还浪费存储
- 如果业务允许轻微延迟，用
Redisearch或MeiliSearch替代自建前缀树，它们内置拼音/错词容错，MySQL 没这能力
WHERE name LIKE ? 后加 LIMIT 有用吗？
有用，但只解决表象。加 LIMIT 10 能让查询提前结束，减少网络传输和客户端等待，但 MySQL 仍可能扫描几千行才凑够 10 条——因为索引无法跳过中间匹配项。
典型陷阱：以为 LIMIT 能“让查询变快”，实际上执行计划没变，只是结果截断了。更糟的是，在分页场景下（LIMIT 50,10），偏移量越大越慢。
- 补全场景永远用
LIMIT，但必须配合前缀长度控制（比如只响应 ≥2 字的输入） - 不要依赖
ORDER BY id LIMIT来“稳定结果”，补全需要按热度或相关性排，不是主键顺序 - 如果非要 MySQL 原生扛，至少加
FORCE INDEX(你的前缀索引名)防止优化器误选全表扫
补全真正的复杂点不在 SQL 写法，而在“用户输得随意”和“数据更新频繁”之间的平衡——预计算要快，实时性要高，错别字要容，这些 MySQL 单独搞不定。别在索引参数上反复调优，先确认你的补全到底需要多准、多快、多新。
