CI3开启compress=>TRUE传输失败本质是MySQL协议压缩能力未对齐，需验证服务端have_compression是否为YES、PHP zlib扩展是否启用、mysqli是否支持压缩，并据失败现象（连接失败/乱码/偶发）定位根因。
CI3（CodeIgniter 3）中开启 compress => TRUE 后出现传输失败，本质是启用了 MySQL 协议层的压缩通信，但服务端或客户端不支持、不匹配或资源受限导致握手失败或数据解压异常。这不是配置“写错”，而是协议能力未对齐，需从压缩能力、环境兼容性、错误表现三方面切入。
确认 MySQL 服务端是否真正支持压缩协议
CI3 的 compress 依赖 MySQL 服务端的 have_compression 能力，而非仅看版本号：
- 登录数据库执行：
SHOW VARIABLES LIKE 'have_compression';，返回YES才表示服务端编译时启用了 zlib 支持；若为DISABLED或NO，即使配置了compress => TRUE，连接也会静默失败或降级失败 - MySQL 5.7+ 默认关闭压缩支持，需在
my.cnf中显式添加loose-have-compression=ON（注意 loose- 前缀），并重启 mysqld - 云数据库（如阿里云 RDS、腾讯云 CDB）通常默认禁用压缩协议，需在控制台参数模板中查找
have_compression或protocol_compression_algorithms并启用
检查 PHP MySQLi 驱动与 zlib 依赖是否就绪
PHP 层必须能调用 zlib 解压原始网络流，否则收到压缩包会直接解析失败：
- 运行
php -m | grep -i zlib，确认 zlib 扩展已启用；若无输出，需安装并启用extension=zlib - 检查
mysqli是否支持压缩：执行php -r "var_dump(function_exists('mysqli_get_client_info'));"，再验证mysqli_options($link, MYSQLI_OPT_COMPRESS, true)可被调用（CI3 底层即使用此 API） - 某些精简版 PHP 容器（如 Alpine 上的 php:alpine）默认不带 zlib-dev 编译依赖，会导致 mysqli 编译时跳过压缩支持——需重装带完整依赖的 mysqli 扩展
观察具体失败现象来缩小范围
不同失败模式指向不同根因，避免盲目重启：
-
连接阶段失败（白屏/500/空响应）：大概率是服务端不支持压缩，或 PHP zlib 缺失。开启
db_debug = TRUE后通常报MySQL server has gone away或Lost connection to MySQL server during query，而非明确的压缩错误 - 查询执行后返回乱码、截断或字段缺失：说明连接建立成功，但解压失败，典型表现为 BLOB 字段内容损坏、TEXT 字段末尾丢失、中文变问号——此时重点查 PHP zlib 和网络中间件（如代理、防火墙）是否干扰压缩流
-
仅高并发下偶发失败：压缩/解压过程消耗 CPU 和内存，若服务器资源紧张（尤其小内存容器），zlib 解压可能超时或崩溃，建议监控
top中php-fpm进程的 %MEM 和 %CPU
临时验证与安全回退方式
不建议长期开启压缩，除非实测带宽成为瓶颈且稳定可用：
- 快速验证：在
database.php中临时设'compress' => FALSE，确认功能恢复，即可锁定问题与压缩相关 - 替代优化：相比协议压缩，更推荐在应用层做轻量级优化——如减少 SELECT *、用
->select('id,name')显式指定字段、启用查询缓存、加 CDN 缓存静态结果 - 生产环境慎用：CI3 官方文档明确标注
compress为实验性选项，部分 MySQL 版本（如 8.0.23+）已标记弃用，后续驱动可能移除支持
