必须只停SQL_THREAD以保持IO_THREAD持续拉取binlog、避免relay log断层，确保升级期间数据流不中断且后续能可靠追平。
STOP SLAVE SQL_THREAD 是唯一能保复制链路不断、数据不丢的操作起点。直接 STOP SLAVE 会同时停掉 IO_THREAD 和 SQL_THREAD，主库新写入的 binlog 就收不到，relay log 断层后追平困难甚至丢事务。
为什么必须只停 SQL_THREAD 而非整个复制？
主从滚动升级不是“不停机就能升”，而是靠“先升从、再切主、最后升原主”实现业务无感知——前提是版本差不能超一个大版本，且必须停 SQL_THREAD 而非整个复制链路。
-
STOP SLAVE SQL_THREAD后，IO_THREAD继续运行，持续拉取主库 binlog 并写入 relay log，保证数据流不中断 - 升级期间，从库仍可提供只读服务（需确认应用未依赖实时强一致）
- 若误执行
STOP SLAVE，Seconds_Behind_Master会归零但实际已停止接收新事件，后续START SLAVE可能因 relay log 缺失导致GTID_EXECUTED不连续 - 5.7 → 8.0 升级时尤其危险：旧 binlog event 类型在新版本解析失败，
Slave_SQL_Running_State会卡在 “Reading event from the relay log”
升级后必须立即执行 mysqld --upgrade=MINIMAL
MySQL 8.0.16+ 已弃用 mysql_upgrade，但 mysqld --upgrade=MINIMAL 不是可选动作，而是 5.7 → 8.0 升级后必跑步骤——否则系统表结构不匹配，权限校验直接崩溃。
- 典型表现：
SELECT USER()返回空，或报错Access denied for user ''@'localhost' - 必须在
SQL_THREAD停止、从库停写后执行：mysqld --defaults-file=/etc/my.cnf --upgrade=MINIMAL --skip-grant-tables --skip-networking & - 不能在主库还运行时对从库执行交互式
mysql_upgrade -u root -p（8.0.16+ 不支持） - 若已跳过该步且
mysqld启动失败，不要硬重启；改用--skip-grant-tables启动后手动修复mysql.user.authentication_string字段格式
升级后验证不能只看 Seconds_Behind_Master = 0
这个值只表示 relay log 已读完，不保证事件已成功回放。真正要确认的是复制是否真正可用、数据是否一致、隐性行为是否变更。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 检查
SHOW SLAVE STATUS\G中Slave_SQL_Running: Yes且Slave_SQL_Running_State不卡在 “Reading event…” 或 “Waiting for table metadata lock” - 比对主从
SELECT GTID_EXECUTED是否一致；若不一致，说明有事件解析失败或被跳过 - 验证
NOW()和CONVERT_TZ()行为：8.0 默认尝试写入mysql.time_zone表，若未加载时区表，时间函数结果会错乱 - 检查认证插件是否自动切换为
caching_sha2_password，老客户端连接可能失败
跨大版本（如 5.7 → 8.0）必须分两步走
官方明确禁止 5.7 直升 8.0。必须经中间态过渡，否则 mysqld 启动直接拒绝并报错 Data Dictionary upgrade required。
- 第一阶段（5.7 → 5.7.latest）：所有节点先升到 5.7.40+，启用
gtid_mode = ON、binlog_format = ROW、enforce_gtid_consistency = ON，关闭show_compatibility_56 - 第二阶段（5.7.latest → 8.0.33+）：仅允许升到 8.0.33 及以上；启动命令必须含
--upgrade=MINIMAL或--upgrade=FORCE - 配置中残留
sql_mode=NO_AUTO_CREATE_USER或innodb_locks_unsafe_for_binlog，8.0 启动会直接报错退出 - 主库必须最后升级：否则主库创建的新角色/权限语句（如
CREATE ROLE）无法被旧从库解析，复制中断
真正容易被忽略的点是：升级后 mysql.time_zone 表为空、authentication_string 字段格式未更新、以及 GTID_EXECUTED 看似一致但中间有 event 解析静默跳过——这些都不会立刻报错，却会在某次主从切换或故障恢复时突然暴露。
