MySQL 1118错误完整解决方案 | Row size too large 实战指南
摘要：本文详细记录了一次MySQL行大小超限错误的排查与解决过程，从问题现象到根本原因，再到多种解决方案，帮助你彻底理解并解决此类问题。
📋 一、问题背景
环境信息
| 项目 | 值 |
|---|---|
| MySQL版本 | 8.0.22 |
| 存储引擎 | InnoDB |
| 字符集 | utf8mb4 |
| 字段名 | transform_script |
| 原类型 | VARCHAR(1080) |
错误信息
1118 - Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs🔍 二、问题排查过程
第一次尝试 ❌
-- 错误操作：单纯增加字段长度 ALTER TABLE your_table MODIFY COLUMN transform_script VARCHAR(10800);结果：报错依旧，甚至更严重
问题分析
为什么增加长度反而问题更严重？
| 因素 | 说明 |
|---|---|
| 字符编码 | utf8mb4下一个字符最多占用4字节 |
| 长度前缀 | VARCHAR需要1-2字节存储长度信息 |
| 行开销 | 表头、空值标记等约几十字节开销 |
| 其他字段 | 表中其他字段也会占用行空间 |
计算演示
VARCHAR(10800) 潜在最大占用： = 10800 × 4字节 + 长度前缀 ≈ 43200 + 2 字节 ≈ 43202 字节 如果表中有其他字段（如 INT、DATETIME 等） + 行头开销（约 40-50 字节） 总长度可能超过 65535 字节限制！💡 三、核心原因解析
InnoDB 行大小限制
┌─────────────────────────────────────────────────────────┐ │ MySQL InnoDB 行大小限制 │ ├─────────────────────────────────────────────────────────┤ │ 最大行大小：65535 字节（不包括 BLOB/TEXT 的实际内容） │ │ 包含内容：所有固定长度字段 + VARCHAR 实际数据 + 行开销 │ │ 特殊情况：某些版本/配置下行内存储限制为 8126 字节 │ └─────────────────────────────────────────────────────────┘为什么 VARCHAR 会触发限制？
- VARCHAR 是行内存储：数据直接存储在行中
- 按最大长度计算：即使实际数据很小，也会按定义的最大长度预留空间
- utf8mb4 放大效应：1个字符 = 最多4字节
✅ 四、解决方案
方案一：改为 TEXT 类型（推荐 ⭐）
-- 表已存在时使用 ALTER ALTER TABLE your_table_name MODIFY COLUMN transform_script MEDIUMTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci COMMENT '存储转换脚本';方案二：新建表时直接定义
CREATE TABLE your_table_name ( id INT PRIMARY KEY AUTO_INCREMENT, transform_script MEDIUMTEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;类型选择参考表
| 类型 | 最大长度 | 适用场景 |
|---|---|---|
| TEXT | 64KB (65,535字节) | 短文本、备注 |
| MEDIUMTEXT | 16MB | 脚本存储、文章内容✅ |
| LONGTEXT | 4GB | 超大文档、日志 |
🛠️ 五、最佳实践建议
1. 字段类型选择原则
存储内容长度预期 推荐类型 ───────────────────────────────────── < 255 字符 VARCHAR(255) 255 ~ 1000 字符 VARCHAR(1000) > 1000 字符 或 不确定 TEXT / MEDIUMTEXT 存储脚本/代码/大文本 MEDIUMTEXT ✅2. 建表时注意事项
-- ✅ 推荐：明确指定字符集和排序规则 CREATE TABLE example ( id INT PRIMARY KEY, content MEDIUMTEXT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; -- ❌ 避免：依赖默认设置，可能导致不一致 CREATE TABLE example ( id INT PRIMARY KEY, content VARCHAR(10000) -- 可能触发行大小限制 );3. 迁移数据时的完整脚本
-- 步骤1：备份原表 CREATE TABLE your_table_backup AS SELECT * FROM your_table; -- 步骤2：修改字段类型 ALTER TABLE your_table MODIFY COLUMN transform_script MEDIUMTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 步骤3：验证数据 SELECT COUNT(*) FROM your_table; SELECT LENGTH(transform_script) FROM your_table LIMIT 5; -- 步骤4：确认无误后删除备份（可选） -- DROP TABLE your_table_backup;⚠️ 六、注意事项
| 注意项 | 说明 |
|---|---|
| 索引限制 | TEXT 字段不能直接创建普通索引，需使用前缀索引 |
| 查询性能 | TEXT 类型查询可能比 VARCHAR 稍慢 |
| 排序操作 | TEXT 字段排序需要注意内存限制 |
| 备份恢复 | 大文本字段会增加备份文件大小 |
TEXT 字段创建索引示例
-- 前缀索引（推荐） CREATE INDEX idx_script_prefix ON your_table(transform_script(255)); -- 全文索引（适用于搜索场景） CREATE FULLTEXT INDEX idx_script_fulltext ON your_table(transform_script);📝 七、总结
问题根源
MySQL InnoDB 引擎对单行数据大小有65535字节的硬性限制，VARCHAR 字段按最大长度计算占用空间，utf8mb4 编码会放大实际占用。
解决思路
将大字段从行内存储改为行外存储，使用 TEXT/MEDIUMTEXT 类型，其实际内容不计入行大小限制。
核心建议
- 超过1000字符的文本字段，优先考虑 TEXT 类型
- 脚本、代码、文章内容等，直接使用 MEDIUMTEXT
- 建表时明确指定字符集，避免默认值带来的不确定性
