MySQL的ROW_FORMAT=COMPRESSED需InnoDB+Barracuda+innodb_file_per_table=ON+显式KEY_BLOCK_SIZE，PHP仅执行SQL；8.0.29+已弃用，推荐透明页压缩；压缩效果取决于数据重复度，需实测验证。
MySQL 的 ROW_FORMAT=COMPRESSED 不是 PHP 创建的
PHP 本身不创建或管理 MySQL 的压缩表。所谓“PHP 创建压缩表”，实际是 PHP 通过 PDO 或 mysqli 执行 SQL 命令，让 MySQL（且仅限 InnoDB 引擎 + Barracuda 文件格式）启用页级压缩。关键控制点在 SQL 语句和 MySQL 配置，不在 PHP 代码逻辑里。
创建 COMPRESSED 表必须满足的 4 个前提
缺一不可，否则 CREATE TABLE ... ROW_FORMAT=COMPRESSED 会静默退化为 COMPACT 或直接报错：
- MySQL 版本 ≥ 5.7（推荐 8.0+），且使用
InnoDB存储引擎 -
innodb_file_format必须为Barracuda（MySQL 5.7.7+ 已弃用该变量，但需确保innodb_file_per_table=ON） -
innodb_file_per_table=ON（必须开启，压缩表只能存于独立 .ibd 文件） - 建表时显式指定
KEY_BLOCK_SIZE（如KEY_BLOCK_SIZE=4），值必须是 1/2/4/8/16（单位：KB），且 ≤ 当前innodb_page_size（通常为 16KB）
PHP 中执行建表语句的典型写法（含错误防护）
不要只拼接 SQL，要检查 MySQL 实际生效的行格式：
try {
$pdo = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo->exec("CREATE TABLE compressed_log (
id INT PRIMARY KEY AUTO_INCREMENT,
content LONGTEXT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB
ROW_FORMAT=COMPRESSED
KEY_BLOCK_SIZE=4");
// 验证是否真被压缩
$stmt = $pdo->query("SELECT ROW_FORMAT FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA='test' AND TABLE_NAME='compressed_log'");
$format = $stmt->fetchColumn();
if ($format !== 'Compressed') {
throw new Exception("Compression not active: ROW_FORMAT is '$format'");
}
} catch (PDOException $e) {
error_log("Failed to create compressed table: " . $e->getMessage());
}
注意：ROW_FORMAT=COMPRESSED 在 MySQL 8.0.29+ 已标记为废弃，官方倾向用透明页压缩（innodb_page_compression=ON）替代，但老项目仍大量使用此方式。
立即学习“PHP免费学习笔记（深入）”；
压缩表节省空间，但代价很实在
不是所有场景都适合。真实影响取决于数据类型和重复度：
-
真正省空间：含大量重复字符串、JSON、HTML、日志文本的
TEXT/VARCHAR列；BLOB 类型效果也明显 - 几乎不省甚至更费：纯数字、UUID、已加密或已压缩（如 gzip base64）的内容；压缩反而增加 CPU 开销和存储碎片
- 性能折损：每次读写都要解压/压缩，CPU 使用率上升；高并发随机读可能因解压延迟导致响应变慢
- 备份与迁移风险：mysqldump 默认不保留
KEY_BLOCK_SIZE，恢复后可能丢失压缩属性；物理备份（xtrabackup）更稳妥
压缩表不是开关式优化，得先用 SELECT AVG(LENGTH(content)) FROM your_table 看平均长度，再抽样 COMPRESS() 测试压缩率，最后在从库灰度验证 I/O 和 CPU 变化。
