如何安全地将MySQL 5.6官方双一配置升级到5.7并执行二进制升级？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1055个文字，预计阅读时间需要5分钟。
将伪原创内容简化如下：
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 模式。
必须检查并显式设置的项：
-
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 字段行为。升级不是换二进制就完事，是把配置、系统表、应用连接器三者对齐的过程。
本文共计1055个文字，预计阅读时间需要5分钟。
将伪原创内容简化如下：
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 模式。
必须检查并显式设置的项：
-
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 字段行为。升级不是换二进制就完事，是把配置、系统表、应用连接器三者对齐的过程。