MariaDB 10.1升级至10.2遇Row size too large错误的TB级存量库解决方案

问题根因补充 #

10.1环境可正常创建表、10.2报错的核心差异是：MariaDB 10.2版本默认开启innodb_strict_mode，对InnoDB行大小的检查规则更严格，超出限制直接抛出错误；而10.1版本该参数默认关闭，仅会生成告警不会阻断表创建操作。
你对存储逻辑的判断基本正确：默认COMPACT行格式下，长度小于255的VARCHAR会全额行内存储，40个varchar(250)的最大容量就已经达到10000字节，再加上InnoDB行头、事务ID、滚动指针等固定开销，很容易超出16KB默认页的行大小上限。

问题1：适配大型存量数据库的替代升级方案 #

• 首选方案：修改表的行格式为DYNAMIC，配合使用Barracuda文件格式
  操作步骤：
  1. 确认数据库参数配置：innodb_file_format = Barracuda、innodb_large_prefix = ON（MariaDB 10.2版本这两个参数默认已开启，无需重启调整）
  2. 对报错的表执行行格式修改：ALTER TABLE 你的表名 ROW_FORMAT=DYNAMIC, ALGORITHM=INPLACE, LOCK=NONE;
     该方案的优势：
  • 无需修改任何字段定义、无需调整全局页大小，也不需要全库备份重导
  • 支持在线DDL执行，ALGORITHM=INPLACE, LOCK=NONE参数可以保证改表过程中业务读写不受影响，TB级单表的改操作也可以在业务低峰期平滑执行
  • DYNAMIC行格式下，当行总大小超过页阈值时，哪怕是长度小于255的VARCHAR字段也会自动将部分内容推到off page存储，仅在行内保留20字节指针，完全可以解决行大小超限问题
• 次选方案：如果仅部分表触发报错，可仅调整这些表的字段长度为VARCHAR(256)，仅比原来多1个字节的定义上限，对业务逻辑完全无影响，改字段操作也支持在线DDL执行，改造成本远低于全量转TEXT类型

问题2：方案1（改字段为TEXT/BLOB/长VARCHAR）的影响及缓解方法 #

实际影响说明 #

• 存储开销：不会出现显著升高。如果字段存储的内容普遍较短（小于20字节），会额外多占用部分空间；如果内容普遍较长，off page存储反而会减少行内空间浪费，降低页分裂概率，整体存储开销和原方案基本持平甚至更低
• 性能影响：仅在查询读取对应off page字段时会多一次IO请求，如果缓冲池命中率足够高，该开销几乎可以忽略；如果查询不涉及这些字段，性能完全不受影响。只有在高频全表扫描、且大量读取这些off page字段、缓冲池命中率极低的场景下，才会出现可见的性能下降

缓解方案 #

• 业务查询层面禁用SELECT *写法，仅查询实际需要的字段，避免不必要的off page字段读取
• 适当调大innodb_buffer_pool_size参数，建议设置为物理内存的50%~70%，提升数据缓存命中率，减少磁盘IO开销
• 仅将低频访问、长度较大的字段改为off page存储类型，高频访问的短字段保留为短VARCHAR类型，平衡存储和性能
• 可开启innodb_page_compression参数，对off page存储的内容进行压缩，降低磁盘占用和IO消耗

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