mysql 8.0+ 已彻底移除 query cache，5.7 及更早版本中因全局锁、整表失效、内存碎片和sql字节级匹配等缺陷，中低端服务器尤其不适用；推荐改用 innodb buffer pool、redis 应用层缓存或覆盖索引优化。
MySQL 8.0+ 已彻底移除 Query Cache，任何尝试启用它的配置都会失败或被忽略；5.7 及更早版本中，即使设了 query_cache_type=1，只要表有写操作，缓存就基本无效——这不是调得不够细，而是设计上就不适合中低配服务器。
为什么中低端服务器尤其不该碰 Query Cache
中低端机器通常 CPU 核心少、内存有限、I/O 能力弱，而 Query Cache 在这类环境里反而放大缺陷：
-
query_cache_mutex是全局锁，单核或双核下线程排队等锁比执行查询还耗时 - 缓存失效不按行/按键，而是“整表清空”，哪怕只更新一条记录，所有关联 SELECT 缓存全丢
- 缓存块管理开销大，
query_cache_size=32M实际可用内存可能不到 25M，碎片还随时间恶化 - 命中需 SQL 字节级完全一致，ORM 自动生成的 SQL（带空格、换行、参数占位符）几乎无法复用
替代方案一：把 innodb_buffer_pool_size 设对
这是中低端服务器性价比最高的“缓存”——它不缓存结果，而缓存数据页本身，且无锁、无失效风暴、命中后直接走内存读。
- 若总内存 ≤ 2GB，设为
innodb_buffer_pool_size = 1G（别贪心留足系统和 MySQL 其他开销） - 若用的是 SSD，可适当提高比例，但超过 70% 后收益急剧下降
- 检查是否生效：
SHOW STATUS LIKE 'Innodb_buffer_pool_read%'，Innodb_buffer_pool_read_requests÷Innodb_buffer_pool_reads> 99% 才算健康 - 避免陷阱：不要设成
1024M却忘了单位是字节——必须带单位，如1G或1024M，否则 MySQL 当作 1024 字节处理
替代方案二：用 Redis 做应用层缓存，只缓确定性查询
不是所有 SELECT 都值得缓，重点盯住三类：配置类、维度类、聚合类。它们更新少、SQL 稳定、结果小。
- 配置表（如
site_config）：启动时加载进 Redis，用SETEX config:main 3600 ...，应用直连 Redis，绕过 MySQL - 城市/分类列表（如
SELECT id,name FROM regions WHERE level=2）：加个WHERE updated_at 条件，缓存 1 小时足够 - 慢聚合（如
SELECT COUNT(*) FROM orders WHERE status='paid' AND created_at > CURDATE()）：改用定时任务每 5 分钟跑一次，结果存cache:daily_paid_count - 关键提醒：别缓
SELECT * FROM users WHERE id=?这种带参数的通用查询——除非你用user:123这样的 key 拼接逻辑，否则极易击穿
替代方案三：用覆盖索引 + 少查字段，让查询快到不需要缓存
很多“慢查询”本质是回表太多、IO 太高。在中低端机器上，优化索引比加缓存见效更快、更稳。
- 找出慢日志里高频的
SELECT，看EXPLAIN的type是否为ALL或index，Extra是否含Using filesort或Using temporary - 例如查订单状态统计：
SELECT status, COUNT(*) FROM orders GROUP BY status，建INDEX idx_status ON orders(status)就够，不用缓存 - 再如用户中心页：
SELECT name, avatar, last_login FROM users WHERE id=123，建INDEX idx_id_cover ON users(id, name, avatar, last_login)，直接索引覆盖，0 回表 - 注意：复合索引字段顺序必须匹配
WHERE条件顺序，id在前才能用于等值查找
真正卡住中低端 MySQL 性能的，往往不是“没缓存”，而是 buffer pool 太小、索引缺失、SQL 返回了太多冗余字段。Query Cache 的消失不是功能倒退，而是把资源腾出来做更底层、更普适的优化——比如现在一个 SELECT 走覆盖索引，比当年靠 Query Cache 命中快得多，也稳得多。
