mysql 8.0起已彻底废弃查询缓存（query_cache），因其表级失效机制导致命中率低且易引发性能下降；应优先优化innodb缓冲池、应用层缓存及sql索引。
MySQL 查询缓存（query_cache）已彻底废弃，别再配置它
MySQL 8.0 起已完全移除 query_cache_type、query_cache_size 等所有查询缓存相关参数。即使你在 5.7 中开启，也会因表级变更（如 INSERT/UPDATE）导致整张表对应的所有缓存失效，实际命中率极低。很多线上服务反而因维护缓存锁造成性能下降。
实操建议：
- 确认版本：
select VERSION();，若 ≥ 8.0，直接忽略 query cache 配置项 - 5.7 环境下若仍启用，请监控
Qcache_hits与Qcache_inserts比值，低于 0.2 就该关掉 - 配置文件中删除或注释掉
query_cache_type=1和query_cache_size=xxx
InnoDB 缓冲池（innodb_buffer_pool_size）是真正的性能核心
这是 MySQL 最关键的内存缓存机制：它把频繁访问的表数据和索引页缓存在内存中，避免每次查询都读磁盘。它的效果远超旧式 query cache，且由存储引擎自动管理，无需 SQL 层干预。
实操建议：
- 生产环境建议设为物理内存的 50%–75%，但需预留至少 2GB 给 OS 和其他进程
- 检查当前使用率：
SHOW ENGINE INNODB STATUSG查看 “Buffer pool hit rate” —— 持续低于 990/1000（即 99%）说明不够用 - 动态调整（8.0+）：
SET GLOBAL innodb_buffer_pool_size = 4294967296;（4GB），但注意该值必须是innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的整数倍 - 避免设得过大导致 swap，可观察
free -h中的available是否持续低于 1GB
应用层缓存（redis / memcached）和 MySQL 协作的关键点
真正提升读性能的主流方案是“MySQL + 应用缓存”，但容易因缓存与数据库不一致导致脏数据。协作不是简单加个 SET，而是要对写操作做精细控制。
实操建议：
- 读路径：优先查 Redis，未命中再查 MySQL，并将结果
SET回缓存（带合理EXPIRE，如 300 秒） - 写路径：必须执行「先删缓存，再更新 DB」或「先更新 DB，再删缓存」——二者选其一并严格统一，禁止只更新不删
- 高并发写时，删缓存后可能有旧数据回写（cache stampede），可用
SET … NX EX或分布式锁兜底 - 对主键明确的查询（如
SELECT * FROM user WHERE id = 123），缓存 key 建议设计为user:123，而非模糊的user_list类全量缓存
临时表、排序、JOIN 的内存缓存靠 sort_buffer_size 等参数，但别乱调
这类会话级缓存用于加速 ORDER BY、GROUP BY、JOIN 等操作，但它们按连接分配，设太大反而引发内存爆炸，尤其在连接数高的场景。
实操建议：
- 默认值通常够用：
sort_buffer_size（默认 256KB）、join_buffer_size（默认 256KB）、read_buffer_size（默认 128KB） - 仅当慢日志中出现
using filesort或Using temporary且对应 SQL 频繁执行时，才考虑局部调大 - 绝对不要在全局配置里设成几 MB —— 若有 1000 个连接，就多占几个 GB 内存
- 更优解是优化 SQL 和索引：比如为
ORDER BY created_at加联合索引(status, created_at)，往往比调 buffer 更有效
真正卡住性能的，常常不是“有没有缓存”，而是“缓存哪一层、怎么失效、谁负责一致性”。InnoDB buffer pool 是基础，应用缓存是杠杆，而错误的 query cache 配置或盲目调大 session buffer，反而会成为隐性瓶颈。