MySQL 8.4 默认禁用 mysql_native_password 插件且 innodb_change_buffering=none、sql_mode 不完全兼容、innodb_buffer_pool_instances 动态推导，需显式配置并重启生效。
mysql_native_password 认证插件必须显式启用
MySQL 8.4 默认禁用 mysql_native_password 插件，旧客户端（如某些 PHP PDO、Navicat 旧版、Python MySQLdb）直连会报错 Plugin caching_sha2_password could not be loaded 或连接被拒绝。
这不是密码错误，是服务端根本没加载该插件。必须在启动前配置，运行中无法补救：
- 在
my.cnf的[mysqld]段落添加：default_authentication_plugin=mysql_native_password - 同时需启用插件本身：
mysql_native_password=ON（注意不是mysql_native_password_plugin=ON） - 若用命令行启动，加参数：
--default-authentication-plugin=mysql_native_password --mysql-native-password=ON - 配置后务必重启 mysqld，仅 reload 不生效
innodb_change_buffering=none 影响写密集型业务性能
MySQL 8.4 将 innodb_change_buffering 默认值从 all 改为 none，意味着插入、删除标记等变更不再缓存在 buffer pool 中，而是直接刷盘或走更重的路径。
对高并发小事务写入（如日志表、消息队列表）可能造成明显吞吐下降和 IOPS 上升：
- 若确认业务依赖 change buffer 提升写性能（尤其 SSD 延迟敏感场景），应回设为
all或至少inserts - 设置方式：配置文件中写
innodb_change_buffering=all，不要用 SQL 动态 SET，它只影响会话级，不改变持久化行为 - 注意与
innodb_adaptive_hash_index=OFF（8.4 默认）叠加时，二级索引查询+写入双重开销可能放大
sql_mode=MYSQL57 不等于“完全兼容”
执行 SET GLOBAL sql_mode = 'MYSQL57' 看似能一键降级兼容性，但实际只覆盖部分 SQL 行为，底层不兼容项依然存在：
-
utf8mb4_0900_ai_ci排序规则仍为默认，旧 dump 导入可能报Unknown collation；需在建库时显式指定COLLATE=utf8mb4_unicode_ci - 系统表结构、数据字典视图（如
INFORMATION_SCHEMA字段）已按 8.4 格式固化，无法回退 -
NO_AUTO_CREATE_USER等已被移除的 mode 值，即使写进配置也会导致启动失败，必须彻底删除 - 真正稳妥的兼容路径是：配置文件中设
sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION，再配合应用层适配
innodb_buffer_pool_instances 自动计算易被忽略
MySQL 8.4 对 innodb_buffer_pool_instances 改为动态推导，默认不再固定为 8，但推导逻辑依赖两个前提：
-
innodb_buffer_pool_size必须明确配置，不能靠默认值（8.4 默认 128MB，太小会导致 instance=1，丧失并发分片收益） - 若机器 CPU 核数少（如容器内只分配 2 核），
innodb_buffer_pool_instances可能算出 1，但实际你希望设为 2 来平衡锁竞争——此时必须手动覆盖 - 验证是否生效：启动后查
SHOW VARIABLES LIKE 'innodb_buffer_pool_instances';，别只信配置文件写了就完事
8.4 的默认值变化不是“更智能”，而是把决策权交还给部署环境；没细看文档直接升级，最容易在这里掉进隐性性能坑。
