“所有列总和 ≤ 65,535 字节” 是 MySQL Server 层对单行最大长度的硬性限制，与存储引擎（如 InnoDB、MyISAM）无关。

---

一、根本原因：MySQL 行格式的 16 位长度字段

1. MySQL 内部行结构（非存储引擎层）

当 MySQL Server 处理一行数据时（如返回客户端、写 binlog），使用 统一的内部行格式（Row-based Format），其关键设计：

• 每列长度用 2 字节（16 位）表示
• 最大长度值：2^16 - 1 = 65,535 字节

✅ 本质：
这是 MySQL 协议层的限制，确保行数据能被网络包（max_allowed_packet）和内部缓冲区安全处理。

2. 与存储引擎的区别

层级	限制	说明
MySQL Server 层	65,535 字节/行	所有列定义长度总和
InnoDB 层	≈8,000 字节/页（主键页内）	实际存储限制，可通过溢出页突破

⚠️ 关键点：
即使 InnoDB 能存 4GB 的 LONGTEXT，MySQL Server 在处理该行时仍受 65,535 字节限制——但仅针对 非大对象列。

---

二、限制的精确计算方式

1. 哪些列计入 65,535？

• 计入：
  CHAR, VARCHAR, BINARY, VARBINARY, TINYBLOB, TINYTEXT
• 不计入：
  BLOB, TEXT, MEDIUMBLOB, MEDIUMTEXT, LONGBLOB, LONGTEXT, JSON

💡 规则：
只有“可完全存入行内”的列才计入限制；大对象（> 255 字节）自动转为指针，不占此配额。

2. 计算公式

\sum (\text{列声明长度} \times \text{字符集最大字节}) \leq 65,535

• 字符集影响：
  • utf8mb3：1 字符 = 最多 3 字节
  • utf8mb4：1 字符 = 最多 4 字节

3. 示例

-- 案例 1：utf8mb4 下 VARCHAR(16383) → 16383 * 4 = 65,532 字节（合法）
CREATE TABLE t1 (a VARCHAR(16383) CHARACTER SET utf8mb4);

-- 案例 2：两列 VARCHAR(32767) → 32767*2*2 = 131,068 > 65,535（报错）
CREATE TABLE t2 (
    a VARCHAR(32767),
    b VARCHAR(32767)
); 
-- ERROR 1118 (42000): Row size too large...

---

三、为何大对象（BLOB/TEXT）不计入？

1. 存储机制

• BLOB/TEXT 在 MySQL Server 层被视为 “外部存储”：
  • 行内仅存 20 字节指针
  • 实际数据通过单独通道传输
• 协议设计：
  MySQL 网络包（Com Query Response）对大对象使用 分块传输，绕过行长度限制。

2. 验证

-- 合法：单列 TEXT 不计入 65,535
CREATE TABLE t3 (a TEXT); 

-- 合法：VARCHAR(20000) + TEXT → 仅 VARCHAR 计入
CREATE TABLE t4 (
    a VARCHAR(20000) CHARACTER SET utf8mb4, -- 20000*4=80,000 > 65,535? 
    b TEXT
);
-- ❌ 仍会报错！因为 VARCHAR(20000) 已超限

✅ 正确做法：
将大字段声明为 TEXT，而非 VARCHAR：

CREATE TABLE t5 (
    a TEXT,  -- 不计入 65,535
    b TEXT
);

---

四、常见错误场景与解决方案

错误 1：宽表创建失败

CREATE TABLE wide_table (
    col1 VARCHAR(10000),
    col2 VARCHAR(10000),
    ...
    col7 VARCHAR(10000)  -- 7*10000=70,000 > 65,535
);
-- ERROR 1118: Row size too large

解决方案：

• 改用 TEXT：

  CREATE TABLE wide_table (
      col1 TEXT,
      col2 TEXT,
      ...
  );
  

• 压缩数据：应用层 gzip 后存 BLOB

错误 2：utf8mb4 导致隐式超限

-- 声明 VARCHAR(20000) 在 utf8mb3 下合法（20000*3=60,000）
-- 但在 utf8mb4 下非法（20000*4=80,000）
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4; 
-- 可能失败！

解决方案：

• 提前计算：MAX_VARCHAR = FLOOR(65535 / max_bytes_per_char)
  • utf8mb3: 65535/3 ≈ 21,844
  • utf8mb4: 65535/4 ≈ 16,383

---

五、绕过限制的高级技巧

1. ROW_FORMAT=DYNAMIC + Barracuda

• 作用：
  强制大字段溢出，减少主键页占用（但 不改变 Server 层 65,535 限制）
• 配置：

  SET GLOBAL innodb_file_format=Barracuda;
  CREATE TABLE t (...) ROW_FORMAT=DYNAMIC;
  

2. 垂直分表

• 将宽表拆分为多个窄表：

  CREATE TABLE user_core (id, name, email);
  CREATE TABLE user_profile (id, bio, settings, ...);
  

3. 应用层序列化

• 将多列合并为 JSON：

  CREATE TABLE t (id INT, data JSON); -- JSON 不计入 65,535
  

---

六、监控与诊断

1. 查看表实际行格式

SHOW TABLE STATUS LIKE 'your_table';
-- 关注 Row_format, Avg_row_length

2. 检查字符集影响

SELECT 
  COLUMN_NAME, 
  CHARACTER_MAXIMUM_LENGTH,
  CHARACTER_OCTET_LENGTH  -- 实际字节上限
FROM information_schema.COLUMNS 
WHERE TABLE_SCHEMA='db' AND TABLE_NAME='table';

---

总结

• 65,535 字节是 MySQL Server 层的硬限制，源于 16 位长度字段设计。
• 仅“行内存储”的列计入限制，BLOB/TEXT 通过指针绕过。
• 字符集是隐形杀手：utf8mb4 将 VARCHAR 上限从 21k 降至 16k。
• 工程原则：
  “宽表必拆，大字段必 TEXT，字符集需精算”。
  理解此限制，方能设计出既合规又高效的表结构。