和小曼一起走到MySQL行的尽头

小曼，重庆人，性格虽然内敛，但却是一位资深段子手。去年和我一起入职，工位坐我旁边后，承包了我半年的笑点。

我们还曾经一起去过那个被称作“MySQL行尽头”的地方。

那是一个普通的下午，耳边都是赶着需求的键盘声，我也码得正嗨皮，就在这时突然传来测试小姐姐的一声

“(╯°Д°)╯︵ ┻━┻小曼，你的 SQL 报错啦！”

我俩四目相对，眉头一皱，嗯？这 SQL 不是我们俩昨天一起看过的吗？而且在研发库上还成功运行了的，竟然报错了。

没办法，只能先停下手边工作，把 SQL 领回来看看：

ALTER TABLE t ADD x VARCHAR(300);
这就是个普通的 DML 语句啊，为 t 表增加一个 x 字段，其类型为 VARCHAR，并且允许最大的字符长度 300。

看起来没什么毛病啊，那再看看在测试库上报了啥错误：

[Err] 1118 - Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs
大致意思是：行过大，超出了 65535，需要将字段修改为 TEXT 或 BLOBs 。

小曼，你看我们添加的字段 VARCHAR 没有大于 65535 啊？不是写的 300 吗？怎么会行过大呢？

ε=(´ο｀*))) 唉，一看你就没读过《MySQL技术内幕》，快去好好补补，虽然 VARCHAR(M) 中的 M 最大可以是 65535，但是在 MySQL 中规定了所有 VARCHAR 字段的长度总和不能超过65535。”

(´・ω・`) 原来是这样！

所以，是 t 表的 VARCHAR 字段的长度之和 > 65535了？那又为什么研发库能执行成功，测试库却执行失败？莫非两个库的 t 表存在不一致。

我们导出表结构一对比，果然发现有两个 VARCHAR 的字段存在不一致，下面是两个库 t 表中 VARCHAR 字段的长度总和：

sum_varchar_test = 21735
sum_varchar_dev = 21035
测试库比研发库大了整整700！（不知道是哪位改了数据库，没同步 > <）

我再看了一眼表结构，VARCHAR 长度上千的字段比比皆是，这分明是不给后人留活路嘛，怪不得我们加不了字段。

可是还是不对啊，小曼，刚刚不是说长度总和大于 65535 吗？测试库的这也才 21735 啊。这不是还差很多吗？

ε=(´ο｀*))) 唉，VARCHAR(M) 中的 M 指的是字符长度，而 65535 指的是字节长度，我们 t 表用的是 utf8 编码，utf8 编码每个字符占 1~3 字节，考虑每个字符可能最大 3 字节，所以 t 表中 VARCHAR 字段的字符长度总和不能超过 65535 / 3 = 21845。而想在测试库上再加个 VARCHAR(300) 的字段确实是超过了限制。

(´・ω・`) 原来是这样！

下面我们一起用SQL复现这个问题：

先创建一张表：

-- 每个字段上限1w字符
-- 又因为是latin1编码，所以也是1w字节
CREATE TABLE t (
a VARCHAR(10000),
b VARCHAR(10000),
c VARCHAR(10000),
d VARCHAR(10000),
e VARCHAR(10000),
f VARCHAR(10000)
)CHARSET=latin1, ENGINE=InnoDB;

再尝试修改表结构：

ALTER TABLE t ADD x VARCHAR(10000);
[Err] 1118 - Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs

错误如约而至，原因我们也已知晓，70000 > 65535，那我们再尝试修改下 SQL：
ALTER TABLE t ADD x VARCHAR(5535);
[Err] 1118 - Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs
仍然报错，经过反复测试后，新增的 VARCHAR 最大长度只能是 5520：

ALTER TABLE t ADD x VARCHAR(5520);
Query OK, 0 rows affected (0.02 sec)

最大只能是 65520，和 65535 还差了 15，这是因为还有其他开销（VARCHAR的长度标识 2 个字节 * 7 + NULL 标识位的1个字节）。

到这里，问题基本清楚了。原来 MySQL 的行也是有尽头的，虽然 VARCHAR 具有可变长的特点，好用，但也不能乱用，毕竟还有 65535 字节在限制着我们。

小曼，那我们是不是按 MySQL 给建议，把字段改成 TEXT 和 BLOBs 就可以跨越限制，不会再出现这个问题？

ε=(´ο｀*))) 唉，MySQL 设计数据结构的时候就已经规定了“一切皆有尽头”，TEXT 和 BLOBs 也不例外，所以仍然存在超出限制的可能，它们的具体限制你去翻翻 MySQL 手册 11.7节吧，不说了，我要改BUG了。

(´・ω・`) 好的，小本本记下来，MySQL手册 11.7节，原来“一切皆有尽头”！

禅定时刻

上述已经将问题基本定位清楚，MySQL 的限制让我们不能继续添加字段，但同时这也正提醒着我们设计的重要性。会出现这个问题的真正原因实则正是，我们使用数据库字段类型不当，那么如何解决该问题，我想大家也应该都知道了。

最后想说，虽然一切皆有尽头，但只要我们用合理的设计去解决，便能打破有限，创造无限。