MySQL 5.6 支持 InnoDB 表压缩，但需同时满足三个硬性条件：innodb_file_format 必须设为 barracuda、innodb_file_per_table 必须为 ON、建表或修改时须显式指定 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4（或8/16），缺一不可。
确认 MySQL 5.6 是否满足压缩前提条件
MySQL 5.6 支持 InnoDB 表压缩，但不是开箱即用。必须同时满足三个硬性条件，缺一不可：
-
innodb_file_format必须设为barracuda（默认是antelope） -
innodb_file_per_table必须为ON（否则表只能建在共享表空间ibdata1中，而ROW_FORMAT=COMPRESSED对共享表空间无效） - 建表或修改表时显式指定
ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4（或8、16），不能只写ROW_FORMAT=COMPRESSED
检查当前值：SHOW VARIABLES LIKE 'innodb_file_format';SHOW VARIABLES LIKE 'innodb_file_per_table';
若不满足，需在 my.cnf 中添加并重启 mysqld：
innodb_file_format = barracuda innodb_file_per_table = ON
注意：innodb_file_format_max 在 5.6 中只读，无法动态修改；改配置后必须重启，且已有表不会自动迁移。
创建新压缩表时的 SQL 写法与常见错误
语法顺序和参数值非常关键，错一个就会退化为默认 DYNAMIC 格式，不压缩：
-
KEY_BLOCK_SIZE必须是纯数字（如4），写成4k、4K或4KB全部报错 -
ROW_FORMAT=COMPRESSED和KEY_BLOCK_SIZE必须同时出现，且不能省略ENGINE=InnoDB - 推荐显式写全：
ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4
正确示例：
CREATE TABLE logs ( id BIGINT PRIMARY KEY, content TEXT ) ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4;
错误示例（看似只差一点，实则无效）：
-
ROW_FORMAT=COMPRESSED单独使用 → 实际走DYNAMIC -
KEY_BLOCK_SIZE=4k→ 报错ERROR 1064 (42000) - 没设
innodb_file_per_table=ON→ 表建在ibdata1，压缩被忽略
对已有 InnoDB 表启用压缩的实际代价
ALTER TABLE t ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4 看似一行命令，本质是全表重建：
- MySQL 会读取原
.ibd文件所有页 → 按新格式压缩写入临时文件 → 替换原文件 - 过程锁表（5.6 不支持
ALGORITHM=INPLACE对压缩格式变更）；高并发写场景慎用 - 磁盘空间需预留至少 1× 原表大小（重建期间新旧文件共存）
- 压缩效果取决于数据重复度，文本类字段（如日志、JSON）通常有 30%–40% 节省，数值型提升有限
验证是否生效：SHOW CREATE TABLE t; 看输出中是否含 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4SHOW TABLE STATUS LIKE 't'; 对比 Data_length 是否明显下降（需等 buffer pool 刷新后才稳定）
别拿 InnoDB 压缩去对标 MyISAM 压缩表
MyISAM 的 myisampack 是离线只读压缩，而 InnoDB 压缩是在线、可读写的，二者设计目标完全不同：
- MyISAM 压缩后禁止
INSERT/UPDATE/DELETE，适合归档表；InnoDB 压缩表完全支持 DML - MyISAM 压缩靠字典编码 + 前缀压缩，InnoDB 压缩依赖
zlib（默认 level=6），更通用但 CPU 开销略高 - MyISAM 压缩文件（
.MYD）可直接mv备份；InnoDB 的.ibd绝对不能手动移动，必须走DISCARD/IMPORT TABLESPACE - 压缩率不能简单对比：MyISAM 可达 70%，但那是以牺牲写能力为代价；InnoDB 的 30%–40% 是在保证事务、崩溃恢复、MVCC 前提下的“带宽换空间”
真正容易被忽略的一点：即使你成功启用了 InnoDB 压缩，如果应用频繁更新大字段（比如反复覆盖 TEXT），压缩页可能频繁分裂和重组，实际磁盘节省会被抵消——压缩更适合写少读多、内容静态的场景，比如日志归档、历史快照、报表宽表。
