前缀索引适用于长字符串字段且前缀选择性高的场景，如邮箱、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）
如何确定最优前缀长度
不能拍脑袋定，要基于数据分布实测选择性：
NetShop网店系统
下载
NetShop软件特点介绍： 1、使用ASP.Net(c#)2.0、多层结构开发 2、前台设计不采用任何.NET内置控件读取数据，完全标签化模板处理，加快读取速度3、安全的数据添加删除读取操作，利用存储过程模式彻底防制SQL注入式攻击4、前台架构DIV+CSS兼容IE6,IE7,FF等，有利于搜索引挚收录5、后台内置强大的功能，整合多家网店系统的功能，加以优化。6、支持三种类型的数据库：Acces
- 先查字段总行数：
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 列
- 业务层截断+校验：如邮箱登录时只比对前缀，后端再全量校验，平衡性能与准确性
