tidb select * from information_schema.tables limit 1 查询无响应

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】V5.1.2
【复现路径】做过哪些操作出现的问题
参考 https://docs.pingcap.com/zh/tidb/v5.1/statistics 修改配置参数,但是没有解决问题
【遇到的问题:问题现象及影响】
该表查询很慢,用户的 client 连接时,常常导致无响应并且超时
【资源配置】
3TIDB + 3TiKV + 3PD
该数据库为测试数据库,数据库表数量比较多
【附件:截图/日志/监控】
语句的执行计划



请问下,有没有什么排查思路可以提供的

trace select看下 有什么结果

这个会卡主,无法显示任何信息

我们有没有办法通过日志定位 TiKV CPU 异常的原因
image
或者定位特点读的表?

这个异常是在查询tables才有,还是一直有,可以先看下tikv-detail 监控中thread cpu 看看哪种线程CPU利用率高

CPU 高的异常是一直有的,我怀疑是和 TiKV CPU 高有关
thread cpu 检查没有特别异常的节点


这台机器上有明显热点啊 ,看看dashboard 热力图 是哪个对象,然后看看相关慢SQL

确定到业务上有些一些大表在执行 delete 操作

以前在Oracle里面遇到过查询系统表慢的情况。可以通过收集系统表统计信息来优化。
TiDB好像不能这样干,手动收集这种mem表会报错。 :grinning:

ANALYZE table tables;
ERROR 1142 (42000): INSERT command denied to user 'root'@'%' for table 'tables'

请教下:我在排查时 information_schema.tables 慢时,又看到对于这个表的查询会触发 region 的扫描用于确定行数和索引大小,这部分知识哪里有详细的资料描述吗? :grinning:

我也没找到相关描述呢,表的一些元信息是存储在tikv的,所以会扫描一些region

这个表是不能够 analyze 的,我也试过的

information_schema.tables这个实际上不是一个表,而是一个系统视图,我觉得你应该排查下是不是有大量的DDL操作在执行,ddl执行的时候实际是会对这个系统视图的查询造成影响的


业务的 delete 事务已经停掉了,但是这个的 CPU 依然没有降下来
20221208-153041
热力图的表读取都没有这么大量的

DDL 有些 truncate 任务在执行

看看dashboard的慢swl sql分析除了delete外其他的

overview 页面看下 tikv里的leader分布

除了 delete 之外,业务有一些表的读取非常频繁,表数据量较大,自增字段使用了 auto_increment 导致热点 region 集中在单个机器上,目前该表已经整改,TiDB 性能趋于稳定
image
感谢各位的提供的建议