拆分text字段能显著降低ddl锁表时间，因其使主表轻量化，提升inplace成功率、加快运维操作、缩短备份窗口；但需规避外键不一致、join性能瓶颈及迁移数据不一致等风险。
拆分 TEXT 字段能显著降低 DDL 锁表时间，尤其对大表是刚需
为什么 ALTER TABLE 会卡住几小时？
MySQL 5.6+ 默认尝试 INPLACE 模式执行 DDL，但一旦涉及字段长度变化、字符集变更或引擎参数调整，InnoDB 可能退化为 COPY 模式——即重建整张表。此时：
- 主表物理文件越大，拷贝耗时越长；
TEXT字段内容默认存储在 off-page，但其元数据和指针仍计入行头，且实际读取时需额外 IO 定位 - 即使只加一个
VARCHAR(2000)字段，若原表已含多个TEXT，InnoDB 在评估行平均长度时可能误判为“需重建”，触发全量拷贝 - 主表每行多存几百字节的冗余字段（如冗余 JSON、日志快照），会让单页容纳行数下降，进一步放大
COPY过程的 IO 压力
拆成独立表后 DDL 影响范围大幅收窄
把 content、description 等大字段抽到 xxx_ext 表后，主表结构轻量化，带来三重收益：
-
ALTER TABLE users ADD COLUMN status TINYINT不再需要扫描或搬运任何TEXT数据，INPLACE成功率接近 100% - 运维人员对主表做索引优化、分区调整、统计信息更新等操作，响应时间从分钟级降到秒级
- 备份与恢复时，主表
.ibd文件体积下降 40%~70%，xtrabackup 全量备份窗口明显缩短
拆分不是无代价，关键得避开这几个坑
拆表本身引入新约束，容易在开发侧被忽略：
- 必须确保外键关联字段（如
user_id）在两张表中类型、符号、长度完全一致，否则ON UPDATE CASCADE失效或触发隐式转换 -
SELECT * FROM users JOIN users_ext ON users.id = users_ext.user_id在高并发下易成性能瓶颈，建议业务层控制是否 JOIN，而非默认加载全部扩展字段 - 如果用
pt-online-schema-change拆分现有大表，需额外处理两阶段迁移逻辑：先建空扩展表 → 同步历史数据 → 切换读写 → 清理旧字段，中间任何一步失败都可能导致数据不一致 - InnoDB 的
row_format=compressed对独立TEXT表效果极佳，但主表若也启用压缩，需确认 MySQL 版本 ≥ 5.7.9 且innodb_file_per_table=ON，否则压缩无效
真正难的不是“要不要拆”，而是判断拆的边界——当单表平均行大小超过 8KB、或 TEXT 类字段总占比超 30% 时，拆分收益已远大于维护成本；但若只是偶尔存几条短日志，强行拆表反而增加 JOIN 开销和事务复杂度。
