前缀索引适合varchar、text等长字符串字段，如title、url、email（但email有唯一约束时宜用完整索引）；不适用于数值型、日期型及短固定长度字符串（如char(2)），因其本身存储紧凑，加前缀反而破坏等值匹配。
前缀索引适合什么字段
只对 VARCHAR、TEXT 这类长字符串字段考虑前缀索引，比如 title、url、email（注意：如果 email 已有唯一性约束且长度可控，通常建完整索引更稳妥）。数值型、日期型、短固定长度字符串（如 CHAR(2)）不需要前缀索引——它们本身就很“瘦”，加前缀反而破坏等值匹配。
常见错误是给 name VARCHAR(100) 直接建 INDEX(name(5))，结果发现大量姓名前5位重复（如“张三”“张四”“张五”），导致索引区分度暴跌，查询仍要回表扫一堆行。
- 先用
SELECT COUNT(DISTINCT LEFT(name, 5)) / COUNT(*) FROM users;算前5位的区分度，理想值 > 0.9 - 逐步试 10、15、20，直到区分度不再明显提升，或索引大小增长过快
- 避免用太小的前缀（如
name(1)），除非业务明确只按首字母查
怎么建前缀索引才不踩坑
语法很简单：ALTER TABLE users ADD INDEX idx_name_prefix (name(10));，但容易忽略三点：
- 前缀长度必须写在括号里，不能写成
name(10)以外的形式（比如name[10]或name:10都会报错） - 同一个字段不能同时存在完整索引和前缀索引，否则优化器可能选错；删掉冗余的
INDEX(name)再建前缀索引 -
ORDER BY name或GROUP BY name无法利用前缀索引排序——因为只索引了前 N 字符，后缀信息丢失，MySQL 会退回到Using filesort
为什么有时 WHERE name LIKE '张%' 走了前缀索引，但 WHERE name LIKE '%三' 不走
前缀索引本质还是 B+ 树索引，只支持“最左前缀匹配”。LIKE '张%' 是从开头匹配，B+ 树能快速定位到所有以“张”开头的叶子节点；而 LIKE '%三' 是尾部模糊，树结构无法跳过前缀直接找结尾，只能全表扫。
- 即使建了
INDEX(name(10))，WHERE name LIKE '张%'依然有效，但前提是查询条件没做函数转换，比如WHERE UPPER(name) LIKE '张%'就会让索引失效 -
WHERE name = '张三丰'能用前缀索引，但若前缀长度设为 2（name(2)），而“张三丰”前2字是“张三”，那它和“张三峰”就冲突了——查出来多条，还得回表过滤，实际性能可能不如完整索引
前缀索引和复合索引里的字符串列怎么配合
如果复合索引里含字符串列，比如 INDEX(status, email)，不要默认给 email 加前缀；优先评估 email 在 where 中是否常单独出现。如果查询大多是 WHERE status = ? AND email = ?，那 email 建完整索引更安全；如果还经常 WHERE email LIKE 'a%' 且 email 平均长度 200，再考虑 INDEX(status, email(15))。
- 复合索引中字符串列放右边时，前缀长度影响整体索引宽度，但不影响最左前缀匹配逻辑
- 别为了省空间把
email弄成email(8)——邮箱前8位很可能全是 “admin@” 或 “user@”，区分度接近 0 - 用
EXPLAIN看key_len：如果显示用了前缀索引，key_len会比完整索引小（比如utf8mb4下email(10)占 42 字节，完整email(255)占 1020 字节）
LIKE 'xxx%'，上线后发现大量 = 查询因前缀过短反复回表，IO 拉满。
