mysql 5.6如何安全升级到5.7_官方双一配置检查与二进制升级-mysql教程-PHP中文网

必须执行 mysql_upgrade -s，否则系统表仍为5.6结构，导致 mysql.user 缺失 authentication_string 字段、sys 库缺失、权限校验失败；-s 限定仅升级系统库，避免全库重建引发卡顿或失败。

mysql 5.6如何安全升级到5.7_官方双一配置检查与二进制升级

直接说结论：MySQL 5.6 升级到 5.7 必须做 mysql_upgrade -s，否则系统表结构不兼容，SELECT VERSION() 显示 5.7，但 mysql.user 仍用旧字段、sys 库缺失、权限逻辑错乱——这不是“看起来升级了”，而是埋雷。

mysql_upgrade -s 是什么，为什么必须加 -s

mysql_upgrade 不是“自动修复一切”的黑盒命令。它默认会扫描所有库的所有表，尝试按 5.7 规则重建（尤其对 MyISAM 表会创建临时表），耗时极长且可能失败。而加 -s（即 --upgrade-system-tables）表示只操作 mysql、information_schema、performance_schema 和新增的 sys 这四个关键系统库，跳过业务库表——这才是生产环境该用的方式。

常见错误现象：

没加 -s，执行卡在 Checking table 'mysql.columns_priv' 几小时不动
升级后应用连不上，报 Access denied for user 'xxx'@'%' (using password: YES)，实际是因为 mysql.user.authentication_string 字段没被初始化
SHOW DATABASES 看不到 sys，SELECT * FROM sys.schema_table_statistics 报错

实操建议：

启动 5.7 实例后，先确认能连上：mysql -uroot -p --socket=/var/lib/mysql/mysql.sock
立即执行：mysql_upgrade -u root -p -s（别加 --force，除非明确提示“system tables are corrupted”）
执行完必须重启 mysqld：systemctl restart mysqld，否则新字段和视图不会生效

二进制升级时 /etc/my.cnf 的关键兼容项

5.7 引入大量默认行为变更，直接沿用 5.6 的配置文件大概率导致启动失败或权限异常。最常踩的坑集中在认证插件和 SQL 模式。

必须检查并显式设置的项：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

default_authentication_plugin= mysql_native_password：5.7.21+ 默认改用 caching_sha2_password，JBoss/WildFly、旧版 Connector/J 8.0 以下不支持，连都连不上
sql_mode 建议显式设为兼容值，例如：sql_mode=STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION；否则 5.6 能插入的空日期，在 5.7 可能直接报错
如果原库有自定义函数或存储过程，导入前需临时加：log_bin_trust_function_creators=1，导入成功后立刻注释掉并重启
禁用 skip-grant-tables 后再重启：该参数仅用于首次重置 root 密码，长期开启等于裸奔

官方“双一”配置检查（innodb_flush_log_at_trx_commit & sync_binlog）

这俩参数决定数据持久化级别，5.6 和 5.7 对它们的默认值没变（都是 1），但 5.7 的 InnoDB 日志刷盘逻辑更严格。若线上曾为性能调成 innodb_flush_log_at_trx_commit=2 或 sync_binlog=0，升级后必须重新验证 RPO（恢复点目标）是否可接受。

影响判断：

innodb_flush_log_at_trx_commit=1 + sync_binlog=1：最安全，崩溃最多丢 1 个事务，但写性能最低
innodb_flush_log_at_trx_commit=2：日志只写 OS cache，OS 崩溃可能丢秒级数据；5.7 下该模式下 binlog 和 redo log 的顺序一致性风险比 5.6 更高
升级后务必在 error log 中搜 InnoDB: Doing recovery，若频繁出现，说明刷盘策略与 crash recovery 机制不匹配

实操建议：

升级前用 SELECT @@innodb_flush_log_at_trx_commit, @@sync_binlog; 记录当前值
升级后对比 mysqld --verbose --help | grep "Default options" 输出，确认未被 5.7 新逻辑覆盖
压测时重点看 SHOW ENGINE INNODB STATUS\G 中的 Log sequence number 和 Last checkpoint at 差值，过大说明刷盘滞后

真正容易被忽略的点：5.7 的 mysql_upgrade 不会动你的 my.cnf，也不会告诉你哪些配置已废弃。比如 query_cache_type 在 5.7 仍可用，但 8.0 直接移除；又比如 explicit_defaults_for_timestamp 默认为 ON，会影响已有表的 TIMESTAMP 字段行为。升级不是换二进制就完事，是把配置、系统表、应用连接器三者对齐的过程。