MySQL 8.0 LTS小版本升级（如8.0.33→8.0.45）必须停服务、替换二进制、重启mysqld，因mysqld启动时自动触发数据字典升级且仅首次生效；强行覆盖运行中二进制会导致崩溃或不一致，手动mysql_upgrade已废弃。
MySQL 8.0 LTS 版本间（如 8.0.33 → 8.0.45）的小版本升级，**可以原地进行，但“无缝”不等于“无感”——必须停服务、替换二进制、重启 mysqld，且不能跳过自动升级检查**。8.0.16+ 已将 mysql_upgrade 功能内建到 mysqld 启动流程中，手动调用该命令已废弃，强行运行会报错 mysql_upgrade is deprecated。
为什么必须停服务再替换二进制文件
直接覆盖正在运行的 mysqld 二进制会导致进程崩溃或数据字典不一致；Linux 系统下，已加载的可执行文件被替换后，旧进程仍引用旧代码段，新进程才加载新版，无法保证系统表升级逻辑生效。此外，mysqld 启动时若检测到数据字典版本低于当前二进制要求，会自动触发升级流程——这个动作只在首次启动新二进制时发生，且依赖干净的 shutdown 状态。
关键点：
- 必须先执行
systemctl stop mysqld（或对应服务名），确认ps aux | grep mysqld无残留进程 - 避免用
kill -9强杀：可能导致ib_logfile或 redo 日志状态异常，启动时报InnoDB: Database page corruption - 若使用
mysqld_safe启动，需同时停止其父进程，否则mysqld可能被自动拉起并继续用旧二进制
替换二进制后启动时的关键参数与日志观察
新版 mysqld 启动时会自动校验并升级数据字典（mysql 系统库表结构）、权限表和时区表。这个过程不可跳过，也不可后台静默——它会阻塞启动，直到完成或失败。
务必在启动后立即检查错误日志（路径由 log_error 配置项决定，常见为 /var/log/mysql/error.log 或 $datadir/hostname.err）：
- 成功标志：日志中出现
Upgrading system tables→Starting upgrade process for server version→ 最终mysqld: ready for connections - 失败信号：含
Failed to upgrade server、Table 'mysql.func' doesn't exist（说明 5.7 兼容表未清理）或大量ERROR 1872（GTID 相关冲突） - 若卡在
Upgrade completed后无后续，检查磁盘空间是否耗尽（升级过程需临时写入mysql.ibd和 undo log）
配置文件与插件兼容性容易被忽略的坑
小版本升级虽不改大框架，但部分配置项可能被弃用或行为微调，尤其影响连接和认证：
-
default_authentication_plugin在 8.0.45 中仍默认为caching_sha2_password，但若应用客户端（如老版 MySQL Connector/J 5.1）不支持，连接会直接拒绝，需临时加--default-auth=mysql_native_password或在[client]段配default-auth = mysql_native_password -
sql_mode默认值可能变化（如新增STRICT_TRANS_TABLES），导致原有 INSERT 因截断警告失败，需比对新旧版本SELECT @@sql_mode输出 - 若启用了自定义插件（如
audit_log、keyring_file），确认新版 RPM/DEB 包已包含对应 SO 文件，否则启动时报Plugin 'xxx' is not loaded -
!includedir /etc/my.cnf.d在某些包管理器升级中会被重置，检查升级后/etc/my.cnf是否仍包含该行，否则自定义配置丢失
升级后必须验证的三件事
看到 mysqld 进程起来、SELECT VERSION() 返回新版本号，不等于升级完成。真正落地要盯住：
- 用户权限是否可继承：执行
SELECT user, host, plugin FROM mysql.user WHERE user='root'，确认plugin字段不是空或auth_socket（说明认证插件未正确加载） - 存储过程/函数能否调用：运行一个含
CREATE FUNCTION的简单例程，避免因log_bin_trust_function_creators默认关闭而报错ERROR 1418 - 慢查询日志是否写入：检查
slow_query_log_file路径是否存在、权限是否可写，且新 SQL 出现在其中——很多升级后slow_query_log=ON但文件路径失效，日志静默丢弃
最易被跳过的环节是：没验证备份恢复链路是否适配新版本。8.0.45 导出的 mysqldump 文件，用 8.0.33 的客户端导入会报 Unknown collation: 'utf8mb4_0900_as_cs'，反过来也一样。升级后应同步更新所有备份还原脚本中的客户端版本。
