MySQL 8.4 移除默认加载 mysql_native_password 插件，需显式配置或迁移至 caching_sha2_password；innodb_change_buffering 默认设为 none，优化 SSD 写入稳定性；innodb_io_capacity 默认升至 10000，须按实际磁盘 IOPS 调整；并行查询默认启用，需通过 EXPLAIN ANALYZE 验证执行计划中是否出现 Using parallel scan。
mysql_native_password插件默认禁用，连接直接失败
MySQL 8.4 启动后不再加载 mysql_native_password 插件，老应用、Ansible 模块、未更新的 Python 脚本或 JDBC 连接串若仍依赖该认证方式，会立刻报错：Plugin 'mysql_native_password' is not loaded。这不是配置漏写，而是行为变更——8.0 中它虽被标记废弃但仍可用，8.4 中已彻底移出默认加载列表。
临时兼容方案：在 [mysqld] 段中显式添加 default_authentication_plugin=mysql_native_password 或 mysql_native_password=ON，然后重启 mysqld。
长期方案更推荐：批量执行 ALTER USER 'user'@'host' IDENTIFIED WITH caching_sha2_password BY 'password';，但注意配套调整 JDBC 连接串，必须带 useSSL=true 和明确时区（如 serverTimezone=UTC），否则握手失败。
innodb_change_buffering 默认从 all → none，写入延迟反而更稳
该参数控制 InnoDB 对非唯一二级索引的插入、更新、删除是否做变更缓冲。8.0 默认 all（全开），8.4 默认 none（全关）。表面看是“降级”，实则是针对 NVMe/SSD 的优化：现代存储随机写能力极强，开启缓冲反而增加内存管理开销和后续合并压力，关闭后写入延迟更稳定、尾部延迟更低。
- 如果你的业务大量写入且仍在用机械硬盘（极少见），可手动设回
all，但务必压测验证 - 绝大多数 SSD 环境下，保持
none更优，尤其高并发小事务场景 - 该变更不影响唯一索引或主键操作，只影响非唯一二级索引的 DML
innodb_io_capacity 默认从 200 → 10000，不调参容易打满磁盘
innodb_io_capacity 告诉 InnoDB 存储设备的 IOPS 能力。8.0 默认 200 是面向传统 SATA HDD 的保守值；8.4 直接跳到 10000，反映 NVMe SSD 已成标配。问题在于：如果服务器实际磁盘只有 5000 IOPS（比如入门级 PCIe 3.0 SSD），InnoDB 会按 10000 节奏刷脏页、合并变更缓冲，极易引发 I/O 饱和，表现为 SHOW ENGINE INNODB STATUS 中 pending normal aio reads/writes 持续升高，查询响应变慢。
务必根据真实硬件能力设置：用 fio 或 iostat -x 1 测出稳态随机读写 IOPS，取 70%~80% 作为 innodb_io_capacity 值；innodb_io_capacity_max 建议设为 innodb_io_capacity 的 2 倍。
innodb_parallel_read_threads 和 parallel_query 默认启用，但需验证生效
8.4 默认开启并行查询，核心参数包括：parallel_query（总开关，默认 ON）、parallel_threads_limit（单条查询最大 worker 数，默认 4）、innodb_parallel_read_threads（全局线程池大小，默认为 CPU 逻辑核数 / 8）。
别光改参数就以为生效了——必须用 EXPLAIN ANALYZE 查看执行计划，确认 Extra 字段出现 Using parallel scan (N workers) 才算真正跑起来。没看到这个提示，说明查询未触发并行条件（比如表太小、索引覆盖、或被 optimizer 判定为不划算）。
另外注意：innodb_dedicated_server=ON 时，innodb_redo_log_capacity 的计算逻辑从基于内存改为基于 CPU，且不再自动修改 innodb_flush_method，这点和 8.0 行为不同。
