mysql查询缓存仅适用于5.7及更早版本的读多写少静态SQL场景，8.0+已移除；真正需优先调优的是InnoDB缓冲池（innodb_buffer_pool_size），建议设为物理内存60%–75%，并配置多实例避免锁争用。
MySQL 缓存不是“开个开关就能提速”的黑盒，而是分层、有取舍、需配合业务场景的系统性配置。盲目启用或堆内存反而会拖慢写入、引发锁争用，甚至在 MySQL 8.0+ 中根本无效——因为 query_cache 已被彻底移除。
先确认你用的是哪个 MySQL 版本，再决定要不要碰查询缓存
MySQL 5.7 及更早版本中，query_cache_type 和 query_cache_size 确实能缓存 select 结果，但仅适用于读多写少、SQL 完全静态（不含 NOW()、RAND()、用户变量等）的场景。一旦表有任意 UPDATE/INSERT/delete，所有关联该表的缓存立即失效——高并发写入下，命中率常低于 10%，反而因维护缓存元数据增加 CPU 开销。
- 检查是否启用：
SHOW VARIABLES LIKE 'query_cache%';，若query_cache_size= 0 或query_cache_type= OFF，说明已禁用 - 监控效果：
SHOW STATUS LIKE 'Qcache%';，重点关注Qcache_hits/Qcache_inserts比值，长期低于 1:1 就该关 - MySQL 8.0+ 用户：直接跳过这步——
query_cache相关参数已被删除，配置即报错
真正值得调的只有 InnoDB 缓冲池（Buffer Pool）
innodb_buffer_pool_size 是 MySQL 性能优化里唯一必须优先调的缓存参数。它缓存的是数据页和索引页，直接影响磁盘 I/O 频率。只要缓冲池够大、命中率高，90% 的读请求都不用碰磁盘。
- 合理大小：专用数据库服务器建议设为物理内存的 60%–75%（例如 32GB 内存 → 设为 24GB），但绝不能超过实际可用内存，否则触发 swap 会雪崩
- 避免单点争用：当缓冲池 > 1GB 时，务必设置
innodb_buffer_pool_instances≥ 4（常见设为 8），否则所有线程抢同一把锁 - 验证效果：
SHOW ENGINE INNODB STATUSG，找到 “BUFFER POOL AND MEMORY” 部分，看Buffer pool hit rate—— 持续低于 95% 就要扩容或查是否有全表扫描拖累
表级缓存与结构缓存：小但关键的“润滑剂”
当应用打开大量表（比如微服务各模块连不同库、或使用分库分表中间件），table_open_cache 和 table_definition_cache 不足会导致频繁重载.frm/.sdi 文件，表现为 Opened_tables 持续上升、响应变慢。
- 判断是否不足：
SHOW STATUS LIKE 'Open%tables';，若Opened_tables增速远高于Open_tables（比如每秒增几十），说明缓存不够 - 安全上调：默认 2000，生产环境可设为 4000–8000；
table_definition_cache建议同步调至相近值（如 5000），避免反复解析表结构 - 注意副作用：这两个值过高会占用更多文件描述符，需同步检查系统级限制：
ulimit -n，必要时调整 OS 层面的fs.file-max
别忘了应用层才是缓存主战场
MySQL 内置缓存能力有限，且无法跨实例共享。高频、低更新频次的数据（如城市列表、配置项、用户基础资料），应由 redis/memcached 承担。MySQL 只做最终一致性后端。
- 避免缓存穿透：对空结果也设短过期（如 60s），防止恶意查不存在 ID 打垮 DB
- 防缓存雪崩：给同类 key 的过期时间加随机扰动（±30s），别让大量 key 同时失效
- 更新策略选型：写 DB 后主动删缓存（Cache Aside），比双写更可靠；若强一致性要求极高，再考虑带版本号的延迟双删
最常被忽略的一点：InnoDB 缓冲池重启即空，热点数据要等访问慢慢“预热”。开启 innodb_buffer_pool_dump_at_shutdown 和 innodb_buffer_pool_load_at_startup 能让重启后 5–10 分钟内恢复 80%+ 命中率——这个开关，很多团队至今没开。