根本原因是mysql对索引键长度有硬性限制：innodb默认单列索引最大767字节，启用innodb_large_prefix且行格式为dynamic或compressed时可升至3072字节；utf8mb4下每个字符占4字节，故最多支持768字符，超长则报错1071或降低索引效率。
为什么VARCHAR字段长度过大会让索引失效
根本原因不是“字段太长”，而是MySQL对索引键长度有硬性限制：InnoDB默认单列索引最大767字节，启用innodb_large_prefix且行格式为DYNAMIC或COMPRESSED时可升至3072字节。但utf8mb4字符集下每个字符占4字节，所以3072 ÷ 4 = 768——超过这个字符数的VARCHAR字段，直接CREATE INDEX会报错1071 - Specified key was too long。
即使没报错，也不代表索引高效：比如定义VARCHAR(2000)却只存10个字符，B+树索引页中仍要预留足够空间容纳最坏情况，导致每页能存的索引项变少，树高增加，I/O次数上升。
如何安全地给长VARCHAR字段建索引
不能直接索引全字段？那就用前缀索引——只取前N个字符建索引。关键是选对N值，既要覆盖绝大多数查询场景，又不能浪费空间。
- 先查实际数据分布：
SELECT MAX(LENGTH(user_token)) FROM auth_logs;如果95%的user_token长度≤128，那user_token(128)大概率够用 - 避免前缀冲突：如果大量token前20位相同（如都以
Bearer eyJ开头），user_token(20)就几乎失去区分度，查出来一堆再回表过滤，反而更慢 - 组合索引里慎用长前缀：比如
(status, user_token(191))，前缀过长会让整个组合索引膨胀，可能不如拆成status单列索引 + 应用层二次过滤 - 测试是否真走索引：
EXPLAIN SELECT * FROM auth_logs WHERE user_token LIKE 'abc%';看key列是否显示你建的索引名
比前缀索引更稳的替代方案
前缀索引是妥协方案，真正想兼顾查询速度和数据完整性，优先考虑这些：
- 哈希转换：应用层把原始字符串（如JWT）转成
SHA256，存为CHAR(64)，再对该列建完整索引。查询时也传哈希值——既规避长度限制，又杜绝前缀冲突 - 独立大字段表：把超长文本（如日志正文、富文本内容）拆到
_detail表，主表只留ID和关键检索字段。这样主表索引干净，JOIN成本可控 - 改用
TEXT+ 全文索引：若字段用于模糊搜索（如“包含某个关键词”），ALTER TABLE t MODIFY content TEXT;再建FULLTEXT(content)，比前缀索引更适合语义匹配 - 别盲目调大
innodb_page_size或改ROW_FORMAT：这些操作需重建整张表，线上环境风险高，且不解决根本的设计问题
容易被忽略的隐式陷阱
就算索引建成功了，也可能在查询时悄悄失效：
-
WHERE user_name = 123：把VARCHAR字段和数字比较，触发隐式类型转换，索引直接失效。必须写成'123' -
WHERE SUBSTRING(user_email, 1, 5) = 'admin'：函数操作导致无法使用索引，应提前在应用层截取或建生成列索引（MySQL 5.7+） - 字符集混用：主表
utf8mb4，但某列误设为latin1，JOIN或WHERE时可能因校对规则不一致放弃索引 - 统计信息过期：
ANALYZE TABLE users;要定期运行，否则优化器可能误判前缀索引的选择性，跳过它去走全表扫描
真正卡住性能的，往往不是“能不能建索引”，而是“建了之后查的时候用不用得上”。盯着EXPLAIN输出里的key_len和rows，比死磕字段长度数字有用得多。
