前缀索引需先评估区分度与查询模式：仅适用于VARCHAR/TEXT/BLOB字段的左前缀匹配（如LIKE 'xxx%'），且前缀不能高度重复；必须用LENGTH()计算字节并测试选择性（≥0.92为佳），避免盲目加长；注意Java拼接、ORDER BY、回表及全文检索等常见失效场景。
直接给 TEXT 或超长 VARCHAR 字段建前缀索引，不先算区分度、不看查询模式，大概率白建——既不加速查询，又拖慢写入。
怎么判断字段值是否适合建前缀索引
不是所有长字符串都值得加前缀索引。先确认三点：
- 字段类型是
VARCHAR、TEXT或BLOB；CHAR(20)这种固定短字段完全没必要 - 实际查询中真有
WHERE column LIKE 'xxx%'这类左前缀匹配（比如 URL 以https://开头、日志以ERROR开头） - 字段内容前几位不是大量重复的（例如所有
email都以user_开头，前 5 字节区分度必然极低）
特别注意：TEXT 字段不指定长度直接建索引会报错：ERROR 1170 (42000): BLOB/TEXT column 'content' used in key specification without a key length——这不是 bug，是 MySQL 在强制你做选择性评估。
如何科学选前缀长度
目标不是“越长越好”，而是用最小字节数达到足够高的区分度（通常 ≥ 0.92 即可）。关键步骤：
- 用
LENGTH()（不是CHAR_LENGTH()）计算真实字节占用，UTF8MB4下一个汉字占 4 字节，content(100)最多覆盖 25 个汉字 - 逐档测试不同前缀长度的选择性：
SELECT COUNT(DISTINCT LEFT(content, 20)) / COUNT(*) AS sel20, COUNT(DISTINCT LEFT(content, 40)) / COUNT(*) AS sel40, COUNT(DISTINCT LEFT(content, 60)) / COUNT(*) AS sel60 FROM article;
- 如果
sel40 = 0.91、sel60 = 0.93，优先选 40——多存 20 字节/行，收益几乎为零
建索引时容易踩的坑
常见错误不是语法写错，而是语义没对齐：
- Java 应用里拼 SQL 时写成
ps.setString(1, "%" + keyword + "%")，前缀索引完全失效，必须是keyword + "%" - 误以为
ORDER BY content能走前缀索引——它不能，B+ 树里只存了前 N 字节，无法排序完整值 - 在 SELECT 列表里直接查
content字段，即使加了前缀索引，仍要回表读取整段内容，Buffer Pool 压力不减反增 - 把前缀索引当全文搜索解法：要支持
LIKE '%error%'，该上FULLTEXT+MATCH AGAINST，或抽离摘要字段
什么时候该放弃前缀索引
当出现以下任一情况，说明前缀索引不是正解：
- 业务要求任意位置关键词匹配（如后台文章检索），前缀索引无能为力
- 字段前缀高度同质化（如所有
url都以https://api.开头，前 15 字节几乎全一样） - 数据分布快速变化（如日志表每天新增百万行，且前缀规律随时间漂移），靠静态
LEFT()测试结果很快过期 - 需要唯一约束或主键语义——前缀索引天生不支持
UNIQUE，因为部分值无法保证全局唯一
最常被忽略的一点：前缀索引不是独立优化项，它必须和查询写法、字段设计、甚至应用层缓存联动。单建一个 content(100)，却不改 Java 里的 LIKE 模式或不拆分大字段，性能不会变。
