奇怪的慢查

【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】
表结构

查询语句

执行计划

使用到了索引,手工执行也很快,为啥会是慢查,dashboard的cop消耗这么长时间 ,请教从哪个方向分析?

建议看看accountid的数据分布,有多少条,多大

         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 41881722
 Avg_row_length: 104
    Data_length: 4355699088
Max_data_length: 0
   Index_length: 670107552
      Data_free: 0
 Auto_increment: 42113927
    Create_time: 2023-07-20 02:50:58
    Update_time: NULL
     Check_time: NULL
      Collation: utf8mb4_unicode_ci
       Checksum:
 Create_options:

是不是order by引起的?

dashboard看也就0.5秒,也不太慢吧

看看coprocessor读取那一页的内容

结果只有一行吗

  1. 手工执行很快具体是多久?
  2. 提供下 explain analyze 的执行结果看下

Coprocessor等待耗时高而执行耗时低,应该是整个系统的tikv Coprocessor 压力比较大吧,Coprocessor 线程忙碌导致等待

account_id返回数据并不多

量大不大,有时候内存没命中,扫盘有可能有长尾的。

有可能tikv负载高,看看tikv cpu和io总的情况

手工执行很快

1 row in set (0.00 sec)

执行计划
time:524.5µs, loops:2, cop_task: {num: 1, max: 482.9µs, proc_keys: 2, rpc_num: 1, rpc_time: 465.9µs, copr_cache_hit_ratio: 0.00, distsql_concurrency: 15}, tikv_task:{time:0s, loops:1}, scan_detail: {total_process_keys: 2, total_process_keys_size: 110, total_keys: 3, get_snapshot_time: 10.4µs, rocksdb: {key_skipped_count: 2, block: {cache_hit_count: 11}}}
time:934.3µs, loops:2, cop_task: {num: 2, max: 442.1µs, min: 420µs, avg: 431µs, p95: 442.1µs, max_proc_keys: 1, p95_proc_keys: 1, rpc_num: 2, rpc_time: 841.4µs, copr_cache_hit_ratio: 0.00, distsql_concurrency: 15}, tikv_task:{proc max:0s, min:0s, avg: 0s, p80:0s, p95:0s, iters:2, tasks:2}, scan_detail: {total_process_keys: 2, total_process_keys_size: 309, total_keys: 2, get_snapshot_time: 17.8µs, rocksdb: {block: {cache_hit_count: 20}}}

grafana哪个指标可以验证这一点

cpu


io util高的时候,时间段对应不上

监控 tikv 有命中率,但是这玩意又不能实锤你这个 SQL 是这个影响了。

把dashboard那条慢sql的执行计划贴出来

1 个赞



这个能对应上

最重要的信息在右边

1 个赞