MySQL 8.0+已彻底移除查询缓存，phpEnv若搭载8.0及以上版本则无法开启；仅5.7且have_query_cache=YES时，需同时配置query_cache_type=1、query_cache_size>1MB、query_cache_limit才可能生效。
MySQL 查询缓存（Query Cache）在 phpEnv 环境下**无法开启，或者开了也无效**——前提是你的 phpEnv 搭载的是 MySQL 8.0+。当前（2026年4月）绝大多数新版 phpEnv 镜像或一键包默认集成 MySQL 8.0 或 8.1，而该功能已被官方彻底移除。
确认 MySQL 版本和 query_cache 是否存在
别急着改 my.cnf，先验证底层是否支持：
- 进入 phpEnv 的 MySQL 命令行（通常为
/phpenv/mysql/bin/mysql -u root -p） - 执行：
SHOW VARIABLES LIKE 'have_query_cache'; - 如果返回空结果，说明是 MySQL 8.0+，
have_query_cache这个变量本身就被删了 - 再试：
SHOW VARIABLES LIKE 'query_cache%';，若无任何输出，坐实不支持
很多 phpEnv 用户卡在这一步还反复修改配置、重启服务，其实只是徒劳。
如果你用的是 phpEnv + MySQL 5.7（极少数旧版）
仅当 SELECT VERSION(); 返回 5.7.x 且 SHOW VARIABLES LIKE 'have_query_cache' 返回 YES 时，才可继续配置：
立即学习“PHP免费学习笔记（深入）”；
- 编辑 phpEnv 的 MySQL 配置文件，路径通常是
/phpenv/etc/my.cnf或/phpenv/mysql/my.cnf - 在
[mysqld]段下添加三行（缺一不可）：query_cache_type = 1query_cache_size = 32Mquery_cache_limit = 2M -
query_cache_size必须 > 1048576（即 >1MB），设为0或1M都等于没开 - 保存后重启 MySQL：
/phpenv/mysql/bin/mysqld restart（或用 phpEnv 自带的phpenv restart mysql）
注意：phpEnv 中的 MySQL 启动脚本可能不识别 service mysql restart，硬套 Linux 通用命令会失败。
Qcache_hits 一直为 0？不是配错了，是根本没生效
即使配置写对、服务重启成功，也常见 SHOW STATUS LIKE 'Qcache%' 中 Qcache_hits 始终为 0。原因不止一种：
- 查询语句含
NOW()、RAND()、USER()、@var等非确定性元素 → 不进缓存 - 表上有任何
INSERT/UPDATE/DELETE，对应所有缓存条目立即失效 → 高频写场景下命中率趋近于零 - 结果集超过
query_cache_limit（默认 1MB）→ 被跳过 - 使用了
SQL_NO_CACHE，或连接时加了NO_CACHE选项
此时看 Qcache_not_cached 和 Qcache_lowmem_prunes 比看 Qcache_hits 更有诊断价值。
替代方案比硬扛 Query Cache 更实际
phpEnv 本质是本地/测试环境，与其折腾一个被 MySQL 官方废弃、且在并发写压力下反拖慢性能的机制，不如转向更可控的方案：
- PHP 层用
apcu_store()/apcu_fetch()缓存查询结果（需启用 APCu 扩展） - WordPress 类应用直接装 WP Super Cache 或 Redis Object Cache 插件
- 自己写逻辑时，在 PDO 查询前后加一层
md5($sql . json_encode($params))作 key 存到 APCu - phpEnv 若已装 Redis，
redis->setex($key, 300, $result)几行代码就能替代整套 Query Cache
真正容易被忽略的是：Query Cache 的锁粒度是全局的，每次缓存写入/失效都要加全局锁 —— 在 phpEnv 这种多站点共用 MySQL 的场景下，反而比不缓存更卡。
