mysql 8.0 彻底移除 query cache 模块，非禁用而是代码级删除，故其对复制无任何影响；残留 querycache* 配置会导致 mysqld 启动失败，进而引发主从中断，须彻底清理配置文件。
Query Cache 在 MySQL 8.0 中**根本不存在**，不是“不推荐”，而是**代码级移除**——所以它对复制（replication）**没有任何影响**，因为它压根没机会参与复制流程。
如果你在 MySQL 8.0 环境下看到和复制相关的异常或日志里提到 Query Cache，那基本可以断定：配置文件里还残留了 query_cache_type 或其他 query_cache_* 参数，导致 mysqld 启动失败或被跳过解析，进而引发主从服务无法正常建立连接、IO线程起不来等连锁问题。
真正影响复制的，是那些“本该删掉却还留着”的配置项。
my.cnf 里还有 query_cache_*？MySQL 8.0 直接拒绝启动
MySQL 8.0.3 起，所有 query_cache_* 变量（包括 query_cache_type、query_cache_size、query_cache_limit）已被从源码中彻底删除。配置文件中哪怕只写一行：
query_cache_type = 0
mysqld 就会报错退出，典型错误信息是：
Unknown variable 'query_cache_type'
这个错误常被忽略，尤其在 Docker 或 RDS 自定义参数组中——参数组保存成功不代表生效，实际启动时一读就崩。结果就是：
- 主库起不来 → binlog 不产生 → 从库 IO 线程连不上
- 从库配置文件带该参数 → 启动失败 → 复制链路中断
- Percona Server 8.x / MariaDB 10.6+ 同样不兼容，别指望“向下兼容”
为什么有人觉得 Query Cache “影响复制”？其实是误解来源
这个问题背后的真实场景，往往来自 MySQL 5.7 升级到 8.0 的迁移过程。在 5.7 中，Query Cache 虽已标记为 deprecated，但仍可运行；而它的行为确实会干扰复制一致性：
-
SELECT命中缓存时，不走引擎层，也就不会触发binlog记录（这是正常的），但若缓存失效策略与主从时间差叠加，可能造成从库执行语句时“查不到刚更新的数据”——这不是缓存本身写 binlog，而是应用误判缓存可用性 - 更常见的是：主库开了
query_cache_type = 1，但从库因内存不足或配置差异导致缓存未命中，相同 SQL 在主从执行路径不同，执行计划或结果出现细微偏差（比如浮点计算顺序、临时表引擎选择），最终引发校验失败或数据不一致 - 这些现象在升级后被归因为“Query Cache 影响复制”，实则是旧配置残留 + 新版本不兼容共同导致的启动/配置故障
检查 & 清理：两步确认是否真有 Query Cache 干扰
别猜，直接验证：
- 登录 MySQL 执行：
SHOW VARIABLES LIKE 'query_cache%';—— 在 8.0+ 中应**返回空集**，若有结果，说明你连的不是 8.0，或者客户端连错了实例 - 检查配置文件：
grep -i 'query_cache_' /etc/my.cnf /etc/mysql/my.cnf 2>/dev/null—— 任何匹配行都必须删掉，不是注释，是删除 - 检查 Docker 启动命令或 RDS 参数组，确认没有通过
--defaults-file或自定义参数注入残留项
做完这些，重启 mysqld。如果复制仍异常，问题一定出在别处：比如 GTID 模式不一致、binlog_format 设置错误、网络延迟导致心跳超时，而不是什么“Query Cache 干扰复制”——它早就不在那儿了。
最容易被忽略的，是把“升级前的配置原封不动拷贝进新环境”。那个看似无害的 query_cache_type = 0，在 8.0 里不是开关，是语法炸弹。
