前缀索引长度应使前缀区分度接近1，如SELECT COUNT(DISTINCT LEFT(email,15))/COUNT(*)>0.99；需按字符数（非字节）取值，中文同理；建索引语法为email(15)，括号紧贴列名；短值等值查询可能无法使用前缀索引。
前缀索引该建多长？看 SELECT COUNT(DISTINCT LEFT(column, N))
前缀索引不是越长越好，也不是拍脑袋定个 10 或 20。核心判断依据是：这个长度能否让索引具备足够区分度。直接跑一句查询就能验证：
SELECT COUNT(DISTINCT LEFT(email, 15)) / COUNT(*) AS selectivity FROM users;
结果接近 1（比如 >0.99）说明 15 位前缀已能很好区分大部分值；若只有 0.3，那基本等于没用。
- 别只看平均长度——
email字段平均长度 28，不代表前 15 位不重复；实际要测的是“前缀去重率” - 对中文字段（如
name），UTF8MB4 下一个汉字占 3 字节，但前缀长度按字符数算，不是字节数；LEFT(name, 10)是取前 10 个字符，不是 10 字节 - 测试时务必加
LIMIT的表要全量扫描，否则结果不准；小表可全查，大表建议用SAMPLE或采样估算
ALTER TABLE ... ADD INDEX 加前缀索引的写法细节
语法看着简单，但几个参数位置和括号容易写错，导致建出来是全列索引或报错：
ALTER TABLE users ADD INDEX idx_email_prefix (email(15));
注意三点：
- 括号必须紧跟列名，不能写成
email (15)（空格会报错） - 只能用于
VARCHAR、TEXT类型；对INT或DATETIME加(5)会被忽略或报错 - 如果原列有
NOT NULL约束，前缀索引不影响该约束；但如果是允许NULL的列，前缀索引仍能正常建立和使用 - MySQL 5.7+ 支持在
CREATE TABLE语句里直接定义，如：email VARCHAR(255), INDEX(email(15))
前缀索引查不到数据？检查 WHERE 条件是否匹配前缀长度
建了 email(15) 索引，但 WHERE email = 'a@b.c' 还是走全表扫描？常见原因不是索引失效，而是条件值太短。
MySQL 用前缀索引做等值查询时，优化器会尝试把右侧常量也截到相同长度再比对。但如果原始值本身比前缀还短（比如只写了个 'a'），就无法利用索引的 B+ 树结构做高效定位。
- 短值查询（如
WHERE email = 'test'）大概率走不了前缀索引，除非你明确知道所有email都以'test'开头且无歧义 -
LIKE 'xxx%'能用前缀索引，但LIKE '%xxx'或LIKE '%xxx%'完全不能 - 排序（
ORDER BY email）和分组（GROUP BY email）也能用前缀索引加速，前提是排序/分组字段就是索引列本身，而非表达式
为什么 SHOW INDEX 里显示的 Sub_part 是 NULL？
执行 SHOW INDEX FROM users 后，发现刚建的前缀索引对应行的 Sub_part 列是 NULL，不是预期的数字（如 15）。这通常意味着：
- 建索引语句写错了——比如漏了括号：
ADD INDEX idx_xxx (email) (15)是非法语法，MySQL 会静默忽略后半部分，建出全列索引 - 目标列类型不支持前缀索引（例如
JSON、POINT），MySQL 不报错但不生效 - 用了低版本 MySQL（
- 确认是否生效最靠谱的方式不是看
SHOW INDEX，而是EXPLAIN SELECT ... WHERE email = '...'看key_len是否符合预期（比如email(15)在 utf8mb4 下key_len应为 60 左右）
前缀索引真正难的不是语法，是权衡：既要足够短来省空间、减少 B+ 树层级，又要足够长来避免大量回表。线上改之前，一定拿真实数据跑一遍 COUNT(DISTINCT LEFT(...)) 和 EXPLAIN。
