SQL查询慢

【 TiDB 使用环境】生产环境
【 TiDB 版本】7.1.1
查询SQL查询很慢
执行计划: id task estRows operator info actRows execution info memory disk
Projection_4 root 0.00 csxt_sale.sale_inv_pool_header.pool_header_id, csxt_sale.sale_inv_pool_header.inv_status 1 time:1m18.5s, loops:2, Concurrency:OFF 89.5 KB N/A
└─IndexLookUp_15 root 0.00 1 time:1m18.5s, loops:2, index_task: {total_time: 1m18.1s, fetch_handle: 27s, build: 1.79ms, wait: 51.1s}, table_task: {total_time: 4m43.9s, num: 772, concurrency: 5}, next: {wait_index: 13.3s, wait_table_lookup_build: 12.9ms, wait_table_lookup_resp: 1m5.1s} 30.6 MB N/A
├─IndexRangeScan_12(Build) cop[tikv] 1.46 table:sale_inv_pool_header, index:idx_pool_header_digital_inv_no(digital_inv_no), range:[“”,“”], keep order:false 15720750 time:26.1s, loops:15402, cop_task: {num: 424, max: 2.87s, min: 746.8µs, avg: 254.4ms, p95: 1.95s, max_proc_keys: 50144, p95_proc_keys: 50144, tot_proc: 9.39s, tot_wait: 143.8ms, rpc_num: 424, rpc_time: 1m47.8s, copr_cache_hit_ratio: 0.07, build_task_duration: 103.5µs, max_distsql_concurrency: 15}, tikv_task:{proc max:2.84s, min:0s, avg: 147.6ms, p80:50ms, p95:1.68s, iters:17041, tasks:424}, scan_detail: {total_process_keys: 15299502, total_process_keys_size: 841472610, total_keys: 15299903, get_snapshot_time: 5.36ms, rocksdb: {delete_skipped_count: 224, key_skipped_count: 17570451, block: {cache_hit_count: 29395}}} N/A N/A
└─Selection_14(Probe) cop[tikv] 0.00 eq(csxt_sale.sale_inv_pool_header.inv_code, “3200223160”), eq(csxt_sale.sale_inv_pool_header.inv_no, “00382760”), eq(csxt_sale.sale_inv_pool_header.inv_type, “01”) 1 time:4m42.3s, loops:773, cop_task: {num: 2640, max: 2.96s, min: 1.15ms, avg: 142.4ms, p95: 1.39s, max_proc_keys: 20480, p95_proc_keys: 13972, tot_proc: 30.5s, tot_wait: 860.7ms, rpc_num: 2641, rpc_time: 6m15.9s, copr_cache_hit_ratio: 0.00, build_task_duration: 26.5ms, max_distsql_concurrency: 13, max_extra_concurrency: 1}, backoff{regionMiss: 2ms}, tikv_task:{proc max:2.95s, min:0s, avg: 121.1ms, p80:25ms, p95:1.32s, iters:27328, tasks:2640}, scan_detail: {total_process_keys: 15720750, total_process_keys_size: 10827121850, total_keys: 15881756, get_snapshot_time: 31.5ms, rocksdb: {delete_skipped_count: 135653, key_skipped_count: 31928713, block: {cache_hit_count: 2198212, read_count: 93, read_byte: 1.81 MB, read_time: 856µs}}} N/A N/A
└─TableRowIDScan_13 cop[tikv] 1.46 table:sale_inv_pool_header, keep order:false 15720750 tikv_task:{proc max:2.95s, min:0s, avg: 120.4ms, p80:24ms, p95:1.32s, iters:27328, tasks:2640} N/A N/A

表索引状态:

SQL:
image

不是有唯一索引 为啥不是点查,表、索引信息也是收集过的.现在这个SQL弄得全表24小时读热点 求大佬助攻


这个要看原始的查询SQL和数据模型及检查索引是否有效

选错索引了,当前走的是idx_pool_header_digital_inv_no这个,传值是空串,重新建立个复合索引就好了

怎么都是单列索引呢,组合索引更好把,时间都耗在返表过滤数据上了

手工analyze表了吗

都手工搞过的

用hint测试过其他执行计划速度吗

1、没有走主键,因为where条件中未包含主键列
2、建议单独拿一个具体语句出来分析,虽然走了digital_inv_no,但是如果全部都是空,那走索引和不走索引是一样的。

index:idx_pool_header_digital_inv_no(digital_inv_no), range:[“”,“”]

这索引选择错了,并且建议建立个组合索引提升一下

为什么不建立组合索引,全都是单列?

where后面没有pool_header_id,走不了点查的,如果每次结果都不大,说明可以建联合索引优化

索引什么的表优化做了吗?

有索引,但不是组合索引,估计加组合索引会好一点

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