mysql 8.0起已彻底移除查询缓存，query_cache_type等参数无效；应聚焦innodb缓冲池优化、应用层缓存及sql性能调优。
MySQL 8.0 之后查询缓存已移除，别再调 query_cache_type
MySQL 8.0.0 起，官方彻底删除了查询缓存（Query Cache）模块，query_cache_type、query_cache_size 等所有相关变量均已废弃。如果你在 8.0+ 版本里还试图通过配置这些参数提升“查询缓存命中率”，结果只会是：配置无效 + 启动警告 + 白忙一场。
真正需要优化的，是 InnoDB 层的缓冲池（innodb_buffer_pool_size）和操作系统页缓存，它们才是现代 MySQL 实际起效的“缓存”主力。
为什么老版本（5.7 及之前）查询缓存命中率普遍很低
即使你用的是 MySQL 5.7，原生查询缓存也极难高效工作，根本原因在于它的缓存粒度太粗、失效太敏感：
-
SELECT * FROM users WHERE id = 123和SELECT id, name FROM users WHERE id = 123被视为两条完全不同的查询，各自缓存，无法复用 - 只要
users表发生任意 INSERT/UPDATE/DELETE，整个表相关的所有缓存条目立刻失效 - 查询中含函数（如
NOW()、RAND()）、用户变量（@var）、临时表、SQL_NO_CACHE等，直接绕过缓存 - 缓存键包含 SQL 字符串全量比对（区分空格、大小写、注释），应用层 ORM 自动生成的 SQL 很难稳定命中
替代方案：把“缓存命中率”目标转向 InnoDB 缓冲池
InnoDB 缓冲池（Buffer Pool）缓存的是数据页和索引页，不是 SQL 结果集，但实际效果更稳定、更可控。提高它的“有效命中率”，关键在三点：
- 确保
innodb_buffer_pool_size设置合理：通常设为物理内存的 50%–75%，但需预留足够内存给 OS 和其他进程；过小导致频繁刷脏页，过大引发 swap - 让热数据常驻内存：用
innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup实现重启后快速预热 - 避免全表扫描污染缓冲池：加索引、限制
LIMIT、拆分大查询；可通过SHOW ENGINE INNODB STATUS中的Buffer pool hit rate观察（理想值 > 990/1000）
应用层该怎么做才真正减少数据库压力
与其纠结“缓存命中率”，不如在应用侧做确定性更强的减负：
- 对不变或低频变更的数据（如省市区字典、配置项），用 Redis 或本地缓存（Caffeine）兜底，设置明确 TTL
- 合并查询：避免 N+1 查询，用
IN或 JOIN 一次性拉取，减少 round-trip 次数 - 读写分离时，确保从库延迟低且只读查询路由准确；否则缓存再好，读到旧数据也没意义
- 监控慢查询日志（
slow_query_log），优先优化type=ALL或Extra=Using filesort的语句——它们才是拖垮整体响应的元凶
缓存永远是手段，不是目的；真正影响性能的，往往是索引缺失、锁竞争、连接泄漏这些更底层的问题。盯着“命中率”数字本身，容易忽略真实瓶颈所在。
