前缀索引仅对WHERE column LIKE 'xxx%'和等值查询有效，需满足字段类型为VARCHAR/TEXT/BLOB、查询以左前缀匹配为主、不依赖ORDER BY/GROUP BY/覆盖索引，并通过COUNT(DISTINCT LEFT())科学选长确保选择性≥0.9。
前缀索引不是加了就快，它只对 WHERE column LIKE 'xxx%' 或等值查询生效，且必须配合科学选长——盲目建 content(100) 可能白占空间、拖慢写入，还无法支持 ORDER BY 或覆盖查询。
哪些字段适合建前缀索引？
不是所有长字段都该加。必须同时满足：
- 字段类型是
VARCHAR、TEXT或BLOB（CHAR(20)这类短固定长度字段没必要） - 实际查询以左前缀匹配为主，比如：
WHERE url LIKE 'https://api.example.com/%'、WHERE email LIKE 'contact@%' - 业务逻辑不依赖
ORDER BY content、GROUP BY content，也不靠SELECT content走覆盖索引（前缀索引不含完整值，必然回表） -
BLOB/TEXT字段建索引时没指定长度会直接报错：ERROR 1170 (42000): BLOB/TEXT column 'content' used in key specification without a key length——这是 MySQL 强制你做选择性评估的信号
怎么选前缀长度才不拍脑袋？
目标不是“越长越好”，而是用最短长度达到高区分度（通常选性 ≥ 0.9 就够用）。用 LEFT() + COUNT(DISTINCT) 测：
SELECT COUNT(DISTINCT LEFT(email, 5)) / COUNT(*) AS sel5, COUNT(DISTINCT LEFT(email, 8)) / COUNT(*) AS sel8, COUNT(DISTINCT LEFT(email, 12)) / COUNT(*) AS sel12, COUNT(DISTINCT LEFT(email, 16)) / COUNT(*) AS sel16 FROM users;
如果 sel8 = 0.91、sel12 = 0.93、sel16 = 0.94，那选 12 比 16 更优——多占 4 字节/行，收益几乎为零。
特别注意：所有字符按 utf8mb4 算，中文、emoji 都占多个字节，email(8) 实际可能只截到前 4 个汉字，别被数字骗了。
建索引时容易踩的坑
常见错误现象包括：
- 写成
CREATE INDEX idx_url ON logs(url)（没带长度），对TEXT字段直接失败；正确写法是CREATE INDEX idx_url ON logs(url(20)) - Java 层 SQL 写成
SELECT *或SELECT content，以为走了索引就能避免回表——其实前缀索引无法覆盖，一定回表，I/O 开销没省下来 - URL 字段全以
https://开头，却只取前 8 位，导致大量前缀重复（https://占 8 字符），区分度崩塌 - 误以为
LIKE '%xxx'或LIKE '%xxx%'能走前缀索引——完全无效，优化方向应是倒序存储+前缀索引，或改用全文索引
真正关键的不是“建不建”，而是查什么、怎么查、数据分布什么样。一个字段今天适合建 email(12)，半年后注册邮箱域名集中化，可能就得重算——前缀索引得跟着数据一起演进。
