mysql 8.0 中 query_cache_type 已被彻底删除，配置即报错启动失败；须清除所有 query_cache_ 相关项、替换监控与 sql 中缓存逻辑，并转向索引优化、innodb 缓冲池调优及应用层缓存。
query_cache_type 在 MySQL 8.0 中已被彻底删除，不是“失效”，而是启动时直接报错。你看到的“查询缓存失效”，本质是升级后配置残留 + 旧监控/SQL 逻辑未清理导致的误判。
query<em>cache</em>* 配置还在启动就失败
MySQL 8.0.3+ 版本移除了全部查询缓存相关变量，只要配置文件里还存在 query_cache_type、query_cache_size 等行，mysqld 就无法启动，报错类似：
Unknown system variable 'query_cache_type'
- 用
grep -r "query<em>cache</em>" /etc/my.cnf*扫描所有配置位置 - 找到后整行删除，不要注释（某些解析器会误读注释中的关键字）
- 删除后必须
systemctl restart mysqld，reload不生效
SHOW STATUS LIKE 'Qcache_%' 全是 0 不代表出问题
MySQL 5.7 中靠 Qcache_hits 看“缓存命中率”，是历史惯性；到了 8.0，这条命令返回空是正常行为，不是配置没配好，也不是 bug。
-
SHOW VARIABLES LIKE 'query_cache%'结果为空 → 正常 - 应用层若还写
SELECT SQL_CACHE ...，该提示词被完全忽略，应从 SQL 中批量清除 - 监控系统里所有基于
Qcache_的图表和告警，必须下线或替换为真实 I/O 指标，例如：Innodb_buffer_pool_read_requestsInnodb_buffer_pool_reads
Buffer Pool 不是“替代查询缓存”，而是换了一套逻辑
InnoDB 缓冲池缓的是数据页和索引页，不是 SQL 文本和结果集。它起效的前提是：
✅ 有合适索引（避免全表扫描）
✅ 查询能走覆盖索引（减少回表）
✅ 数据访问模式局部性高（热点数据反复读）
-
innodb_buffer_pool_size建议设为物理内存的 70%–80%，但前提是：- 系统没开
performance_schema（小内存机器上它可能吃掉 100MB+） - 没大量连接同时跑大排序/JOIN（每个连接私有缓冲如
sort_buffer_size也会叠加消耗）
- 系统没开
- 动态调大示例（MySQL 5.7+ 支持）：
SET GLOBAL innodb_buffer_pool_size = 4294967296; -- 4GB
- 但注意：
innodb_buffer_pool_size必须是innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的整数倍，否则会被自动向下取整，且可能触发 warning
Buffer Pool 调得再大，如果 SQL 还在扫全表、没建索引、或者连 WHERE 条件都没加，那再多内存也白搭。真正要盯的不是“缓存有没有”，而是 EXPLAIN FORMAT=JSON 里有没有 using_index、rows_examined 是否稳定在百级别以内。
