慢查询堵在coprocessor问题排查

🪐 TiDB 技术问题 性能调优
1

【 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

提取码：asni

2

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

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

3

image
image2326×1162 195 KB

image
image1994×1378 263 KB

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 |
±------------------------------±--------±--------±----------±--------------------------------------------------------±--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±----------------------------------------------------------------------------------------------------------±----------±-----+

4

业务反馈只有点查

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

stats:pseudo
表统计信息不健康

7

image
image2020×480 69.6 KB

这是健康的吧

8

image
image2324×568 74.2 KB

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

9

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

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

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。