MySQL 8.0+（含phpEnv默认集成版本）已彻底删除query_cache_type和query_cache_size，配置会报错或无效；真正影响性能的是innodb_buffer_pool_size等核心参数。
query_cache_type 和 query_cache_size 在 phpEnv 环境下基本无效——不是你配错了，而是 MySQL 版本根本不支持。
phpEnv 默认集成的是 MySQL 8.0 或 MariaDB 10.6+，这两个版本已彻底移除查询缓存模块。如果你在 my.cnf 里写了 query_cache_type = 1，MySQL 启动时会直接报错：Unknown variable 'query_cache_type'，甚至无法启动。
为什么在 phpEnv 里查不到查询缓存相关状态？
执行 SHOW VARIABLES LIKE 'query_cache%'; 返回空结果或全为 OFF/0，常见原因只有两个：
- 你用的是 MySQL 8.0+（phpEnv 当前主流版本），该功能已被硬性删除，变量根本不存在
- 你误用了 MariaDB 镜像（如
mariadb:10.11），它虽保留部分兼容变量，但默认禁用且不生效
验证方式很简单：
立即学习“PHP免费学习笔记（深入）”；
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT VERSION();如果返回类似
8.0.33 或 10.6.12-MariaDB，就不用再折腾查询缓存了——它不在那儿。
phpEnv 中真正影响查询性能的配置项
MySQL 8.0 的性能瓶颈几乎从不来自“缓存没开”，而集中在内存、I/O 和执行计划上。重点关注这几个可调参数：
-
innodb_buffer_pool_size：应设为物理内存的 50%–75%，phpEnv 虚拟机常只给 2GB 内存，默认 128MB 严重不足 -
innodb_log_file_size：太小会导致频繁刷盘，建议设为innodb_buffer_pool_size的 25% -
max_connections：phpEnv 默认常为 151，高并发测试时容易Too many connections -
tmp_table_size和max_heap_table_size：影响 GROUP BY、ORDER BY 是否落磁盘临时表
这些值改完需重启 MySQL（phpenv service mysql restart），且不能只改 my.cnf 里的全局段——phpEnv 的配置加载顺序可能覆盖自定义设置，建议直接编辑其生成的配置文件（通常在 ~/.phpenv/versions/*/etc/my.cnf）。
查询变慢？先别怀疑“缓存失效”，检查这三件事
很多用户以为“刚执行过的 SELECT 又慢了”是缓存丢了，实际往往和缓存毫无关系：
-
EXPLAIN FORMAT=JSON查看执行计划是否走了索引；type是ALL就说明在全表扫描 - 检查
information_schema.INNODB_TRX是否有长事务未提交，它会阻塞 MVCC 清理，拖慢后续查询 - 用
SHOW PROCESSLIST;观察是否有Waiting for table metadata lock，这是 DDL（如ALTER TABLE）引发的典型阻塞，和缓存无关
phpEnv 的轻量特性决定了它对锁竞争更敏感，一个未提交事务或慢 ALTER 就会让整个数据库“卡住几秒”，看起来像缓存失效，其实是元数据锁在排队。
真正的性能瓶颈从来不在“要不要缓存”，而在“数据怎么读得快”。MySQL 8.0 的查询缓存不是被“关掉”的，是被“删掉”的——设计上它无法适应现代应用的并发模型。与其花时间调参，不如把精力放在索引优化、连接池复用、或加一层 Redis 缓存固定结果集上。那些在 phpEnv 里反复修改 query<em>cache</em>* 却没效果的配置，大概率从一开始就没被加载进进程里。
