MySQL跨版本升级后残留的系统表和文件需手动清理，因mysql_upgrade仅检查并升级表结构，不删除废弃表、备份目录、旧日志等；须按步骤识别、验证后安全清理。
MySQL跨版本升级后残留的系统表和文件，不会自动清理，必须手动干预；否则可能引发权限异常、元数据不一致、甚至新功能不可用。
为什么 mysql_upgrade 不等于“彻底清理”
很多人以为执行完 mysql_upgrade 就万事大吉，其实它只做两件事：检查系统表结构是否匹配当前版本、必要时执行 ALTER TABLE 升级。它完全不删除旧版本遗留的废弃表、临时文件或已弃用的配置项。
-
mysql_upgrade不会删掉mysql.proxies_priv（MySQL 8.0+ 已废弃，由role_edges和default_roles替代） - 不会清理
/var/lib/mysql/mysql_old/这类手动备份目录（常见于升级前人为创建） - 不会移除
INFORMATION_SCHEMA中已失效的虚拟表引用（如旧版INNODB_SYS_TABLESTATS在 8.0.30+ 后被拆分） - 不会处理
performance_schema中因参数关闭而残留的未注册表（例如禁用table_io_waits_summary_by_table后，其内存结构仍占位）
识别真正无用的系统表与目录
先确认哪些是可安全清理的“历史遗迹”，而不是当前运行所依赖的元数据：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 检查
mysql库中明显废弃的表：SELECT table_name FROM information_schema.tables WHERE table_schema = 'mysql' AND table_name IN ('proc', 'event', 'func', 'help_topic', 'time_zone_name')—— 其中proc和func在 MySQL 8.0+ 已被移除，若存在说明是迁移残留 - 查看
datadir下是否存在带_old、_backup、.bak或版本号后缀的子目录（如mysql_57/、ibdata1.bak） - 运行
ls -la /var/lib/mysql/（Linux）或dir C:\ProgramData\MySQL\MySQL Server*\（Windows），重点找ib_logfile*以外的*.log、*.pid、*.sock文件 —— 它们属于旧实例，新服务启动后不再使用 - 检查
SHOW VARIABLES LIKE 'log_error';返回的错误日志路径，对比其修改时间是否早于升级时间；若是，该日志文件可归档后删除
安全清理操作清单（按顺序执行）
以下步骤必须在确认新实例稳定运行 ≥48 小时、且所有业务连接已切换至新版本后进行：
- 停止旧 MySQL 服务（如果仍在后台运行）：
sudo systemctl stop mysql@5.7（systemd 多实例命名）或sc delete MySQL57（Windows） - 删除废弃系统表（仅限明确已弃用的）：
DROP TABLE IF EXISTS mysql.proc, mysql.func;（MySQL 8.0+） - 清空旧日志与临时文件：
sudo find /var/lib/mysql -maxdepth 1 \( -name "*.log" -o -name "*.pid" -o -name "*.sock" \) -not -newermt "2026-10-10" -delete（将日期替换为升级完成时间） - 递归删除已确认无用的备份目录：
sudo rm -rf /var/lib/mysql/mysql_57_backup/（务必核对路径，ls -ld确认属主和权限） - 清理
performance_schema缓存（非持久化，重启即刷新）：FLUSH STATUS;+FLUSH PERFORMANCE_SCHEMA;
容易被忽略的关键点
最常出问题的地方不在命令本身，而在上下文判断：
-
mysql.user表里可能混着旧认证插件的用户（如mysql_native_password用户在 8.4+ 默认禁用），不能直接删，要先ALTER USER ... IDENTIFIED WITH caching_sha2_password - 某些 Docker 镜像或一键脚本会在
/etc/mysql/conf.d/下生成zz-migration.cnf这类临时配置，升级后不删会导致后续mysqld --initialize失败 - Windows 上
C:\ProgramData\MySQL\MySQL Server 5.7\Data\和C:\ProgramData\MySQL\MySQL Server 8.0\Data\可能共存，但后者未必是主数据目录 —— 要以my.ini中datadir指向为准，别盲目删整个文件夹 - 任何涉及
DROP TABLE的操作，务必先在测试库验证，生产环境建议用RENAME TABLE mysql.proc TO mysql.proc_dropped_202610;替代直接删除，留出回滚窗口
