MySQL 8.4 LTS不是功能大爆发版本，而是将8.1–8.3中验证成熟的架构调整和默认行为优化打包为长期支持基线，升级关键在于关注默认值变更与行为收敛点，如innodb_change_buffering默认改为none、group_replication_consistency默认为BEFORE_ON_PRIMARY_FAILOVER、innodb_redo_log_capacity替代旧日志参数、mysql_native_password默认禁用等，这些静默变化最易引发性能回退或连接失败。
直接说结论：MySQL 8.4 LTS 不是“功能大爆发”版本，而是把过去几年创新版（8.1–8.3）中验证成熟、生产可用的架构调整和默认行为优化，打包进一个长期支持基线。查阅官方手册时，重点不是找“全新功能”，而是盯紧 默认值变更 和 行为收敛点 —— 这些才是升级后最可能出问题的地方。
innodb_change_buffering 默认从 all 改为 none
这个改动影响非常实际：8.4 启动后，InnoDB 默认不再缓存非唯一二级索引的插入/删除标记操作。以前 innodb_change_buffering=all 会把这类写操作先攒在缓冲区，等页面读入内存再合并，降低随机 I/O；现在设为 none，所有变更都立即落盘或走正常路径。
适用场景：
- SSD/NVMe 环境下，随机写性能足够强，change buffer 的收益变小，反而可能因争用缓冲池引发锁等待
- OLTP 主键写密集、二级索引更新少的业务，基本无感
- 但如果你的表有大量非唯一二级索引 + 高频批量 INSERT/DELETE，QPS 可能小幅下降，延迟毛刺变多
容易踩的坑：
- 沿用旧 my.cnf 未显式配置该参数，结果发现批量导入变慢，排查半天才意识到是默认值变了
- 误以为是硬件或配置问题，反复调 innodb_io_capacity，其实根源在 change buffer 被关了
group_replication_consistency 默认为 BEFORE_ON_PRIMARY_FAILOVER
组复制（MGR）的事务一致性保障前移了。8.0 默认 EVENTUAL，主切后新主可能还没回放完全部 binlog 就开始提供读服务；8.4 默认强制新主在接管前完成所有已提交事务的回放。
这意味着：
- 故障切换时间略长（通常多几百毫秒），但应用读不到“跳变”数据
- 如果你的应用依赖“最终一致性”做宽松读取（比如报表类查询跑在只读节点），切换后可能短暂卡住或超时
- BEFORE_ON_PRIMARY_FAILOVER 不影响正常主从复制，只作用于 MGR 内部故障转移流程
关键提醒：
- 该参数不能动态 SET，必须在 my.cnf 中配置并重启生效
- 若需兼容旧行为，可手动设回 EVENTUAL，但需承担一致性风险
innodb_redo_log_capacity 替代 innodb_log_file_size + innodb_log_files_in_group
Redo Log 管理方式重构了。8.4 废弃了老式双参数组合，统一用单参数 innodb_redo_log_capacity 控制总容量（单位字节）。例如原配置 innodb_log_file_size=1G × 2 = 2G，现在直接设 innodb_redo_log_capacity=2147483648。
为什么这样改：
- 避免用户误配导致日志文件数不匹配、启动失败（如只改 _file_size 忘改 _files_in_group）
- 官方可更灵活控制内部日志段分配策略，尤其适配高吞吐写入场景
实操注意：
- 升级前必须停库，用 mysqld --initialize-insecure 或手动清理旧日志文件（ib_logfile0, ib_logfile1）
- 首次启动时若检测到旧日志文件存在，会报错退出，提示 “Redo log files exist but redo log capacity is not set”
- 建议在初始化配置中显式写明 innodb_redo_log_capacity，不要依赖自动计算
mysql_native_password 插件默认禁用
连接层最常踩的坑。8.4 默认认证插件是 caching_sha2_password，而 mysql_native_password 被彻底禁用——不是废弃，是默认关掉。
现象很典型：
- 旧 JDBC 驱动（如 Connector/J 5.1.x）、PHP mysqli 扩展、某些 Python MySQL 客户端连不上，报错 Authentication plugin 'caching_sha2_password' cannot be loaded 或类似提示
- CREATE USER ... IDENTIFIED WITH mysql_native_password 会失败，除非先启用插件
解决办法只有两个：
- 在 my.cnf 的 [mysqld] 段加 mysql_native_password=ON，然后重启
- 或升级客户端驱动，使用 8.0+ 版本的 Connector/J，并确保连接字符串含 &serverTimezone=UTC 等兼容项
别忽略这点：很多自动化部署脚本硬编码了 mysql_native_password 创建用户，升级后全挂，得逐个改。
真正麻烦的从来不是“加了什么新功能”，而是这些默认值和行为的静默切换——它们不会报错，但会让系统在某个凌晨三点突然慢下来，或者让某条 SQL 的执行计划彻底偏移。升级前务必在测试环境用真实流量压测，尤其盯住 SHOW ENGINE INNODB STATUS 里的 change buffer 使用率、redo log 刷写延迟、以及 MGR 切换日志里的 consistency wait 时间。
