写入性能下降若由Row size too large引发，必须优先精简字段类型再启用行压缩；因冗余字段会放大写入、索引、溢出页等开销，而压缩仅减少已有数据体积，无法根治设计冗余问题。
直接说结论：写入性能下降若由 Row size too large 触发或伴随大字段（如长 TEXT、JSON）频繁写入，单纯调大 innodb_log_file_size 或加索引没用；必须从「字段精简」和「行格式压缩」双路入手，且二者不可互换——压缩不能替代类型优化，类型优化也不能绕过压缩的适用前提。
为什么改字段类型比开压缩更优先？
因为字段冗余会直接放大后续所有操作的开销：写入时多拷贝、索引页更臃肿、溢出页更多、甚至触发 Row size too large (65535) 错误。压缩只对已存在的数据做减法，不解决“本不该存这么大”的问题。
-
VARCHAR(1024)存实际平均 20 字符的 URL？换成VARCHAR(255)或TINYTEXT - 用
ENUM或TINYINT UNSIGNED替代VARCHAR(20)的状态字段（如'active'/'inactive'） - 避免在主表存完整 HTML/JSON，提取关键字段建单独列，其余走归档表或外部存储
- 确认
innodb_file_per_table=ON和innodb_file_format=Barracuda已生效（MySQL 5.7+ 默认满足，但旧实例常被忽略）
启用 ROW_FORMAT=COMPRESSED 的硬性条件与踩坑点
不是执行 ALTER TABLE t ROW_FORMAT=COMPRESSED 就能生效。它依赖底层文件格式和表空间配置，漏掉任一环节都会静默失败（表结构显示 Row_format: Compact 却没压缩）。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 必须先确保
innodb_file_per_table=ON（动态变量，可在线设） - 必须用
Barracuda文件格式：SET GLOBAL innodb_file_format = 'Barracuda'（MySQL 5.7+ 已废弃该变量，但 5.6 及更早需显式设置） -
KEY_BLOCK_SIZE不是越小越好：KEY_BLOCK_SIZE=4虽压缩率高，但在 MySQL 8.0.2 之前有数据损坏风险；PolarDB 等增强版已默认启用polar_compressed_table_policy=ADJUST_KEY_BLOCK_SIZE自动兜底，但原生 MySQL 仍需手动避开 4K - ALTER 过程走的是
INPLACE REBUILD模式，期间表可读写，但 CPU 和 IO 压力明显上升——别在业务高峰跑
压缩后写入变慢？先看是不是误用了场景
压缩对写入性能的影响不是线性的，它高度依赖数据特征和硬件瓶颈。如果观察到写入延迟突增，大概率是以下情况之一：
- 表更新极其频繁（每秒数百次以上），每次写都触发压缩+解压+页重组，CPU 成为瓶颈（
top看mysqld用户态占比超 80%） - 用
KEY_BLOCK_SIZE=4或KEY_BLOCK_SIZE=2强压小块，导致单页压缩耗时翻倍，尤其在高并发下锁竞争加剧 - 表里混着大量短文本（如
VARCHAR(50)）和极长文本（如TEXT），压缩收益低，却承担了全部开销 - 没关掉
innodb_doublewrite=ON（默认开启），压缩页 + doublewrite buffer 写入放大更明显
真正有效的组合策略
生产中见效快、风险低的做法，是把「字段收缩」和「压缩」当作两道过滤网：第一道筛掉明显冗余，第二道才对剩余的大静态字段做物理压缩。比如一个日志表：
- 把
log_message TEXT拆成log_level TINYINT、module_name VARCHAR(64)、error_code SMALLINT，只留detail TEXT COMPRESSION='zlib'（MySQL 8.0.19+ 支持列级压缩） - 对整表启用
ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，不追求极限压缩率，换稳定性和维护性 - 定期用
SELECT data_length, index_length FROM information_schema.tables对比压缩前后空间变化，避免“以为压了其实没生效”
最易被忽略的一点：压缩表的 ALTER TABLE ... ADD COLUMN 或 MODIFY COLUMN 操作，即使只是加个 TINYINT，也可能触发全表重建——因为 InnoDB 需重写所有压缩页。这类 DDL 务必提前评估耗时，别当成轻量操作。
