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 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;类型选择参考表类型最大长度适用场景TEXT64KB (65,535字节)短文本、备注MEDIUMTEXT16MB脚本存储、文章内容✅LONGTEXT4GB超大文档、日志️ 五、最佳实践建议1. 字段类型选择原则存储内容长度预期 推荐类型 ───────────────────────────────────── 255 字符 VARCHAR(255) 255 ~ 1000 字符 VARCHAR(1000) 1000 字符 或 不确定 TEXT / MEDIUMTEXT 存储脚本/代码/大文本 MEDIUMTEXT ✅2. 建表时注意事项-- ✅ 推荐明确指定字符集和排序规则 CREATE TABLE example ( id INT PRIMARY KEY, content MEDIUMTEXT ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_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建表时明确指定字符集避免默认值带来的不确定性
1118-Row size too large.The maximum row size for the used table type,not counting BLOBs,is 65535
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 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;类型选择参考表类型最大长度适用场景TEXT64KB (65,535字节)短文本、备注MEDIUMTEXT16MB脚本存储、文章内容✅LONGTEXT4GB超大文档、日志️ 五、最佳实践建议1. 字段类型选择原则存储内容长度预期 推荐类型 ───────────────────────────────────── 255 字符 VARCHAR(255) 255 ~ 1000 字符 VARCHAR(1000) 1000 字符 或 不确定 TEXT / MEDIUMTEXT 存储脚本/代码/大文本 MEDIUMTEXT ✅2. 建表时注意事项-- ✅ 推荐明确指定字符集和排序规则 CREATE TABLE example ( id INT PRIMARY KEY, content MEDIUMTEXT ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_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建表时明确指定字符集避免默认值带来的不确定性
