(1071, ‘Specified key was too long； max key length is 767 bytes‘)

MYSQL MySQL 数据库运维

(1071, ‘Specified key was too long； max key length is 767 bytes‘)

Eucalyptus2026-07-15

这个报错和ROW_FORMAT有关,在 MySQL 的 InnoDB 存储引擎中,ROW_FORMAT主要有4种格式,但在较旧的版本或特定语境下,常讨论的是前三种。以下是这四种格式的详细介绍和区别:

REDUNDANT (冗余格式)

来源:MySQL 5.0 之前的旧格式。

现状:不推荐使用,除非你需要迁移非常古老的数据库。

特点:

为了向后兼容保留。
每个列都存储了长度前缀,即使定长字段也存。
缺点:占用空间大,性能较差。

COMPACT(紧凑格式) MySQL 5.0 - 5.7 默认

来源:MySQL 5.0 引入。

现状:在 MySQL 5.7 及之前是默认格式。现在依然广泛使用,但不如 DYNAMIC 灵活。

特点:

去掉了 REDUNDANT中不必要的长度前缀。
NULL 值和长度为 0 的字段不占用存储空间只占位标记。
比 REDUNDANT更节省空间,CPU 开销更小。

DYNAMIC(动态格式)MySQL 5.7 / 8.0 默认

来源:MySQL 5.7 引入,8.0 成为默认值。

现状:现代 MySQL 的推荐默认格式。

基于COMPACT格式改进。
关键区别:对于变长字段如 VARCHAR, TEXT, BLOB ,如果数据太长无法完全存入主页面 Overflow Page ,DYNAMIC格式只会将前 20 字节或更多,取决于实现留在主页面,其余部分全部放到溢出页 Overflow Page 。
而 COMPACT格式会尝试将前 768 字节留在主页面。
优势:主页面能容纳更多的行索引记录,提高了缓冲池 Buffer Pool 的命中率,适合大字段较多的场景。

COMPRESSED(压缩格式)

来源:MySQL 5.1 引入。

现状:适用于读多写少、磁盘空间紧张且 CPU 资源充足的场景。注意:在 MySQL 8.0.13 之后,官方已弃用此格式,建议改用表空间压缩或其他手段。

特点:

基于 COMPACT格式。
使用 zlib 算法对数据和索引进行物理压缩。
可以显著减少磁盘占用和 I/O,但会增加 CPU 负担因为需要解压/压缩。
通常配合 KEY_BLOCK_SIZE使用。

总结

REDUNDANT	COMPACT	DYNAMIC	COMPRESSED	特性
引入版本	< 5.0	5.0	5.7	5.1
默认状态	过时	5.7及以前默认	8.0 默认	需手动开启
大字段处理	全部存溢出页	前768字节在主页	仅前20字节在主页	压缩后存储
空间效率	低	中	高	最高 (但耗CPU)
性能	低	中	高 (缓存命中率高)	低 (CPU密集)
推荐程度	不推荐	可用	推荐	特定场景

在 MySQL 5.6 及更早版本或者手动设置了innodb_large_prefix OFF 中:

COMPACT/ REDUNDANT格式限制:单个索引列的最大长度限制为 767 字节。
DYNAMIC /COMPRESSED 格式限制:如果启用了innodb_large_prefix ON MySQL 5.7 默认开启 ,最大长度限制提升至 3072 字节。

为什么会出现这个错误?最常见的情景是你在VARCHAR字段上创建索引,且使用了utf8mb4字符集。

字符集计算:utf8mb4每个字符最多占用 4 个字节。
临界点计算:767 bytes/4 bytes per char 191.75767 bytes/4 bytes per char 191.75。所以,在COMPACT格式下,utf8mb4的 VARCHAR 字段如果长度超过 191,创建索引就会报错。

例如下面的场景:

那有人可能会说这个idx_name不也才8个字符,为什么会超出限制呢?

这是一个非常经典的误解这里有两个概念混淆了: 索引名的长度和索引列内容的长度。报错 Specified key was too long指的不是索引的名字 idx_name 太长,而是你试图建立索引的那个字段列里的数据内容可能太长,超过了限制。

澄清概念

idx_name:这是索引对象的名称。MySQL 对索引名的限制通常是64个字符。idx_name只有 8 个字符,完全没问题。
key length (报错中的 key):指的是被索引的那一列数据在索引树中占用的字节数。

那有人可能又会说如果varchar(255)中我只存 abc 呢?VARCHAR确实是“弹性”的变长 ,它只占用实际存储数据所需的字节数加上1-2个字节的长度前缀。如果里面存的是 abc ,它确实只占很少的空间。但是,索引 Index 的工作机制不同。索引 B Tree 是一个预分配结构。当 MySQL InnoDB 引擎创建索引时,它必须为索引中的每一个条目 Entry 预留足够的空间,以容纳该列可能出现的最大值。

在数据库底层: