MySQL容器升级后报错是因版本倒挂：8.0写入的数据目录被5.7读取，导致元数据格式不兼容，标志位（如0x4800）与文件不匹配，权限表丢失；须用同版本容器启动或重导逻辑备份。
容器升级后 MySQL 报 Table 'mysql.user' doesn't exist、Data Dictionary initialization failed 或反复重建 mysql 库——这不是挂载路径错了，而是旧数据目录被高版本（如 8.0）写入后，又被低版本容器（如 5.7 镜像）启动读取，元数据格式直接不兼容。
确认是不是版本混用导致的 flag 不匹配
看到日志里有 Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4800，基本可以锁死是版本倒挂：你用 MySQL 8.0 容器初始化过数据卷，之后却换回了 5.7 镜像启动。5.7 根本不认识 8.0 写入的 ibdata1 标志位，也不认 .sdi 文件，强行读只会报错或静默跳过权限表。
- 查当前容器实际版本：
docker exec -it mysql-container mysqld --version - 进容器看
/var/lib/mysql/下有没有mysql.ibd和mysql/目录——有就说明是 8.0 留下的结构 - 别试
innodb_force_recovery：它对 flag 不匹配完全无效，设到 6 也会崩在log0buf.cc:883
软链接迁移时 SELinux/AppArmor 没放行新路径
用 ln -s /new/path/mysql_data /var/lib/mysql 后服务起不来，常见于容器外挂载宿主机路径（如 -v /host/data:/var/lib/mysql），但容器内进程仍受宿主机安全策略限制。
- Docker 默认不透传 SELinux 上下文，CentOS/RHEL 上需加
:z或:Z标签：-v /host/data:/var/lib/mysql:z - Ubuntu 主机跑 Docker 时，若启用了 AppArmor，得手动更新配置：
/etc/apparmor.d/usr.sbin.mysqld里补一行/host/data/** rwk,，再sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld - 验证是否生效：
docker exec mysql-container ls -lZ /var/lib/mysql，看 context 是否含mysqld_db_t
my.cnf 被多个位置覆盖，datadir 实际没生效
你以为改了 my.cnf 就完事，但容器内 MySQL 启动时按固定顺序找配置文件，优先级高的会覆盖低的。尤其当你挂载了自定义配置，又没删掉镜像内置的默认配置，极易冲突。
- 查最终生效的
datadir：docker exec mysql-container mysqld --verbose --help | grep "datadir" - 常见干扰源：
/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf、甚至/var/lib/mysql/my.cnf（如果挂载点里有） - 安全做法：只保留一个配置文件，挂载时用
-v /host/my.cnf:/etc/my.cnf:ro，并在里面显式写全路径，比如datadir = /var/lib/mysql（即使没变也要写，避免继承默认值） - Windows 宿主机注意路径分隔符：Docker for Windows 接收正斜杠，写成
datadir = C:/mysql/data，别用反斜杠
升级失败后硬删 ibdata1 或 mysql 目录反而更糟
看到启动失败就想删 ibdata1 或整个 mysql/ 目录？这是最危险的操作。8.0 的数据字典根节点就在 ibdata1 里，删了等于废掉所有表定义；而 mysql/ 目录里除了系统表，还存着 component、role_edges 等 8.0 新增对象，删了会导致 ERROR 1878 (HY000)。
- 真正该删的是整个
/var/lib/mysql目录——仅限你不需要复用旧数据（比如测试环境重装） - 必须保留的只有业务库的
.ibd文件（如果用了innodb_file_per_table=ON）和binlog，其余全是可重建的元数据 - 如果数据不能丢，唯一出路是拉起同版本容器（比如原先是 8.0.33 写的，就必须用 8.0.33 镜像启动），再用
mysqldump --no-data mysql > mysql_struct.sql替换结构
最常被忽略的一点：MySQL 8.0 启动时会自动执行数据字典升级，但这个过程依赖 ibdata1 里残留的 LSN 和页头信息。一旦这些被破坏，连自动升级逻辑都触发不了——此时任何“修复”操作都是徒劳，只能回退版本或重导逻辑备份。
