必须执行 mysql_upgrade -s，否则系统表仍为5.6结构，导致 mysql.user 缺失 authentication_string 字段、sys 库缺失、权限校验失败；-s 限定仅升级系统库，避免全库重建引发卡顿或失败。
直接说结论：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 模式。
面向 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 字段行为。升级不是换二进制就完事，是把配置、系统表、应用连接器三者对齐的过程。
