MySQL前缀索引长度应基于字段区分度选择，非越长越好；需用COUNT(DISTINCT LEFT(col,n))/COUNT(*)验证，目标是短前缀覆盖90%以上不同值，兼顾效率与空间。
MySQL索引长度不是越长越好，也不是固定值，关键看字段实际数据的区分能力——前缀越短、唯一性越高，索引效率就越好，空间和写入开销也越小。
用前缀区分度验证法确定长度
对字符串字段（如 title、name、email）建前缀索引时，核心目标是：用尽可能短的前缀覆盖绝大多数不同值。常用验证 SQL 如下：
SELECT COUNT(DISTINCT LEFT(name, 35)) / COUNT(*) FROM b2b_goods;逐步尝试不同长度（比如从 10、20、30…试到 100），观察比值变化：
- 比值 ≥ 0.9：说明前 35 个字符已能区分 90% 以上的记录，对多数业务已足够
- 比值 ≥ 0.99：适合对精确匹配要求高的场景（如用户名唯一校验）
- 比值达到 1.0：全字段无重复，但通常没必要走到这一步，尤其当字段本身很长（如 VARCHAR(500)）
结合字段类型与业务场景选长度
并非所有字符串都需计算区分度，可先按经验快速判断：
- 邮箱（email）：前 20–30 字符基本够用，因域名部分（@xxx.com）常重复，本地名开头差异大
- 商品标题（title）：建议从 30 开始测试，电商类标题前 40 字通常已包含核心关键词
- 用户昵称或姓名：中文名普遍较短，15–25 即可；英文名注意大小写和空格，可略加长至 30
- URL 或长文本摘要：优先考虑是否真需要索引，若仅用于 LIKE '%xxx%' 则索引无效；若用于等值查询，取前 64 或 128 常见且安全
避免常见长度设置误区
错误做法会抵消前缀索引的优势：
- 直接对 VARCHAR(255) 字段建全字段索引（
INDEX(col)），不设长度——浪费空间，拖慢 INSERT/UPDATE - 随意设一个“看着顺眼”的数，比如 email(10)，但实际前 10 位大量重复（如 all_user_001@、all_user_002@），导致索引失效
- 在区分度已稳定（如 35 字符达 0.92）后，继续盲目加长到 60，索引体积翻倍但查询性能几乎不变
- 对 ENUM、TINYINT、DATE 等短类型字段设长度（如
status(1)）——语法允许但无意义，MySQL 忽略该长度
创建与验证索引的实际步骤
完成分析后，按标准流程落地：
- 用
CREATE INDEX idx_title ON b2b_goods (title(35));创建前缀索引 - 执行
EXPLAIN SELECT * FROM b2b_goods WHERE title = 'xxx';确认 key_len 显示为 35（或接近，考虑字符集影响）且 type 是 ref/eq_ref - 对比加索引前后 rows 扫描量，应从全表扫描（ALL）降到几十或个位数
- 上线后观察慢日志，确认该索引被真实命中，而非长期闲置
