MySQL ERROR 1118行大小过大：转TEXT后仍报错求解决方案

安全阿岳

2026-5-25

解决MySQL行大小超限（ERROR 1118）的问题

首先，我完全理解你遇到的困扰——700列的超宽表本身就容易触发InnoDB的行大小限制，哪怕把VARCHAR改成TEXT也没解决，核心原因是TEXT类型并没有完全脱离行内存储。

为什么改TEXT还是报错？

InnoDB对于TEXT（以及BLOB）类型的处理是：会把前768字节的内容存在行内，剩余部分才会放到溢出页。也就是说，每个TEXT列仍然会占用768 + 2字节的行内空间（2字节是长度标识）。如果你的表有几十个TEXT列，光这些前缀加起来就可能接近甚至超过8126字节的限制，再加上其他列的存储开销，自然还是会触发报错。

具体解决步骤

1. 先估算当前行的实际占用大小

先搞清楚你的表到底占了多少行内空间，用这个查询来计算（替换成你的数据库和表名）：

SELECT 
  SUM(
    CASE 
      WHEN data_type LIKE 'varchar%' THEN 
        -- VARCHAR的行内占用：定义长度 + 2字节长度标识
        IFNULL(character_maximum_length, 0) + 2
      WHEN data_type IN ('text', 'mediumtext') THEN 
        -- TEXT行内前缀 + 2字节标识
        768 + 2
      WHEN data_type = 'longtext' THEN 
        -- LONGTEXT只存4字节指针 + 2字节标识
        4 + 2
      -- 其他类型直接取默认存储长度
      ELSE IFNULL(data_length, 0)
    END
  ) AS estimated_row_size
FROM information_schema.columns
WHERE table_schema = '你的数据库名' 
  AND table_name = '你的表名';

这个结果会帮你定位到底是哪些列在“吃”行内空间。

2. 优化列类型（优先操作）

缩减不必要的VARCHAR长度：检查所有VARCHAR列，把那些定义长度远大于实际存储内容的列改小（比如把VARCHAR(500)改成VARCHAR(200)，如果实际存的内容很少）。VARCHAR的行内占用是按定义长度计算的，哪怕实际存的短，也会预留空间。
用更紧凑的类型替代：对于有固定可选值的列，用ENUM替代VARCHAR；对于数字类型，用最小合适的类型（比如TINYINT代替INT），这些都能大幅减少行内空间。
把部分TEXT改成LONGTEXT：如果某些列确实需要存超长内容，改成LONGTEXT——它只在内存中存4字节的指针，不会占用768字节的行内前缀，能节省大量空间。

3. 垂直拆分表（长期可行方案）

既然你的表有700列，本身就不符合关系型数据库的设计规范。可以把表拆分成多个一对一关联的表：

主表：只保留核心业务必须的列（比如主键、常用查询字段）。
扩展表：把那些大文本、不常用的列拆分到单独的表，用主键和主表关联。
这样每个表的行大小都会控制在8126字节以内，同时也能提升查询性能（因为查询主表时不需要加载大量冗余列）。

4. 临时应急配置（不推荐长期使用）

如果以上方案都来不及实施，可以临时调整InnoDB的行为，但这只是权宜之计：

确保innodb_large_prefix = ON（MySQL 5.7.7+默认开启），它允许索引前缀更长，但对行大小限制的缓解有限。
关闭innodb_strict_mode：虽然能绕过部分行大小检查，但可能会导致数据存储异常，不建议在生产环境长期使用。

总结

优先通过估算行大小找到冗余点，优化列类型；如果还是不行，垂直拆分表是最稳妥的长期方案——毕竟未来你还要迁移到键值存储，拆分表也能为后续迁移做准备。

内容的提问来源于stack exchange，提问作者Bing