问题背景

几天前，该环境ibdata1的size被置为0,无法启动，使用传输表空间等特殊恢复手段，恢复数据到新实例。

再次收到通知，MySQL无法访问了，来看看。

错误日志如下

起初，以为是一条关联select触发了mysql bug导致实例崩溃。

相关表的表结构，如下所示。

既然之前该实例是经过特殊恢复重建的，能不能把数据导出再导入呢？

发现导出时 interface_mng 表访问存在异常。

select count(*)是没有问题的。访问部分数据也是可以的。全表扫描有问题，那么就是部分数据有异常。

多次不同的尝试过后，mysql 错误日志发现新的 row0mysql.cc line 263 重要信息。

查看row0mysql.cc line 263的源码

简单的理解: 从innodb层传递到server层时,一个BLOB类型的大对象断言出错har的影响。

那么怀疑矛头指向字段类型为 text 大对象了。

定位异常为 text类型的RESP_DATA 字段。

单独排除 RESP_DATA 这一列，包含剩下的所有列，访问无问题。

访问包含 RESP_DATA 列有问题。

最终规避方案：排除异常 RESP_DATA 字段重建表

ITPub博客

MySQL 一个select把实例搞崩了，原来是表数据异常