invalid memory address or nil pointer dereference

[wjhuang2016-PINGCAP]

您好
问题已经基本查明，由于之前版本 drop column 或者 alter column 时不会检查外键约束是否存在，在新版本中会报错。该问题已经在 v3.0.8 中修复https://docs.pingcap.com/zh/tidb/stable/release-3.0.8

目前的修复方式是把涉及的外键通过 ALTER TABLE table_name DROP FOREIGN KEY key_name 删掉。

[Tao]

如果这个表已经删除了，怎么 DROP FOREIGN KEY？

[wjhuang2016-PINGCAP]

如果表已经删除，就不需要再DROP FOREIGN KEY。

考虑到目前外键比较多，我们这边会写个脚本来帮您删掉。

[Tao]

好的，多谢了

[wjhuang2016-PINGCAP]

tidb.zip (4.4 MB)

@Tao 您好
使用方式：先拿到某个库的 meta 文件，以前面的 health_dev 为例。
将 health_dev.json 放到同目录下。
运行
./tidb health_dev

第一个参数是db名字。
然后得到输出 health_dev.sql

[Tao]

执行的时候，提示这个

[wjhuang2016-PINGCAP]

health_dev.json 和 ./tidb 是在同一个目录下吗？

[Tao]

哦，不好意思，目录没放对，我重新执行了下，生成SQL语句了。
总共生成了 6501条SQL语句，执行成功了 57条，失败 6444条。
失败的都是提示 [Code: 1091, SQL State: 42000] Can’t DROP ‘XXX’; check that column/key exists。
现在 SELECT * FROM information_schema.key_column_usage; 已经不报错了。
多谢

[wjhuang2016-PINGCAP]

很多外键名都是重复的，所以第一次执行 drop 成功后，再 drop 就会报 check that column/key exists。
应该是没对外键名做唯一性检查，所以创建了很多个同名的外键，不过现在表结构应该是没问题了。

[Tao]

已经没问题了，重新获取数据库的 meta 数据，然后再执行这个脚本，已经没有sql语句生成了。

[来了老弟]

OK​