MySQL表的ROW_FORMAT=COMPRESSED由InnoDB引擎控制，PHP仅执行SQL命令；需启用innodb_file_per_table、正确设置KEY_BLOCK_SIZE（1/2/4/8/16KB），并注意MySQL版本兼容性及权限配置。
MySQL 表的 ROW_FORMAT=COMPRESSED 和 PHP 无关
PHP 本身不控制 MySQL 表的压缩级别。所谓“PHP 设置表压缩级别”是个常见误解——COMPRESSED 行格式、KEY_BLOCK_SIZE、页压缩等，全部由 MySQL 服务端（InnoDB 存储引擎）决定，PHP 只是通过 SQL 发起操作请求。
如果你在 PHP 中执行 CREATE TABLE 或 ALTER TABLE 并指定压缩参数，真正生效的是 MySQL 的配置与权限，不是 PHP 的设置。
如何用 PHP 执行压缩表创建或修改
需确保 MySQL 已启用 innodb_file_per_table=ON、innodb_file_format=Barracuda（旧版本）、且表空间支持压缩（如使用 innodb_file_per_table + innodb_page_size=16k 时，KEY_BLOCK_SIZE 才有效）。
-
KEY_BLOCK_SIZE值必须是 1、2、4、8 或 16（单位：KB），对应压缩率约 2× ~ 5×，值越小压缩越强，但 CPU 和 I/O 开销越高 - 仅对
ROW_FORMAT=COMPRESSED生效；DYNAMIC或REDUNDANT格式下设KEY_BLOCK_SIZE会被忽略 - PHP 中需用 PDO 或 mysqli 执行 DDL，例如：
CREATE TABLE `logs_compressed` ( `id` BIGINT PRIMARY KEY, `data` TEXT ) ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4;
执行前建议检查：SHOW VARIABLES LIKE 'innodb_file_per_table'; 和 SELECT @@innodb_file_format;（MySQL 5.7+ 已弃用该变量，实际以 innodb_file_per_table + 表空间类型为准）。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
立即学习“PHP免费学习笔记（深入）”；
PHP 调用时容易踩的坑
即使 SQL 写对了，仍可能失败，原因多与 MySQL 服务端状态有关：
- 用户无
CREATE/ALTER权限，报错类似Access denied for user ... to database ... - 表已存在且结构不兼容，
ALTER TABLE ... ROW_FORMAT=COMPRESSED会失败，需先SET GLOBAL innodb_file_per_table=ON;（需 SUPER 权限）并重建表 - MySQL 8.0+ 默认禁用
Barracuda，ROW_FORMAT=COMPRESSED会被静默转为DYNAMIC，需确认innodb_default_row_format=dynamic是否覆盖了你的意图 - PHP 连接未设
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，导致压缩失败却无报错，只返回 false
压缩效果验证不能只靠 PHP
PHP 拿不到底层页压缩率，只能间接验证：
- 查
information_schema.INNODB_SYS_TABLES：字段ROW_FORMAT和ZIP_PAGE_SIZE（MySQL 5.7）或CREATE_OPTIONS（含KEY_BLOCK_SIZE=4） - 对比
DATA_LENGTH和INDEX_LENGTH在压缩前后的变化（用SHOW TABLE STATUS LIKE 'table_name'） - 真实压缩收益取决于数据重复度和字段类型，纯随机字符串或已加密内容几乎不压缩，别指望 PHP 层能“调优”出额外空间节省
真正影响压缩效率的是 InnoDB 的 innodb_page_size、缓冲池大小、以及是否启用透明页压缩（Linux zlib 支持），这些都和 PHP 配置毫无关系。
