执行 CREATE TABLE、增加字段或把字符集改为utf8mb4时，MySQL可能返回 ERROR 1118 (42000): Row size too large。这不是数据文件占满，而是单行在MySQL内部或InnoDB页中的存储预算超出限制。
修复重点是减少行内数据，而不是扩大磁盘。 先确认是哪一组列把行宽推高，再决定调整行格式、字段类型或表结构，避免直接改库导致长时间锁表。
保存完整错误和失败的DDL
先记录MySQL版本、错误文本和正在执行的语句：
SELECT VERSION();
SHOW WARNINGS;
SHOW VARIABLES LIKE 'innodb_page_size';
SHOW VARIABLES LIKE 'innodb_default_row_format';如果错误发生在迁移工具或应用发布中，从日志取出完整DDL，不要只保留ERROR 1118。创建表、增加列、转换字符集和重建索引触发的限制可能不同。
对现有表保存定义：
SHOW CREATE TABLE app.orders\G
SHOW TABLE STATUS FROM app LIKE 'orders'\G没有原始DDL和当前行格式，就无法判断是服务器级65535字节限制，还是InnoDB页内记录限制。
理解两层行大小限制
MySQL表的内部行表示存在65535字节上限，BLOB和TEXT的实际内容不计入这个上限，但它们的指针和其他开销仍占空间。VARCHAR、CHAR、NULL位图和变长字段长度字节都会参与计算。
InnoDB还有与页大小、行格式相关的本地记录限制。默认16KB页下，单条记录能留在页内的大小远小于65535字节；DYNAMIC行格式可以把较长的变长列更多地放到页外，但它不是无限容量开关。
错误里的65535只是其中一层边界，看到它不能直接推断把某个VARCHAR缩短1字节就一定能解决。 需要结合存储引擎和ROW_FORMAT判断。
找出最占空间的列
列出表中字符、二进制和大对象字段：
SELECT COLUMN_NAME,
COLUMN_TYPE,
CHARACTER_SET_NAME,
IS_NULLABLE,
COLUMN_DEFAULT
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'app'
AND TABLE_NAME = 'orders'
ORDER BY ORDINAL_POSITION;重点关注大量 VARCHAR(1000)、宽CHAR、多个可空列以及从latin1转换到utf8mb4的字段。utf8mb4声明长度按最多4字节字符预算，同样的字符数可能让最大行宽明显增加。
还要检查生成列与索引前缀：
SHOW INDEX FROM app.orders;不要只根据当前数据平均长度判断，DDL校验关注的是字段允许的最大存储边界和行格式。
先确认ROW_FORMAT是否合适
读取当前行格式：
SHOW TABLE STATUS FROM app LIKE 'orders';在支持的MySQL与InnoDB环境中，可在测试库评估DYNAMIC格式：
ALTER TABLE app.orders ROW_FORMAT=DYNAMIC;DYNAMIC有利于把长的VARCHAR、VARBINARY、BLOB和TEXT数据放到页外，减少聚簇索引记录中的行内占用。转换会重建表的场景并不少见，耗时、临时空间、WAL/binlog和复制延迟都要提前测量。
不要在磁盘余量不足或业务高峰直接重建大表。 先用同版本测试环境复制结构与脱敏样本，记录锁等待和空间峰值。
把适合的长字段改成TEXT
描述、备注、JSON文本、长URL集合等不需要固定上限的字段，可以评估从超大VARCHAR改为TEXT。例如：
ALTER TABLE app.orders
MODIFY COLUMN extra_note TEXT NULL;这能降低MySQL内部行长度预算，但会影响默认值支持、索引方式、排序、临时表和ORM映射。原列若参与普通索引，改为TEXT后往往需要明确前缀长度，或改用更适合的检索方案。
修改前检查应用是否依赖字段长度、严格模式和参数绑定。字段类型调整是数据模型变更，不是单纯的容量参数修改，必须连同索引和应用一起验证。
清理过度预留的字段设计
不少表为未来需求一次预留几十个大VARCHAR，实际业务只使用少数列。可把低频扩展属性拆到一对一扩展表，或按明确访问模式使用JSON列；高频查询字段仍保留为独立、类型准确的列。
数值、日期和状态不应使用宽VARCHAR保存。合适的INT、DECIMAL、DATE、DATETIME和ENUM替代方案能减少空间，也能改善校验和查询计划，但迁移前要检查非法历史值。
垂直拆表会增加JOIN与事务复杂度，需要根据读写路径决定。目标不是为了通过DDL随意拆列，而是让行内只保存高频且适合结构化访问的数据。
字符集转换前先估算影响
从latin1或utf8mb3迁移到utf8mb4时，字段最大字节数和索引长度都会变化。先查看表与列字符集：
SELECT TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA='app' AND TABLE_NAME='orders';对每个字符列确认真实业务长度，先缩小明显过度的VARCHAR，再做字符集转换。不要为了绕过错误继续使用无法完整表示业务字符的旧字符集，也不要把全部字段无区别改成TEXT。
转换会重建数据和索引的场景要在副本或测试库演练。字符集升级应以数据完整为目标，同时把行宽与索引长度纳入迁移计划。
使用安全的变更与回退方案
大表ALTER前确认备份可恢复、磁盘空间充足、复制正常，并设置可接受的锁等待。MySQL版本、存储引擎和具体ALTER决定能否使用INSTANT、INPLACE或需要COPY，不能把某个版本的在线DDL结论直接套到所有环境。
先查看计划支持情况并在测试表执行。生产环境可根据版本使用原生在线DDL，或经过验证的在线变更工具；无论哪种方式，都要监控线程、IO、binlog和副本延迟。
需要演练表结构调整时，可在 萤光云 建立同版本数据库，也可通过 LightNode 部署临时节点。测试数据必须脱敏，不能复制生产账号和密钥。
修改后的验收标准
重新执行原DDL，确认不再出现ERROR 1118；核对表定义、行格式、字符集和索引：
SHOW CREATE TABLE app.orders\G
SHOW TABLE STATUS FROM app LIKE 'orders'\G
CHECK TABLE app.orders;再运行应用的写入、更新、查询和排序测试，重点覆盖最长字段、空值、多字节字符和索引条件。观察慢查询、磁盘增长、复制延迟与错误日志。
验收不仅是ALTER成功，还要确认数据数量一致、应用读写正常、索引仍被使用、复制追平，并且新结构留有合理余量。
常见问题
把所有VARCHAR改成TEXT就能解决吗？
可能降低行内预算，但会改变默认值、索引和查询行为。应只调整适合保存长文本的列，并验证应用与索引。
修改innodb_page_size可以直接解决吗？
该参数在实例初始化阶段决定，不能把生产库当成普通动态参数修改。迁移到不同页大小代价很高，也不能替代合理表结构。
表里还没有数据，为什么创建时就报错？
MySQL会根据字段定义和最大可能行宽检查结构，与当前是否已有数据无关。
温馨提示
行大小错误是在提醒表结构已经接近存储边界。先减少过度预留和行内长字段，再考虑行格式；不要依靠关闭严格检查或盲目升级参数把问题留给后续写入。
