MySQL 5.7+ 启用 COMPRESSED 行格式需同时满足：innodb_file_per_table=ON、Barracuda 文件格式（5.7.7+ 默认启用但旧实例可能仍为Antelope）、KEY_BLOCK_SIZE取值1/2/4/8/16且不超innodb_page_size，且zlib库必须可用；缺一即静默失败或报错。
MySQL 5.7+ 默认不启用 Barracuda 文件格式
直接执行 ALTER TABLE t ROW_FORMAT=COMPRESSED 失败，最常见原因是 innodb_file_format 仍为默认的 Antelope。该格式根本不支持 COMPRESSED 或 DYNAMIC 行格式。
检查当前值：SHOW VARIABLES LIKE 'innodb_file_format'; —— 如果返回 Antelope，就必须切换。
-
SET GLOBAL innodb_file_format = 'Barracuda';是临时生效，重启后丢失 - 必须在
my.cnf（或my.ini）中显式写入：innodb_file_format = Barracuda - MySQL 5.7.7+ 已废弃该变量，改用
innodb_file_format_check = ON+ 启用innodb_file_per_table即可自动识别，但旧版本仍需手动设
KEY_BLOCK_SIZE 值非法或与 innodb_page_size 冲突
KEY_BLOCK_SIZE 不是随便填的数字，它代表压缩后的页大小（单位 KB），只允许取值 1、2、4、8、16，且不能超过当前 innodb_page_size（默认 16384，即 16KB）。
错误示例：KEY_BLOCK_SIZE=6 → 报错 Incorrect key_block_size；KEY_BLOCK_SIZE=32 → 报错 KEY_BLOCK_SIZE is not supported。
- 确认页大小：
SHOW VARIABLES LIKE 'innodb_page_size'; - 若为 16KB，
KEY_BLOCK_SIZE=16等价于无压缩，实际无效；推荐从8或4开始试 -
KEY_BLOCK_SIZE必须是纯数字，写成8k或"8"都会语法报错
innodb_file_per_table 未开启或表不在独立表空间
ROW_FORMAT=COMPRESSED 仅对独立表空间（每个表一个 .ibd 文件）生效。如果 innodb_file_per_table = OFF，所有表都存进系统表空间 ibdata1，此时指定压缩会被忽略或报错。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
检查方式：SELECT TABLE_NAME, TABLE_SCHEMA, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 't'; —— 若 CREATE_OPTIONS 为空或不含 row_format=compressed，大概率没生效。
- 先确认全局开关：
SHOW VARIABLES LIKE 'innodb_file_per_table';，必须为ON - 已有表即使开关已开，也不会自动迁移；需执行
ALTER TABLE t ENGINE=InnoDB;强制重建进独立表空间 - 某些云数据库（如阿里云 RDS）默认关闭该选项，且不允许用户修改，此时
COMPRESSED无法使用
zlib 压缩库未编译进 MySQL 或被禁用
页级压缩依赖 zlib（或可选 lz4），若 MySQL 编译时未链接 zlib，或运行时加载失败，就会报 Unsupported compression algorithm。
这在轻量环境（如 phpEnv、Docker 镜像、某些 macOS Homebrew 包）中尤为常见。
- 查错误日志：
mysqld --verbose --help | grep -i compress，看是否列出zlib - 尝试启用压缩前先测试：
CREATE TABLE t_test (id INT) ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;，失败则基本可判定 zlib 缺失 - 生产环境建议优先用
ROW_FORMAT=DYNAMIC替代 —— 它不依赖外部库，也能解决Row size too large (> 8126)问题，且兼容性更好
innodb_file_per_table = ON 这一项，ALTER TABLE ... COMPRESSED 就永远只是静默失败或报错不明。
