ThinkPHP 的 database.php 中添加 'compress' => true 无效，因框架未将该参数映射到 PDO 或 mysqli 驱动层；需通过 DSN 添加 compress=1（限 mysqlnd）或自定义连接器调用 mysqli::options(MYSQLI_OPT_COMPRESS, true) 才能生效。
ThinkPHP 的 database.php 配置里没有 compress 参数，直接加会无效甚至报错。 MySQL 协议层的连接压缩（即 mysqlnd 的 MYSQLI_OPT_COMPRESS）不被 ThinkPHP 原生封装支持，框架底层 PDO 或 mysqli 驱动也未暴露该开关。所谓“开启 compress 降低带宽”是常见误解，实际生效需绕过框架手动干预驱动层。
为什么 database.php 里加 'compress' => true 没用
ThinkPHP 的数据库配置数组字段由框架解析后映射到 PDO 构造参数或 mysqli::options() 调用，但 compress 不在白名单中。即使你写入：'compress' => true，框架既不会传给 PDO 的 $options 数组，也不会调用 mysqli::options(MYSQLI_OPT_COMPRESS, true)。结果是配置被静默忽略，连接仍走未压缩协议。
- 查看 ThinkPHP 源码（
think\db\connector\Mysql类），其connect()方法只处理type、hostname、hostport等约 15 个固定键，不含compress - PDO 构造时若要启用压缩，必须在 DSN 中显式添加
;compress=1（仅限 mysqlnd），且 PHP 需启用mysqlnd驱动而非libmysqlclient - mysqli 方式则必须在
new mysqli()后立即调用options(MYSQLI_OPT_COMPRESS, true)，而 ThinkPHP 并未提供钩子时机
真能压缩的两种可行路径
若确实需要 MySQL 连接压缩（比如跨公网访问云数据库、带宽敏感场景），只能放弃标准配置，改用底层直连或自定义连接器：
- 用 DSN 字符串 +
compress=1：仅限 mysqlnd 驱动，DSN 格式为mysql:dbname=test;host=127.0.0.1;compress=1，再传给Db::connect($dsn)；但注意 ThinkPHP 6.1+ 的Db::connect()对 DSN 解析不支持compress，需降级到 6.0 或自行 patchthink\db\connector\Mysql::parseDsn() - 手写 mysqli 连接器：继承
think\db\connector\Mysql，重写connect()方法，在new mysqli()后插入$this->link->options(MYSQLI_OPT_COMPRESS, true)，再注册为自定义类型（'type' => 'mycompressmysql'） - 更现实的做法：把压缩任务交给网络层——用 SSH 隧道（
ssh -L 3307:db-host:3306 user@jump）或 Cloudflare Tunnel，它们自带流量压缩，无需改代码
容易被忽略的兼容性雷区
即使强行启用 MySQL 压缩，也会触发一系列隐性问题：
立即学习“PHP免费学习笔记（深入）”；
- MySQL 8.0+ 默认禁用
protocol_compression_algorithms，需在服务端显式设置SET GLOBAL protocol_compression_algorithms = 'zlib'，否则客户端请求被拒绝 - 压缩后 max_allowed_packet 限制会动态变化，ThinkPHP 的
fetchColumn()等方法若读取超长文本可能抛出MySQL server has gone away - 部分云数据库（如阿里云 RDS、腾讯云 CDB）明确禁用连接压缩选项，控制台会直接拦截含
compress=1的连接请求 - 开启压缩后，
SHOW PROCESSLIST中的 Command 列会显示Connect Compressed，这是唯一可验证是否生效的日志线索
真正影响带宽的从来不是 SQL 文本本身，而是结果集体积。与其折腾连接压缩，不如在业务层做减法：查前加 field() 显式指定字段、用游标分页替代 LIMIT OFFSET、对大字段（如 JSON、TEXT）单独异步加载——这些才是在 ThinkPHP 体系内可控、可测、不踩坑的带宽优化点。
