MySQL 8.0 系统表损坏与引擎转换故障排查实战

一、问题背景

在 MySQL 8.0 环境下，尝试将 mysql 库中残留的 MyISAM 系统表批量转换为 InnoDB 引擎时，遇到了一系列连锁报错，最终导致无法创建用户和授权。整个过程暴露出 MySQL 8.0 系统表升级、SQL 模式校验、数据字典一致性等多个层面的典型问题。

二、故障链路梳理

第一阶段：批量转换 MyISAM 系统表

执行以下语句查询 mysql 库中仍为 MyISAM 引擎的表：

sql 复制代码

SELECT CONCAT('ALTER TABLE mysql.', TABLE_NAME, ' ENGINE=InnoDB;') AS alter_sql
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'mysql' AND ENGINE = 'MyISAM';

得到待转换列表后，执行：

sql 复制代码

ALTER TABLE mysql.event ENGINE=InnoDB;

报错：

复制代码

ERROR 1067 - Invalid default value for 'modified'

第二阶段：修复字段默认值后转换成功

通过 SHOW CREATE TABLE mysql.event; 查看表结构，发现 modified 字段为 TIMESTAMP 类型，默认值为 '0000-00-00 00:00:00'（零日期）。执行修复：

sql 复制代码

ALTER TABLE mysql.event 
MODIFY COLUMN `modified` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

ALTER TABLE mysql.event ENGINE=InnoDB;  -- 成功

第三阶段：创建用户时触发更严重的错误

继续执行用户创建语句：

sql 复制代码

CREATE USER IF NOT EXISTS 'test_user'@'localhost' IDENTIFIED BY 'test_pass';
GRANT ALL PRIVILEGES ON `ai_workbench`.* TO 'test_user'@'localhost';

报错：

复制代码

ERROR 1728 - Cannot load from mysql.db. The table is probably corrupted

此时问题已从单一表的引擎转换，升级为系统权限表损坏 ，MySQL 根本无法加载 mysql.db 表，导致所有权限相关操作全部失败。

三、根因分析

1. ERROR 1067：零日期默认值被 SQL 模式拒绝

MySQL 5.7 及以上版本默认启用了严格的 sql_mode，其中包含 NO_ZERO_DATE 和 NO_ZERO_IN_DATE，明确禁止将 '0000-00-00 00:00:00' 作为合法日期默认值。

mysql.event 表的 modified 字段保留了旧版本 MySQL（5.5/5.6）的零日期默认值，在 MySQL 8.0 严格模式下执行 ALTER TABLE ... ENGINE=InnoDB 时，MySQL 会重新校验所有字段的合法性，从而触发此错误。

2. ERROR 1728：系统表结构未升级导致损坏

这是整个故障链的核心。mysql.db 表报错 "probably corrupted" 的根本原因是系统表结构与新版本 MySQL 不兼容，常见于以下场景：

从旧版本 MySQL（5.x）直接拷贝数据目录升级到 8.0
从 MariaDB 迁移后未执行系统表升级
数据目录中残留了旧版本的 MyISAM 系统表，在版本升级过程中自动升级流程失败或被跳过

MySQL 8.0 自 8.0.16 版本起彻底移除了 mysql_upgrade 工具，改为在 mysqld 启动时自动执行系统表升级。如果自动升级流程因某些原因失败（如数据目录权限问题、异常断电、手动干预等），系统表就会处于"半升级"的损坏状态，表现为可以查询但无法写入权限信息。

3. 图形化工具的语法兼容问题

在排查过程中使用 SHOW CREATE TABLE mysql.event\G 时，在 Navicat 等 GUI 工具中报语法错误。这是因为 \G 是 MySQL 命令行客户端（CLI）专属的竖向展示语法，图形化工具不支持。

四、解决方案

方案一：强制触发系统表升级（推荐）

MySQL 8.0 提供了 --upgrade=FORCE 参数，可以强制在启动时重新执行完整的系统表升级流程：

bash 复制代码

# 停止 MySQL 服务
systemctl stop mysqld

# 以强制升级模式启动
mysqld --user=mysql --datadir=/var/lib/mysql --upgrade=FORCE

# 观察日志输出，确认 "Finished upgrading system tables" 后停止
# 正常重启
systemctl start mysqld

升级完成后重新执行 CREATE USER 和 GRANT 语句即可。

方案二：跳过权限模式手动修复

如果强制升级无效，可以尝试在跳过权限检查的模式下手动重建损坏的表：

bash 复制代码

# 以跳过权限模式启动
mysqld_safe --skip-grant-tables --skip-networking &

# 登录并修复
mysql -uroot

sql 复制代码

USE mysql;
CHECK TABLE db;
REPAIR TABLE db;

-- 如果修复无效，删除后重建
DROP TABLE db;
-- 使用 SHOW CREATE TABLE 从健康实例获取建表语句重新创建
FLUSH PRIVILEGES;

方案三：重新初始化数据目录（最彻底）

如果上述方案均无效，说明系统表损坏较为严重，最干净的做法是重新初始化：

bash 复制代码

# 1. 备份业务数据
mysqldump -uroot -p --databases ai_workbench > backup.sql

# 2. 停止服务，备份数据目录
systemctl stop mysqld
cp -r /var/lib/mysql /var/lib/mysql_backup

# 3. 重新初始化
rm -rf /var/lib/mysql/*
mysqld --initialize --user=mysql --datadir=/var/lib/mysql

# 4. 启动并导入数据
systemctl start mysqld
mysql -uroot -p < backup.sql

五、经验总结与最佳实践

问题	根因	预防措施
ERROR 1067	零日期默认值被严格模式拒绝	迁移前检查 `sql_mode`，将零日期改为 `CURRENT_TIMESTAMP`
ERROR 1728	系统表结构未随版本升级	升级后立即执行 `--upgrade=FORCE`，验证所有系统表状态
`\G` 语法错误	GUI 工具不支持 CLI 专属语法	图形化工具中去掉 `\G`，改用分号结尾
权限操作失败	`mysql.db` 等权限表损坏	避免直接拷贝旧版本数据目录，优先使用 `mysqldump` 逻辑迁移