tidb慢查询问题

版本:4.0.10
os: 16Core 64G内存
表大小:45W记录 explain查看是走了索引(where的三个条件正好是复合索引的三列,不存在数据类型转换的问题)
返回4条记录
查询当时(查询的时候)前5分钟满足某个条件的清单数据,不存在查询很早的冷数据。

Conn_ID: 23544972

Query_time: 3.628473079

Parse_time: 0.000101786

Compile_time: 0.000526445

Rewrite_time: 0.000171957

Cop_time: 3.627442079 Wait_time: 0.001 Request_count: 2 Total_keys: 5 Process_keys: 4

Is_internal: false

Num_cop_tasks: 2

Cop_proc_avg: 0 Cop_proc_p90: 0 Cop_proc_max: 0 Cop_proc_addr: 10.84.78.202:7301

Cop_wait_avg: 0.0005 Cop_wait_p90: 0.001 Cop_wait_max: 0.001 Cop_wait_addr:

Mem_max: 20880

Prepared: false

Plan_from_cache: false

Has_more_results: false

KV_total: 3.627341427

PD_total: 0.000008914

Backoff_total: 0

Write_sql_response_total: 0.000005451

Succ: true

当时tikv的 io和cpu负载都很低,非常低。


这样的查询耗时3秒多,请问有什么思路排查?

2赞

这是tidb_decode_plan后当时部分的执行计划

2赞

sql 还有表结构都要贴出来吧

2赞

explain 计划不全啊,来个全的

2赞

PRIMARY KEY ( id ),
UNIQUE KEY dm_sl_store_data_10min_fmit_rt_rowkey_dt ( app_id , row_key , dt ),

2赞

@songxuecheng @xfworld

2赞

执行计划能贴个图么~ 这个都变形了 :rofl:

2赞

确实太长,我截图也截不全的,copy文字下来放到ue编辑器,可以格式化。

2赞

@xfworld


2赞

IndexRangeScan_28 cop[tikv] 0.01 table:a, index:dm_sl_store_data_10min_fmit_rt_rowkey_dt(app_id, row_key, dt), range:[“SL201” “1627453831088” 2021-08-16 21:51:39,“SL201” “1627453831088” 2021-08-16 21:53:39), keep order:true, desc 2 tikv_task:{time:0s, loops:1} N/A N/A

这已经是索引范围扫描了… 但是这个索引的范围值是不是不对?
“SL201” “1627453831088” 2021-08-16 21:51:39

两次的值,一样呢

2赞

走索引是没有问题的


这是对应时刻的pd leader日志
查看了当时pd主机的io情况:

io可能hang住了,推测是这个原因。

3赞
  1. 根据你的执行计划,看起来大部分时间耗费在了 cop_time。
    image
  2. 请问这个是测试环境还是正式环境。 可以看下监控 tikv-detail 中 coprocessor 监控,是否整体消耗过高导致。
  3. 也可以在业务低峰期,执行试试,是否还是耗时这么久,多谢。
  • 该问题是否已经解决?如已经解决,请 对问题标记【对我有用】,问题 才能被搜索到,也能帮助他人更高效地找到答案。如果你的问题还没有解决,请继续追问及反馈你遇到的问题,附上操作提示或者截图。

最终解决了吗?找出问题了吗?

主机io有几秒的hang住

我看你反馈的那个io截图,是实时的还是说可以查历史的?

历史的

请教下,用什么命令可以查看?

历史采集记录的而已,sar iostat都可以