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 STATUS\G，找到 “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%+ 命中率——这个开关，很多团队至今没开。
