mysql 8.4默认禁用mysql_native_password插件、innodb_change_buffering设为none、innodb_io_capacity升至10000、innodb_flush_method改为o_direct，均针对nvme ssd优化，但需按实际硬件调优以避免性能问题。
mysql_native_password 插件默认禁用，连接直接失败
MySQL 8.4 启动后，默认不加载 mysql_native_password 插件。任何仍使用该认证方式的客户端（老 Java 应用、未更新的 Python 脚本、Ansible 模块、甚至部分运维工具）会立刻报错：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'; - 配套注意：若改用
caching_sha2_password，JDBC 连接串必须带useSSL=true和serverTimezone=UTC（或其他明确时区），否则握手失败
innodb_change_buffering 默认值从 all → none，写入性能表现反直觉
这个参数控制 InnoDB 是否对非唯一二级索引的插入、更新、删除做变更缓冲。8.0 默认 all（全开），8.4 默认 none（全关）。
表面看是“降级”，实则是针对 SSD/NVMe 的优化：现代存储随机写能力极强，开启变更缓冲反而增加内存管理开销和后续合并压力，关闭后写入延迟更稳定、尾部延迟更低。
- 如果你的业务大量写入且依赖机械硬盘（极少见），可手动设回
all，但需压测验证 - 绝大多数 SSD 环境下，保持
none更优，尤其高并发小事务场景 - 注意：该变更不影响唯一索引或主键操作，只影响非唯一二级索引的 DML
innodb_io_capacity 默认值从 200 → 10000，不调参就可能打满磁盘
这个参数告诉 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 倍，避免突发负载下 I/O 调度失衡 - 不要依赖默认值——这是 8.4 升级后最常被忽略的性能坑
innodb_flush_method 默认从 fsync → O_DIRECT，文件系统层行为突变
Linux 下，8.0 默认用 fsync（内核页缓存 + 文件系统日志），8.4 默认尝试 O_DIRECT（绕过内核缓存，直接与磁盘交互）。
好处是减少双缓冲、降低延迟；坏处是：若文件系统不支持或配置不当（如 XFS 未启用 allocsize=64k），会导致大量 write() system call failed 错误，甚至 mysqld 启动失败。
- 检查是否生效：启动后执行
SELECT @@innodb_flush_method;，返回O_DIRECT才算成功 - 若失败，回退到
fsync是安全选择，但需同步确认innodb_doublewrite为 ON（8.4 默认已启用） - ext4 用户注意：确保挂载选项含
barrier=1，否则O_DIRECT可能引发数据损坏风险
