alter table … row_format=compressed 会失败，因仅innodb支持该格式；必须同时指定key_block_size（如8），且表需为独立表空间、innodb_page_size≥key_block_size，否则静默忽略或报错。
ALTER TABLE … ROW_FORMAT=COMPRESSED 会失败？先确认存储引擎
MySQL 中只有 InnoDB 支持 ROW_FORMAT=COMPRESSED，MyISAM、Memory 或其他引擎直接报错：ERROR 1064 (42000): You have an error in your SQL syntax 或更明确的 ERROR 1005 (HY000): Can't create table。执行前务必检查：
SHOW CREATE TABLE your_table_name;确认
ENGINE=InnoDB，否则 ALTER 操作根本不会进入行格式处理阶段。
必须同时指定 KEY_BLOCK_SIZE 才能启用 COMPRESSED
ROW_FORMAT=COMPRESSED 单独写在 ALTER TABLE 里是无效的——InnoDB 要求你显式声明压缩单元大小。常见合法值是 1、2、4、8、16（单位：KB），对应页内压缩后的目标块大小。例如：
ALTER TABLE your_table_name ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;若省略
KEY_BLOCK_SIZE，MySQL 会静默忽略 ROW_FORMAT 设置，表实际仍为 ROW_FORMAT=Dynamic（默认）。
文件格式和参数必须匹配，否则 ALTER 会卡住或回滚
innodb_file_format 已在 MySQL 5.7.9+ 废弃，但底层仍依赖 innodb_file_per_table=ON 和 innodb_page_size=16384（默认）。如果表位于系统表空间（ibdata1），COMPRESSED 格式不被允许；必须确保该表是独立表空间（即建表时或通过 ALTER TABLE ... ENGINE=InnoDB 触发过独立 .ibd 文件生成）。另外，KEY_BLOCK_SIZE 不能大于 innodb_page_size，否则报错：ERROR 1005 (HY000): Unable to create table with KEY_BLOCK_SIZE > innodb_page_size。
压缩后空间没变小？检查数据是否可压缩 & 是否重建了索引
COMPRESSED 行格式只对 BLOB/TEXT/LONGTEXT 等大字段和部分二级索引页生效，普通 INT/VARCHAR 短字段压缩收益极低。更关键的是：ALTER 操作必须实际重建表（ALGORITHM=INPLACE 在多数压缩场景下不支持），否则旧数据仍存于未压缩页中。确认是否真正重建，查 information_schema.INNODB_SYS_TABLES：
SELECT NAME, ROW_FORMAT, SPACE from information_schema.INNODB_SYS_TABLES WHERE NAME LIKE 'your_db/your_table';注意
SPACE 值变化 —— 不变说明 ALTER 未触发物理重建，可能是隐式降级为 COPY 算法失败或被跳过。
真正起作用的不是那行 ALTER 语句本身，而是它背后触发的表重建过程、页分配逻辑和压缩字典加载时机——这些细节一旦漏掉任意一环，看起来改成功了，实际数据还在老格式里躺着。
