MySQL查询information_schema.columns报错

1、DTS数据同步报错

2、源端用户user1拥有所有database的权限，包括select权限

3、使用user1用户登录源端MySQL，当指定database为database1，select被拒绝

4、从MySQL的物理表文件看，表的.frm和.ibd文件是正常的

5、将报错的表table1备份为table2，删除table1，select information_schema.columns、information_schema.tables可执行且不报错

6、将table2重命名为table1，select information_schema.columns、information_schema.tables再次报一样的错误

7、将table1重命名为table2，select information_schema.columns、information_schema.tables可执行且不报错

8、原因判断

参考： https://bugs.mysql.com/bug.php?id=63527

其他用户也遇到了与MySQL对象相关的information_schema.columns、information_schema.tables的select报错，但是涉及的MySQL对象为view，而我们这里为table。

view可以指定definer等，而table1的创建语法中没有找到这样的字眼。但是推测以某一种方式与definer相关联。

9、辅证

意思是指子查询的结果多于一行。

WHERE ( SELECT cc.ip

FROM crawl_site cc WHERE cc.id=this_.site_id)>=_ip.start_ip

用这种条件，（SELECT。。。） 里面结果只能1条，多了就会“Subquery returns more than 1 row

”

解决方法：在子查询的条件语句末尾加 limit 1 。

以select * from table1 where table1.colums=(select columns from table2)这个sql语句为例。

1、如果是写入重复，去掉重复数据。然后写入的时候，可以加逻辑判断(php)或者外键(mysql)，防止数据重复写入。

2、在子查询条件语句加limit 1,找到一个符合条件的就可以了

select * from table1 where table1.colums=(select columns from table2 limit 1)

3、在子查询前加any关键字

select * from table1 where table1.colums=any(select columns from table2)

扩展资料：

解决思路

子查询多了一行，众所周知这个子查询的查询结果是只能有一行。那么现在知道了就根据报错提示找到相应的mapper.xml文件的那个sql语句里纠错。首先：

SELECT '' AS bugID,A.`SUMMARY` AS `describe`,

(SELECT CONCAT(last_name ,first_name) FROM cwd_user WHERE user_name = A.`ASSIGNEE`) AS liablePerson,

(SELECT CONCAT(last_name , first_name) FROM cwd_user WHERE user_name = A.`REPORTER`)  AS testLiablePerson ,

c.`pname` AS `status`,

(SELECT email_address FROM cwd_user WHERE user_name = A.`REPORTER`)  AS emailAddressTest ,

(SELECT email_address FROM cwd_user WHERE user_name = A.`ASSIGNEE`)  AS emailAddressDev

FROM `jiraissue` a, project b, issuestatus c

WHERE

a.`PROJECT` = b.`ID` AND a.`issuestatus` = c.`ID`

AND a.issuenum = #{bugID,jdbcType=VARCHAR}

AND b.`pkey` = #{projectName,jdbcType=VARCHAR}

看得出这里有四个子查询，然后把select的条件变成*查出来到底要什么。得到结果根据assignee和reporter的结果分别将子查询查一下发现根据报错的条件查发现是第二条有重复，这四条都会出现这个问题，所以优化一下在子查询上加个limit条件只用子查询结果的第一条就可以了。

最近接了一个锅,进入新公司接手了一个进入交付阶段的项目.在code review的时候发现很多问题,然后开始修复bug.

在测试阶段突然发现几乎所有涉及到更新的 *** 作都失败,下面贴出异常信息.

第一次 出现的时候百度了一下,猜想可能是多服务部署资源冲突,重启服务故障消失.所以没有特别重视

第二次 出现的时候只有测试环境部署,不存在多机资源冲突的问题,猜想是多线程资源交叉导致的,于是给可能导致资源竞争的地方加上了分布式锁.

由于无法重现故障,所以并没有确认问题得到解决.

第三次 故障依旧,当发现问题依然存在的时候,开始认真反思,发现自己解决问题的思路明显有问题,过于片面,一直都只在应用层面寻求解决问题的办法,而且解决问题的方式也只是在尝试百度出来的方法.并没有去思考更深层的问题.

在Mysql5.5中，information_schema 库中增加了三个关于锁的表（MEMORY引擎）；

INNODB_TRX ## 当前运行的所有事务

INNODB _LOCKS ## 当前出现的锁

INNODB_LOCK_WAITS ## 锁等待的对应关系

通过查询 INNODB_TRX 发现

当前事务中又两个RUNNING状态开始时间在一个小时之前

开始一直以为是锁表了

查看了 INNODB _LOCKS  事务信息之后发现有4行数据被锁住了一直没有释放

从这里开始发现问题了,应用已经抛了异常,事务理所当然的应该回滚才对,为什么资源依然没有释放,导致持续的阻塞呢?

其实最开始的异常信息就已经给出了答案,回到开始的地方,再看异常信息就很清楚了,应用里面的异常类是 MySQLTransactionRollBackException

是一个回滚异常, 这就说明在事务回滚的时候出了问题资源没有得到释放

然后开始查询 MySQLTransactionRollBackException  相关的信息

这个时候 innodb_rollback_on_timeout =0(默认配置)这个MySQL的配置开始进入我的视线,

举个栗子

事务在锁等待超时后是回滚事务内所有的statement还是最后一条语句；

 0表示rollback最后一条语句，默认值； 有点坑爹啊( 细思极恐 )

 1表示回滚事务内所有的statements；(此参数是只读参数，需在my.cnf中配置，并且重启生效；)

吃过一次亏,这次并没有盲目的相信百度到的信息

于是开始测试

一、验证innodb_rollback_on_timeout=off的情况

1.session A

    开启事务,事务未提交,锁住id=1的数据

2.session B 

开启事务,执行更新id=2的数据成功(事务未提交,锁住id=2),然后请求id=1等待锁超时,id=2的数据更改为222.

3.session C

请求id=2的数据50秒后显示等待锁超时

执行 SELECT * FROM information_schema.INNODB_TRX

可发现有资源一直未释放,具体到测试数据中就是id=2的资源一直被锁定,线程一直被挂起.

总结:通过实验基本可以确定是业务资源交叉导致死锁之后资源没释放造成的持续阻塞，

二.验证innodb_rollback_on_timeout=on

修改配置后将验证innodb_rollback_on_timeout=off的步骤再走一遍

发现锁等待只能在业务层面尽量避免

on/off的区别在于session C进入时不会持续阻塞,session B异常后全部回滚

---