技术案例推演：VARCHAR(191) 与索引长度陷阱

本文是演示内容，不是作者真实项目经历。后续会用真实素材替换。

为什么会出现 191

在旧版本 MySQL 与 utf8mb4 组合下，索引长度受到字节数限制。VARCHAR(191) 乘以每字符最多 4 字节，接近常见索引前缀上限，因此常被当作保守默认值。

典型问题

当字段需要唯一约束时，盲目把所有字符串都改成 191 可能带来两个问题：长 slug 被截断后无法保存，或者不同字符串共享相同前缀而触发唯一键冲突。真正需要确认的是数据库版本、字符集、排序规则、索引类型和字段业务长度。

处理方式

先确认目标环境的 InnoDB 索引能力，再按字段语义设计长度。用户可见 slug 通常应该在应用层限制总长度，并为唯一索引保留完整值；不适合唯一索引的长文本则不应直接建普通 B-Tree 唯一键。

经验

191 不是通用业务规则，只是特定历史约束下的工程折中。迁移前要用真实字符集和索引定义做一次建表验证，并为超长输入补充负向测试。