mysql 8.0 已彻底移除查询缓存，性能优化应聚焦 innodb buffer pool 命中率（innodb_buffer_pool_reads/innodb_buffer_pool_read_requests），而非过时的 qcache 指标。
MySQL 查询缓存（Query Cache）已弃用，别再依赖它做性能优化
MySQL 8.0 已彻底移除 query_cache_type 和相关参数，5.7 是最后一个支持它的稳定版本。如果你还在查 Qcache_hits、Qcache_inserts 这类状态变量，说明你可能正踩在一个过时的优化思路上——缓存命中率 ≠ 实际性能收益，尤其在写多读少或表频繁变更的场景下，查询缓存反而会成为锁争用瓶颈。
真正影响 SQL 执行性能的缓存层是 InnoDB Buffer Pool
现代 MySQL 性能分析应聚焦 innodb_buffer_pool_reads（物理磁盘读）与 innodb_buffer_pool_read_requests（逻辑读请求）的比值，这才是衡量「热数据缓存效果」的关键指标：
SELECT
ROUND((1 - (ibp_reads / ibp_read_requests)) * 100, 2) AS buffer_pool_hit_rate
FROM (
SELECT
VARIABLE_VALUE AS ibp_reads
FROM performance_schema.global_status
WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads'
) r
CROSS JOIN (
SELECT
VARIABLE_VALUE AS ibp_read_requests
FROM performance_schema.global_status
WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests'
) req;
-
Innodb_buffer_pool_reads > 0表示有磁盘 I/O，需关注是否 buffer pool 太小或查询未走索引 - 命中率长期低于 95% 通常意味着 buffer pool 不足，或存在大量全表扫描
- 该指标只反映页级缓存效果，不等同于“SQL 结果被缓存”，和旧版 Query Cache 完全无关
如何判断某条 SQL 是否真的从 Buffer Pool 中受益
单条语句无法直接看到“本次执行是否命中 Buffer Pool”，但可通过 EXPLAIN FORMAT=JSON + 执行前后状态差定位真实开销：
