慢查询堵在coprocessor问题排查

【 TiDB 使用环境】
支付业务

【概述】 点查很慢

【背景】 支付订单历史库,没有写入

【现象】 点击非常慢

【问题】 慢的原因

【业务影响】
支付

【TiDB 版本】
5.0.3

【应用软件及版本】

【附件】 相关日志及配置信息
tidb-pay-PD_2021-08-20T09_01_07.456Z.json (4.9 MB) tidb-pay-TiDB_2021-08-20T08_57_33.044Z.json (8.2 MB) tidb-pay-Overview_2021-08-20T08_45_31.239Z.json (3.7 MB) tidb-pay-PD_2021-08-20T09_01_07.456Z.json
tidb-pay-TiDB_2021-08-20T08_57_33.044Z.json
tidb-pay-Overview_2021-08-20T08_45_31.239Z.json
https://pan.baidu.com/s/1XFinREdcf51UywEGtqpT9g
提取码:asni

具体的 SQL 和 Explain analyze SQL 、统计信息 可以都发一下吗 ?从监控看 Seek operation 量很大,是不是有一个大的查询?

另外,拿下 14:45 分左右,出现慢 SQL 的时候,对应的 slowlog file 中该 SQL 的信息 ~



select id, pay_uid,case_id,commission,fill_amount,commission_amount,fee_rate,status,deposit_order_no,cnsmr_seq_no,create_time,update_time from pay_record_v3_deposit where pay_uid = ‘V3EHfLC2cRapycqlt1vi110c44bdc2’;

| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
±------------------------------±--------±--------±----------±--------------------------------------------------------±--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±----------------------------------------------------------------------------------------------------------±----------±-----+
| IndexLookUp_10 | 10.00 | 0 | root | | time:682.7µs, loops:1, table_task: {total_time: 9.71ms, num: 0, concurrency: 16} | | 206 Bytes | N/A |
| ├─IndexRangeScan_8(Build) | 10.00 | 0 | cop[tikv] | table:pay_record_v3_deposit, index:idx_pay_uid(pay_uid) | time:590.8µs, loops:1, cop_task: {num: 1, max: 566.8µs, proc_keys: 0, rpc_num: 1, rpc_time: 548.6µs, copr_cache_hit_ratio: 0.00}, tikv_task:{time:0s, loops:1}, scan_detail: {total_process_keys: 0, total_keys: 1, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 10, read_count: 0, read_byte: 0 Bytes}}} | range:[“V3EHfLC2cRapycqlt1vi110c44bdc2”,“V3EHfLC2cRapycqlt1vi110c44bdc2”], keep order:false, stats:pseudo | N/A | N/A |
| └─TableRowIDScan_9(Probe) | 10.00 | 0 | cop[tikv] | table:pay_record_v3_deposit | | keep order:false, stats:pseudo | N/A | N/A |
±------------------------------±--------±--------±----------±--------------------------------------------------------±--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±----------------------------------------------------------------------------------------------------------±----------±-----+

业务反馈只有点查

  1. 收集一下该表统计信息,执行计划显示统计信息不准;
  2. 补充一下 dashboard 里面看到 coprocessor 读取 的监控截图,看一下 cop task 和 scan key 的情况;
  3. slow query log 不要吝惜,也把对应的 SQL 的 slow query 发一下,对比是否可以复现问题。

stats:pseudo
表统计信息不健康


这是健康的吧

image
这个集群是不是有问题,这种sql也能跑出20s

看一下集群负载时什么样的? 如果系统表查询时间比较长,可以看一下 tidb 的监控

- 如果你的问题已解决:
  - 如果你自己排查解决了,请附上你的解决方案,对自己的方案标记【对我有用】。
  - 如果别人帮助你解决了问题,那么请选择【最有价值】的回复,标记为【对我有用】,对帮助你的人,也是一种嘉奖和赞赏。
- 被标记了【对我有用】的问题,才能被搜索到,这样子也能帮助他人更高效地找到答案。标记了【对我有用】还能获得 5 积分,5 经验值。
- 如果你的问题还没有解决,请继续追问及反馈你遇到的问题。