引言

生产环境，某表末尾添加一个字段，保存造成数据库崩溃，idb 文件损坏，数据库版本号 8.0.29，表数据 5K 多条

起因

2022-08-12 12:20 左右，中午吃饭回来打算更新线上程序，同事操作表添加一列，数据库出问题了

线上站点打开缓慢或打不开，接着排查问题

查看服务状态 systemctl status mysqld 正常

客户端连接数据库打开任意表，极慢或打开失败

查看数据库日志发现有错误信息输出

[InnoDB] InnoDB initialization has started.
[InnoDB] InnoDB initialization has ended.

类似 的错误信息：https://github.com/gitpod-io/gitpod/issues/9314 ，还有锁表关键字 lock TABLES

打开任意表，有些能打开有些不能，问题定位到具体某一张表 A (A 表就是添加字段的表，此前没有反应过来)

只要访问 A 表，或关联访问，查看 DDL 等操作都会造成实例重启，均有日志输出

所以，解释了为什么打开缓慢或打不开，因为线上应用程序在持续查询 A 表，实例在不断重启

解决

首先，停止线上应用程序，开始还原数据库备份文件

我们做了数据库备份任务（12 小一次），最新备份为中午 12 点 8 分

接着修改生产环境表 A 为 A2，重新创建表 A，从还原的数据库恢复表 A

对比系统日志记录，备份数据表 A 为最新，万幸！！！

至此，重启应用，一切正常

接着

此时表 A2 就像一个地雷，一踩就爆，我们有定时任务备份，表 A2 肯定会有影响，计划晚上 6 点删除表 A2

嘿嘿，很简单，结果执行删除表 A2，数据库又崩了

先进行了数据库备份

-- 跳过锁表
mysqldump -u root -p --quick --skip-lock-tables -R db > /tmp/db.sql

-- 排除某表
mysqldump -u root -p --ignore-table=db.A2 -R db > /tmp/db_2.sql

接着开始删除表 A2 计划：

• 修改现有数据库 db 为 db2，重新创建数据库 db，再把数据恢复到 db，排除表 A2，再删除数据库 db2
• MySQL 不能直接修改数据库名称，所以通过修改表名 rename table db.table to new_db.table;
• 没考虑到还有视图、存储过程，又改回来
• 期间有不少尝试：
• 拷贝表 A2 的 idb 文件进行恢复，alter table A2 import tablespace，但失败了
• 重启服务器，重启数据库服务，改一些配置文件等等都没用
• 问题越来越明确到是 idb 文件损坏造成的，突然想到通过截断把数据清空
• 执行 truncate table A2，竟然成功了，再接着删除表 A2，也成功了！！！

一切都恢复正常，好像很简单就解决了，而过程却是那么的真实。