疑似 information_schema 查询bug问题

版本:5.0.0 release
对接的数据库类型:mysql,版本 5.7
shardingsphere 启动模式:proxy 模式。
问题描述:ShardingSphere proxy 查询 底层数据库的 information_schema.schemata 表,只能查询出 501 条记录,实际有 1266 条记录。

配置:只配置了读写分离
image
图 1.

config-root-information_schema.yaml 文件 配置:


图 2.

其他几个配置文件,除了红框中更不一样,其他都一样。
(information_schema、mysql、performance_schema、sys 是mysql中的几个系统库)

启动后,执行 sql 查询:
SELECT
schema_name,
catalog_name as encoding,
default_character_set_name AS encoding
FROM
information_schema.schemata
ORDER BY 1

debug 跟踪代码,proxy执行进入到:AbstractSelectInformationExecutor的getSourceData方法:


图 3.

上面查询得到的 ResultSet 传入到 callback处理,就是AbstractSelectInformationExecutor的 execute 中的代码,如下:


图 4.

问题就是,这个 resultset 总是只能遍历出 501 条记录,实际数据库中执行这个 sql 查询,是能查询出 1266 条的(单独写过程序查询过)。

另外,如果把 图 3. 中的 conn 变量,改成通过 DriverManager.getConnection 方式自己创建,而不是从连接池拿,就能查询出来全部数据,这个我改程序测试过。

注:图4 中我修改了 for 循环中部分代码,和这个问题没关系,请忽略改动。

你好 @Exception ,通过 AbstractSelectInformationExecutor的getSourceData 方法查询information_schema.schemata 表时,返回的真实数据会被 Proxy 中的 schema 数据替换,并不能数据库中真实数据相对应。

这个类设计的目的其实是为了 Proxy 能够兼容常见的客户端,像 Navicat 等,可以参考这个ISSUE

不太明白为什么 resultset 只能返回 501 条数据,而不是全部呢?

可能我没有说清楚,我再描述下。
您说的我能理解:返回的真实数据会被 Proxy 中的 schema 数据替换。代码里是看到了这个逻辑,但在替换之前,要先从真实库information_schema的 schemata 中查询出所有数据,一行行对比,才能替换。
问题就是,我这边真实库中有1226 条,但只能查询出来 501 条,所以最终结果就不对了。

一般的真实库的 schemata 表,不会有这么多条记录,所以我想是不是因为这个,所以大部分人没遇到该问题。

理解了,条数的问题还需要排查一下,目前还不清楚为什么;如果你发现了原因,欢迎贡献到社区 :grinning:

解决了,不是bug。
是我用的插件自动设置了查询条数限制:

1 个赞

这还真是特别,感谢反馈。

京ICP备2021015875号