【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
测试的sql.sql (11.3 KB)
无标题.xlsx (12.0 KB)
测试的sql.sql (11.3 KB)
无标题.xlsx (12.0 KB)
time:1.38s, loops:830, cop_task: {num: 121, max: 89.5ms, min: 432.2µs, avg: 13.3ms, p95: 44.4ms, max_proc_keys: 20480, p95_proc_keys: 20478, tot_proc: 936ms, tot_wait: 290ms, rpc_num: 121, rpc_time: 1.6s, copr_cache_hit_ratio: 0.11, distsql_concurrency: 15}, tikv_task:{proc max:48ms, min:0s, avg: 9.12ms, p80:22ms, p95:35ms, iters:1116, tasks:121}, scan_detail: {total_process_keys: 584729, total_process_keys_size: 178611036, total_keys: 584909, get_snapshot_time: 14.1ms, rocksdb: {key_skipped_count: 1169046, block: {cache_hit_count: 8000, read_count: 24, read_byte: 39.7 KB, read_time: 72.7µs}}}
参考上面的 process_keys 的结果，和你预期的一样么？
key_skipped_count: 1169046 （表中的数据有大量的删除？）
查询的时候应该没有大量数据再删除
sql问题
key_skipped_count是还没有gc的mvcc版本数量，update和delete都会导致这个数量上升。如果sql执行之前有大量delete或者update那么这个值可能就是对的。
可以查看一下你设置的gc时间，如果长可以适当改小一点，这样mvcc就会降低很多，不会扫描过多无用的数据
1 个赞
优化sql
没有看到可以优化的地方
sql哪块问题？
能把具体的sql贴一下吗
key_skipped_count: 1169046这个值有点大，看下集群GC设置是多少，可以调快一些，等重新GC后再跑SQL应该会快一些
not(isnull(et.atdpersonpaycode.paycode))
对应ON AC.id = PCODE.paycode
PCODE回表的时候要找出paycode不为null的行（慢在这）再去和AC做hashjoin
看着像索引选择不太合理，试试先analyze一下PCODE表
先把涉及到的表手工分析一次，然后把with as的几个select 分别执行下看看速度和返回的数据量
isnull应该不会走索引吧。
1 个赞
已经analyze这个表过了，没用
我测试了只要关联查询tidb都会有这个isnull
把SQL和执行计划脱敏后贴出来吧
不好意思，前边点了以为是图片 
execution info 中time表示从进入算子到离开算子的全部 wall time，包括所有子算子操作的全部执行时间。如果该算子被父算子多次调用 (loops)，这个时间就是累积的时间。loops 是当前算子被父算子调用的次数。
https://docs.pingcap.com/zh/tidb/stable/sql-statement-explain-analyze#explain-analyze
在你的SQL中，可以理解为PCODE通过索引扫描后回表的时间，这里回表3026973行，太多了，所以慢，可以尝试让PCODE表走HASH JOIN
大佬您说的hash join是什么作用？怎么走，什么原理，有文章能学习吗？