SQL有没有进一步优化的空间

🪐 TiDB 技术问题 性能调优
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

SQL 语句为
SELECT id,data_type,op_type,op_status,request_url,request_body,response_text,create_time,qipuid,fileid,uid,user_type,original_request,site,raw_request,raw_response,agent_version,platform_id,source,ip,displayname_score,title_low_quality_score,customtag FROM (select id,data_type,op_type,op_status,request_url,request_body,response_text,create_time,qipuid,fileid,uid,user_type,original_request,site,raw_request,raw_response,agent_version,platform_id,source,ip,displayname_score,title_low_quality_score,customtag from mp_video_log where (id >= 1165020428 AND id < 1165297746)) babelx_sub_query;
执行计划为

| id                 | estRows   | estCost       | actRows | task      | access object      | execution info                                                                                                                                                                                                                                                                                                                                            | operator info                                   | memory   | disk  |
| TableReader_7      | 270425.63 | 135908259.57  | 277318  | root      |                    | time:1.41s, loops:280, cop_task: {num: 72, max: 1.18s, min: 6.53ms, avg: 173.2ms, p95: 576.4ms, max_proc_keys: 17376, p95_proc_keys: 11740, tot_proc: 5.61s, tot_wait: 52.8ms, rpc_num: 72, rpc_time: 12.5s, copr_cache_hit_ratio: 0.00, build_task_duration: 13.1ms, max_distsql_concurrency: 9}                                                         | data:TableRangeScan_6                           | 202.0 MB | N/A   |
| └─TableRangeScan_6 | 270425.63 | 1216185173.80 | 277318  | cop[tikv] | table:mp_video_log | tikv_task:{proc max:279ms, min:1ms, avg: 42.9ms, p80:75ms, p95:136ms, iters:550, tasks:72}, scan_detail: {total_process_keys: 277318, total_process_keys_size: 860797065, total_keys: 277390, get_snapshot_time: 49.4ms, rocksdb: {key_skipped_count: 554564, block: {cache_hit_count: 2076, read_count: 13171, read_byte: 137.8 MB, read_time: 92.6ms}}} | range:[1165020428,1165297746), keep order:false | N/A      | N/A   |

这个 SQL 为定时任务抽取数据，看看有没有优化的空间降低耗时。

2

没啥优化空间了，这 1 s 多就执行完了，还不够快吗，你客户端能处理的过来吗

3

这直接查不就行了吗为什么要写个子查询

1 个赞
4

1.不用写子查询
2.加索引
3.业务上降低id每次取数范围
能够优化的也就这些了

5

多久抽一次数据

6

批量抽取数据的，有的SQL 1.2S，有的 SQL 6～8S 执行计划一样，就发个贴问问

7

大数据那边的服务写的框架标注的 babelx_sub_query=。=估计就是想区分出来是这个服务做的吧

8

一天一次

9

表结构能看下吗？id是自增主键？

10

子查询似乎没啥必要，考虑分页查询试试呢

11

可以试试，不用子查询。

12

已经很快了，感觉没啥优化空间了。

13

:yum:加快GC，减少无效版本数据。

Rocksdb_key_skipped_count：RocksDB 扫数据时遇到的已删除 (tombstone) Key 数量。

14

感觉没啥优化空间了。

15

单独给你这个应用再申请一个db账号，这不就可以分出来

16

按理说id这一列是肯定有索引的。但是执行计划是TableRangeScan，我怀疑是个聚簇索引表。
但是聚簇索引表如果id是连续分配的话，肯定有热点问题。

表结构里面是否有

/*T![clustered_index] CLUSTERED */

这种信息？

17

是聚簇索引表

1 个赞
18

如果id 是连续的， between…and…比

> id>= 1165020428 ANDid < 1165297746 好些。

20

最多可以再优化20%左右。

22

1s左右的速度就不用再继续优化了。