MySQL 9.0目前不能用于生产环境，仅适合本地实验或预研；截至2026年8月，它仍是生命周期仅一个季度的创新版，缺乏长期支持、兼容性保障及主流运维工具适配。
MySQL 8.4 LTS 是生产环境唯一稳妥选择，9.x 目前只适合本地实验或预研，不能上生产。
MySQL 9.x 现在到底能不能用？
不能。截至 2026 年 8 月，MySQL 9.0 仍属于 Innovation Release（创新版），生命周期仅一个季度，官方不承诺兼容性、不提供长期安全更新，Percona、MyDumper、pt-tools 等主流运维工具尚未适配。mysql --version 输出的 9.0.1 或 9.0.2 都只是“快照版”，不是稳定基线。你跑通一条 SELECT 不代表事务一致性、复制稳定性、崩溃恢复逻辑都过关——这些只有 LTS 版本才会经过数月真实流量验证。
常见错误现象：GROUP_REPLICATION 启动失败、mysqldump 报 Unknown system variable 'transaction_write_set_extraction'、备份工具解析 binlog 失败。这些问题不是配置错，而是协议层或元数据格式已悄然变更。
- 9.x 默认启用
sha256_password认证，且mysql_native_password插件被彻底移除，老客户端直连会报Plugin caching_sha2_password could not be loaded - DDL 原子性行为有调整，
ALTER TABLE ... RENAME COLUMN在 9.x 中可能触发隐式锁升级，而 8.4 已收敛为确定性语义 - 没有
innodb_redo_log_capacity这类生产级运维参数，日志文件管理仍依赖旧的innodb_log_file_size+innodb_log_files_in_group组合，无法在线扩缩
为什么 MySQL 8.4 LTS 的默认参数变更比新功能更关键？
因为这些变更会在你没察觉时悄悄影响性能和连接行为。比如 innodb_change_buffering 从 all 改为 none，不是“加了个开关”，而是直接关掉了 change buffer 对非唯一二级索引的写缓存能力——对 SSD 环境是利好，但如果你的表有 10+ 个非唯一索引，又在做批量 INSERT ... ON DUPLICATE KEY UPDATE，QPS 可能掉 15%～20%，而 SHOW ENGINE INNODB STATUS 里根本不会报错，只会显示 Buffer pool hit rate 异常升高、innodb_os_log_written 持续走高。
另一个典型是 group_replication_consistency 默认值变为 BEFORE_ON_PRIMARY_FAILOVER：MGR 故障切换时，新主会等所有已提交事务回放完才对外提供服务。好处是读不到跳变数据；坏处是切换耗时从 200ms 升到 800ms，若应用设置了 500ms 超时，就会出现短暂不可用。这个参数不能 SET GLOBAL 动态改，必须写进 my.cnf 并重启。
-
innodb_flush_methodLinux 下默认从fsync改为O_DIRECT，如果磁盘不支持或 RAID 卡缓存策略冲突，可能引发写放大甚至 hang 住 -
innodb_adaptive_hash_index默认关闭，对高频等值查询（如用户 ID 查单）可能增加 B+ 树遍历开销，需结合INFORMATION_SCHEMA.INNODB_METRICS中adaptive_hash_searches和adaptive_hash_searches_btree对比评估 -
temptable_max_ram改为按总内存 3% 动态计算，若机器内存 64GB，临时表内存上限就变成 ~2GB，容易触发磁盘临时表，需检查慢查日志中是否有Using temporary; Using filesort频发
升级路径怎么选？别碰 in-place upgrade
从 8.0 升 8.4，强烈建议用 logical upgrade（即 mysqldump 或 mydumper 导出再导入），而不是 in-place upgrade。原因很实在：8.0 到 8.4 的系统表结构、权限模型、数据字典序列化格式都有微调，in-place 升级失败后 rollback 成本极高，且 Oracle 官方文档明确标注 “not recommended for production”。
实操要点：
- 先在测试环境用
mysql_upgrade --dry-run检查兼容性，它会报告哪些表需要ALTER TABLE ... UPGRADE，但别信它的“没问题”结论——实际要跑一遍全量 DML 流量压测 - 导出时加
--set-gtid-purged=OFF（如果不用 GTID）或--set-gtid-purged=ON（如果用），否则导入后复制可能起不来 - 导入后立刻执行
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;确认 MTS（多线程复制）状态正常，8.4 对 coordinator 线程调度逻辑有优化，旧 dump 可能暴露队列堆积问题
真正麻烦的从来不是“能不能升”，而是“升完哪几个地方会突然变慢、连不上、或行为不一致”。8.4 的价值不在炫技，而在把过去三年散落在 8.1–8.3 里的默认值调优、边界 case 修复、运维参数收敛，打包成一个可信赖的基线——这意味着你得花时间重验每一条业务 SQL 的执行计划、每一个连接池的认证流程、每一处备份恢复链路的完整性。静默变化，才是最该盯紧的地方。
