innodb表压缩能降低磁盘占用但有严格前提：需innodb_file_per_table=on、mysql≥5.7.9、建在独立表空间；key_block_size须为1/2/4/8/16，推荐从8开始测试；仅高熵字段（如text/json）受益，加密或短字段可能增大约10%–20%空间。
直接说结论：InnoDB 表压缩能有效降低磁盘占用，但只对特定数据类型和访问模式有效；ROW_FORMAT=COMPRESSED 不是“开个开关就省空间”，它依赖 innodb_file_per_table=ON、正确的 KEY_BLOCK_SIZE 值，且对短字段或加密二进制数据可能反而增大约 10%–20% 空间。
建表前必须确认的三个硬性条件
很多人执行 CREATE TABLE ... ROW_FORMAT=COMPRESSED 后发现 .ibd 文件大小没变，根本原因是前置条件不满足，MySQL 会静默退化为 ROW_FORMAT=Dynamic：
-
SHOW VARIABLES LIKE 'innodb_file_per_table'必须返回ON；若为OFF，所有表都落在ibdata1（系统表空间），而系统表空间不支持压缩 - MySQL 版本需 ≥ 5.7.9；5.7.6–5.7.8 需手动加载压缩监控引擎，5.6 及更早版本完全不支持
ROW_FORMAT=COMPRESSED - 无需显式设置
innodb_file_format=Barracuda（该变量在 5.7.7+ 已废弃），但表必须建在独立表空间或通用表空间中——ibdata1永远无效
KEY_BLOCK_SIZE 怎么选？不是越小越好
KEY_BLOCK_SIZE 决定压缩后页的实际尺寸（单位 KB），但它不是压缩率控制参数，而是影响缓冲池行为和 I/O 效率的关键阈值：
- 合法值只有
1、2、4、8、16；设成6或12会报错Incorrect key_block_size -
KEY_BLOCK_SIZE=16等价于不压缩（因默认innodb_page_size=16384），但对BLOB/TEXT字段仍有轻微头开销收益 - 设太小（如
KEY_BLOCK_SIZE=1）会导致单页存不下一行，触发页分裂和额外重组开销，反而增大.ibd；建议从8起测，再根据实际压缩比下调 - 压缩后页在缓冲池中同时存两份：一份压缩版（占
KEY_BLOCK_SIZE内存）、一份解压版（固定 16KB）；innodb_buffer_pool_size需预留额外空间
哪些字段真正受益？别压缩错对象
压缩效果完全取决于数据熵值。以下场景实测压缩比差异极大：
- 高收益：
TEXT存日志、JSON、HTML；VARCHAR(1000)存用户评论、配置项——重复字符串多，zlib（LZ77）压缩比常达 40%–70% - 低收益甚至负收益：
INT+VARCHAR(20)用户名/邮箱组合；已加密字段（如 AES 加密后的VARBINARY）——接近随机分布，压缩后体积可能 +5%～15% - 注意：索引也同步压缩，二级索引字段若含长文本，压缩收益会叠加；但主键过长（如 UUID）会拖慢 B-Tree 导航，得权衡
ALTER TABLE 压缩已有大表的现实代价
对线上百万行以上表执行 ALTER TABLE t ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8 是高风险操作：
- MySQL 5.7/8.0 默认使用 inplace DDL，但压缩变更仍需重建聚簇索引，全程锁表（
ALGORITHM=COPY模式），期间写入阻塞 - 临时空间需求 ≈ 原表大小；若磁盘剩余空间不足 2× 原
.ibd，操作会失败并残留临时文件 - 无平滑迁移方案；不能边写边压。建议在业务低峰执行，并提前用测试库验证压缩比和查询延迟变化
- 验证是否生效：
SELECT TABLE_NAME, ROW_FORMAT, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='t';——CREATE_OPTIONS应含KEY_BLOCK_SIZE=8
最易被忽略的一点：压缩节省的是磁盘空间和 I/O 次数，不是内存或 CPU；如果缓冲池放不下热数据，压缩反而因解压开销拉低 QPS。务必先用 SELECT data_length / table_rows 算出平均行长，再结合字段类型判断是否值得压。
