【 使用环境 】生产环境
【 OB or 其他组件 】
【 使用版本 】4.2.1.9
【问题描述】想要获取当前数据库下所有表的行数
【复现路径】
1.查询information_schema.tables,但是发现这张表记录的行数不准
2.查询系统视图,select * from oceanbase.CDB_TABLES ,但是发现某些表NUM_ROWS字段为NULL,实际count后是有值的。
information_schema.tables
里记录的行数不准,跟统计信息的收集有关。
cdb_tables.num_rows
可能也是同理。
如果你要准确的行数,直接对表 做 count(*)
运算(不要带任何 where
条件)。在传统数据库里这个建议就有点“匪夷所思”了,但是在 OB 里,这种 count(*)
都是秒出(不管表多大),有点“不可思议”。
试试看
count(*)得出的结果肯定是正确的,但对大表执行消耗的时间是很长的,而且也没法对那么多表都去做count。如果是统计信息的问题,那对表单独收集下统计信息就可以吗,租户之前做过合并了。
还有我想知道OMS全量校验时,每张表的行数是怎么获取的啊,也是每个表都去count?
好像不是,他那个我记得有的时候也会变得。应该也是统计信息里的数据吧。
您说的这个统计信息,是要先对表进行一次analyze?那OMS是从哪查的表行数呢。
information_schema.tables 这个肯定是估的。数据库也没必要时时刻刻 分分秒秒统计这个。
唯有count最准。
我理解您的意思,还是比较好奇OMS是怎么做全量校验的。如果系统表记录的不准,那就是在源端目标端分别count进行校验的?
OB 里 大表 count
不慢的,几十亿的表,count
秒出。试试看。
嗯嗯,大表只有收集完统计信息count才会快
可以看下OMS的官方文档,里面有这块的解释:
-
元信息查询:查询需要同步的库表元信息,主要读取的信息有 Table 的 Schema 信息、索引信息和分区信息。比如 MySQL 读取的统计库就是
information_schema
中的统计表信息。
不,跟是否收集统计信息无关。 性能跟是否合并后有一点关系。这个 count
的数据取自表各个宏块上的信息记录。 数据写入的时候就计算好了。