看到这行报错日志，问题定位一下就清晰多了。关键错误信息非常明确，直接指向了 MySQL 启动失败的根源：

[ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4800!

这段报错直接点出了核心矛盾：MySQL 的数据字典（内存中的逻辑结构）认为表是普通模式，但物理文件 ibdata1（磁盘上的实际文件）里却标记着特殊的标志位（0x4800）。

通俗来说，这通常意味着文件格式不兼容，或者数据文件残留了旧版本或旧配置的痕迹，导致 InnoDB 引擎无法正确解析系统表空间。

结合你之前使用 Docker 部署的方式，极大概率是因为你复用了旧的 mysql-data 数据卷，而这个卷里残留了之前初始化失败的垃圾文件，或者之前是用 MySQL 8+ 初始化的，现在用 5.7 读取，自然就格式错乱了。

根本原因分析

1. 数据残留污染：之前尝试过多次启动，每次都会在 ibdata1（系统表空间文件）里写入一些初始化信息。强制停止容器后，这些文件没有被清理，留下了“半成品”状态的文件。
2. 版本或配置冲突：0x4800 这个标志位通常与 InnoDB 的特定功能（如加密、共享表空间属性）有关。如果之前的初始化流程没有走完（比如卡在一半），文件状态就会处于一个尴尬的中间态——既不是完全的旧版，也不是完整的新版。

终极解决方案（二选一）

既然这是一个刚搭建的环境（或者你不在乎里面损坏的数据），最干净、最快的解决办法就是彻底清除旧数据，让 MySQL 重新生成一套全新的文件，彻底解决 Table flags 冲突。

方案 A：彻底重置（推荐，99% 能解决）

这是解决此类“文件标志位冲突”最有效的手段。删除旧的 Docker 数据卷，让 MySQL 从零开始初始化，确保所有 InnoDB 文件重新生成。

删除旧的容器（如果还存在）：

docker rm -f mysql-server-fix

关键步骤：删除旧的数据卷。

这一步会清除所有旧的、损坏的 ibdata1、ib_logfile* 等文件，避免残留数据干扰新实例。

docker volume rm mysql-data

注意：如果你之前创建卷时指定了绝对路径（比如 -v /opt/mysql:/var/lib/mysql），那需要执行 rm -rf /opt/mysql/* 来清空目录。

重新创建配置文件（确保里面只有基础配置，不要有乱码或冲突选项）：

cat > /root/mysql-conf/my.cnf << 'EOF'
[mysqld]
# 移除之前的 force_recovery 尝试，先正常启动
# skip-grant-tables 也暂时移除，除非你还想跳过密码
EOF

重新运行容器：

docker run -d \
  --name=mysql-server \
  --restart=always \
  -p 3306:3306 \
  -v mysql-data:/var/lib/mysql \
  -v /root/mysql-conf/my.cnf:/etc/mysql/conf.d/my.cnf \
  -e MYSQL_ROOT_PASSWORD=123456 \
  -e TZ=Asia/Shanghai \
  mysql:5.7

方案 B：如果必须抢救旧数据（危险，仅限有重要数据）

如果这个 mysql-data 里有非常重要的业务数据不能丢，且方案 A 不适用，那就必须使用“强制恢复模式”来导出数据，但请注意此操作风险极高。

修改配置文件，将恢复级别调高到 6（最强制模式）：

cat > /root/mysql-conf/my.cnf << 'EOF'
[mysqld]
# 危险级别：6，可能会导致数据页过期，但能强行启动
innodb_force_recovery = 6
# 必须加上这个，否则可能因为权限问题连不上
skip-grant-tables
skip-networking
EOF

重新启动容器（注意名字要唯一，或者先删掉旧的）：

docker run -d \
  --name=mysql-server-rescue \
  -v /root/mysql-conf/my.cnf:/etc/mysql/conf.d/my.cnf \
  -v mysql-data:/var/lib/mysql \
  mysql:5.7

查看日志：

如果看到 mysqld: ready for connections，立刻执行导出：

docker exec mysql-server-rescue mysqldump -u root --all-databases > /root/emergency_backup.sql

注意：此时数据库是只读的，无法执行 UPDATE 或 INSERT。导出后，依然需要使用方案 A（清空数据卷）来重建数据库，然后把导出的 SQL 导入进去。

总结

对于当前的 Table flags 错误，方案 A（删除旧卷重来）是最佳选择。因为旧的 ibdata1 文件已经处于逻辑混乱状态，修复它的成本远高于重新初始化，而且彻底重置能避免后续出现更多兼容性问题。