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

[dbms-ops]

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

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

[h5n1]

trace select看下 有什么结果

[dbms-ops]

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

[dbms-ops]

我们有没有办法通过日志定位 TiKV CPU 异常的原因

或者定位特点读的表？

[h5n1]

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

[dbms-ops]

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

[h5n1]

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

[dbms-ops]

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

[我是咖啡哥]

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

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

[dbms-ops]

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

[h5n1]

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

[dbms-ops]

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

[tidb菜鸟一只 (小菜一颗)]

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

[dbms-ops]

业务的 delete 事务已经停掉了，但是这个的 CPU 依然没有降下来

热力图的表读取都没有这么大量的

[dbms-ops]

DDL 有些 truncate 任务在执行

[h5n1]

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

[h5n1]

overview 页面看下 tikv里的leader分布

[dbms-ops]

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

感谢各位的提供的建议