前缀索引适用于长字符串字段且前缀选择性高的场景，如邮箱、url、uuid；需通过 count(distinct left()) 实测选择性，目标 >90%；不支持 order by/group by、唯一约束受限，like 仅前缀匹配有效。
前缀索引适用于字段值较长、但前几位就具备足够区分度的场景，比如邮箱、URL、用户名等字符串列。它能减少索引体积、提升写入和缓存效率，但会牺牲部分查询精度和排序能力。
哪些字段适合建前缀索引
核心判断标准是：字段值长度大 + 前缀选择性高（即前 N 个字符就能较好区分不同记录）。
- 邮箱地址 ：如
user@example.com，通常前 10–15 位（含用户名和 @）已能大幅降低重复率 - URL 路径 ：如
/api/v1/users/123，前 20–30 位常覆盖主要路由结构 - 长文本标识符 ：如 UUID 字符串（36 位），前 16 位在多数业务中已有足够区分度
- 不建议用于 ：中文姓名、短字段（如状态码）、前缀高度重复的字段（如全以
https://开头的 URL）
如何确定最优前缀长度
不能拍脑袋定，要基于数据分布实测选择性：
- 先查字段总行数：
SELECT COUNT(*) FROM t; - 再按不同前缀长度统计去重数，例如：
SELECT COUNT(DISTINCT LEFT(email, 10)) AS cnt10, COUNT(DISTINCT LEFT(email, 15)) AS cnt15 FROM t; - 计算选择性 = 去重数 / 总行数；目标是达到 90%+，且长度尽量小
- 可配合直方图或采样分析，避免全表扫描代价过高
使用前缀索引要注意的坑
它不是万能替代方案，有明确限制：
- 无法用于 ORDER BY 和 GROUP BY：MySQL 8.0 之前不支持对前缀索引列做完整排序或分组
- 不能作为主键或唯一约束依据 ：即使加了 UNIQUE 约束，也是对前缀生效，可能产生逻辑冲突
- LIKE 查询需注意通配符位置 ：只有
WHERE col LIKE 'abc%'能走索引，'%abc'或'%abc%'完全失效 - JOIN 条件慎用 ：若关联字段用了前缀索引，匹配精度下降可能导致结果异常
替代或补充方案参考
当前缀索引局限明显时，可考虑这些更稳健的做法：
- 生成列 + 普通索引 ：MySQL 5.7+ 支持，如为 email 创建虚拟列
email_prefix VARCHAR(16) STORED AS (LEFT(email,16))，再对其建索引 - 哈希列索引 ：对长字段计算 MD5/SUBSTR(MD5(),1,16)，存为新列并建索引，适合等值查询，但丧失范围能力
- 全文索引（FULLTEXT）：针对搜索类场景，但只适用于 MyISAM 或 InnoDB 的 TEXT/VARCHAR 列
- 业务层截断 + 校验 ：如邮箱登录时只比对前缀，后端再全量校验，平衡性能与准确性
