INFORMATION_SCHEMA.TABLES 元数据表查询很慢

  • 【TiDB 版本】:v4.0.6
  • 【问题描述】:

查询元数据表很慢,需要10s以上。 但是其他元数据表和业务数据表则正常。 帮忙看看我该怎么排查这个问题。

SELECT * FROM INFORMATION_SCHEMA.TABLES LIMIT 10;

  1. 先 analyze table ,重新收集下统计信息
  2. 反馈下 explain analyze sql, trace sql 结果
  3. 看下执行时,集群整体duration 是多少
  1. analyze table 报错:
    ANALYZE TABLE INFORMATION_SCHEMA.TABLES;

INSERT command denied TO USER ‘root’@’%’ FOR TABLE ‘TABLES’

image

image

这个集群中有多少张表?

系统表和业务表一共1500张

在跑这个查询的中间(最好晚一些)
运行一下 curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2 拿一下这个结果

pc.log (1.4 MB)

这个是在语句没有返回结果的时候抓取的吗,只看抓取信息的话,语句应该已经执行结束了

pc.log (1.8 MB)

上面那个是在查询结束后跑的。这个是在查询中的。

问一下现在好了吗?另外,如果不加 limit 速度如何?看上面的 trace ,感觉应该会很快,当时集群系统资源使用情况如何啊?

查全表也慢,和之前一样。 集群压力不大。 除了这个表。其它业务表和元数据表都正常。。。

可以把相关 SQL 慢日志中的内容,给一下吗

# Time: 2020-11-18T19:40:44.964858669+08:00
# Txn_start_ts: 0
# User@Host: root[root] @ 172.16.100.58 [172.16.100.58]
# Conn_ID: 92407936
# Query_time: 8.896591786
# Parse_time: 0.000027173
# Compile_time: 0.001052338
# Rewrite_time: 0.000557936
# DB: base_enterprise_db
# Is_internal: false
# Digest: 120b806b0b81e490bc9ccb4a626d186df81cd14c6da1eac67f27fde4b2be89b4
# Num_cop_tasks: 0
# Prepared: false
# Plan_from_cache: false
# Has_more_results: false
# KV_total: 0
# PD_total: 0.000000846
# Backoff_total: 0
# Write_sql_response_total: 0.032100753
# Succ: true
# Plan: tidb_decode_plan('kAF0MAkxNl83CTAJMTAwMAlvZmZzZXQ6MCwgY291bnQ6BRUFBXR0aW1lOjguODYzMjUzMTI3cywgbG9vcHM6MglOL0EBBCAKMQkxMV8xMAkJTEwwCXRhYmxlOlRBQkxFUwkxMDI0CR1FEDQ4OTk0FUUkMQlOL0EJTi9BCg==')
# Plan_digest: 8e784bf7b4d57ff32ea91e98c40ea1ad13a9ee8c3457a33e0e1832cf42fa1f44
use base_enterprise_db;
SELECT *FROM INFORMATION_SCHEMA.TABLES  LIMIT 0, 1000;

1、想确认一下,在不同的 tidb-server 上执行该命令,都会很慢吗?能否提供一下 对应 tidb-server 的对应时间的 日志。上面慢日志中没有想要的信息

这边集群有2个tidb-server,分别在2个上面查询也一样慢。

在查询的时候看了一下tidb日志,没有什么有用的信息。 大多数都是一些info。

:ok_hand:,能帮抓下火焰图吗,执行下面的命令,并把结果文件给一下,curl http://{TiDBIP}:10080/debug/zip?seconds=60 --output debug.zip
另外,麻烦给一下 explain analyze 的内容,想看后面的 info 信息

debug.zip (4.7 MB)

麻烦尽快看一下,已经影响到生产了。

1、现在集群负载很高?上面说业务表及集群压力不高啊

只有一台tikv负载高,在负载低的时候查询这个元数据表也一样很慢。

1、如果只有一台 tikv 负载较高,可以参考热点问题处理思路解决,应该和该 SQL 是没关系的,热点问题,可以官网搜一下 split 命令相关的资料
2、能告诉一下,你们集群的服务器配置吗。cpu、内存、磁盘