MySQL 8.4 SQL执行流程逻辑层级与8.0一致，仍为连接器→解析器→优化器→执行器；变化在于查询缓存模块被物理移除、自适应哈希索引默认关闭、并行扫描默认启用、认证插件强制caching_sha2_password。
MySQL 8.4 的 SQL 执行流程在逻辑层级上与 8.0 完全一致，没有新增或删减执行阶段——连接器、解析器、优化器、执行器这些核心环节没变。真正变化的是底层行为、默认策略和关键组件的开关状态，直接影响你看到的执行效果和性能表现。
查询缓存彻底移除，query_cache_type 不再生效
MySQL 8.0 已经默认禁用查询缓存（query_cache_type=OFF），但相关变量仍存在、可设、不报错；到了 8.4，整个查询缓存模块被物理移除：
-
query_cache_type、query_cache_size等变量已从服务器中删除，启动时若配置会触发警告甚至失败 -
SHOW VARIABLES LIKE 'query%'查不到任何结果 - 哪怕你用 mysqld 启动参数硬传
--query-cache-type=1，也会被忽略或报错 MY-013712
这意味着：所有依赖查询缓存“自动加速”的旧应用，在 8.4 上必须改用其他方案（如应用层缓存、物化视图替代、或加索引优化原生查询）。
innodb_adaptive_hash_index 默认关闭，大表 JOIN 性能可能波动
8.0 默认开启自适应哈希索引（innodb_adaptive_hash_index=ON），用于加速等值查询；8.4 将其默认值改为 OFF：
- 对高并发、随机主键写入场景（如 UUID 主键订单表），关闭后反而减少锁争用，写入更稳
- 但对大量
WHERE id = ?或JOIN ... ON t1.id = t2.id的 OLTP 查询，可能观察到单条查询响应时间微升（实测通常 +5%~15%，取决于数据局部性） - 可通过
SET GLOBAL innodb_adaptive_hash_index = ON动态打开，无需重启
注意：该开关只影响 InnoDB 层的哈希加速，不影响 B+ 树索引本身；EXPLAIN 输出里也看不到变化，需用 SHOW ENGINE INNODB STATUS 观察 adaptive hash index 部分的 usage 统计。
并行扫描成为默认能力，EXPLAIN ANALYZE 多了一行关键输出
8.0 的并行查询是实验特性，需显式 SET SESSION parallel_query = ON 且不稳定；8.4 将其固化为默认可用功能：
- 只要满足条件（表足够大、无复杂子查询、非临时表等），优化器会自动选择并行扫描
- 验证方式唯一可靠：执行
EXPLAIN ANALYZE SELECT COUNT(*) FROM big_table，看Extra列是否出现Using parallel scan (4 workers) - 线程数由
parallel_threads_limit控制，默认 4，最大 64；不是越多越好，超核数反而引发调度开销 - 注意：并行扫描不适用于带
FOR UPDATE或涉及二级索引回表过深的语句，此时优化器会自动降级为单线程
这个变化最易被忽略：它不改变 SQL 写法，也不报错，但同一条语句在 8.0 和 8.4 上的执行计划、耗时、IO 分布可能完全不同。
认证插件变更让连接器阶段多一次密钥协商
8.4 默认禁用 mysql_native_password，强制使用 caching_sha2_password（除非显式启用）：
- 客户端首次连接时，若未启用 TLS，服务端会额外发送公钥（
send public key），客户端需用该公钥加密密码再发回 - 旧版 JDBC 驱动（&allowPublicKeyRetrieval=true 的连接串，会卡在握手阶段，报错
Public Key Retrieval is not allowed - 连接器阶段身份验证耗时比 8.0 略长（平均 +0.5~2ms），但安全性提升显著
这不是执行流程“多了一步”，而是同一“连接器”步骤内部的协议细节升级——对 DBA 来说，意味着升级后第一件事就是检查所有连接字符串和驱动版本，否则服务起不来。
真正要盯住的，从来不是“流程有没有变”，而是哪些默认开关翻转了、哪些变量消失了、哪些看似透明的环节悄悄加了安全握手。这些才是上线前必须逐项验证的点。
