SQL执行时间消耗

[h5n1]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】4.0.12

【问题描述】
darshboard内一个点查的SQL 平均执行时间549ms, 页面内各项执行时间计划为0，剩余的时间消耗在哪里？

[这道题我不会 (Lizhengyang@PingCAP)]

麻烦反馈下这个 SQL 真实的执行计划（explain analyze + SQL 文本），另外麻烦把后台慢日志中这个 SQL 相关的内容也提供下

[h5n1]

慢SQL：
update tf_f_user_item_shift set partition_id=4119 , attr_value=‘1’ , end_date=‘2021-05-31 23:59:59’ , eparchy_code=‘0857’ , province_code=‘85’ , update_depart_id=‘CREDIT’ , update_staff_id=‘CREDIT00’ , update_time=‘2021-05-28 05:38:15’ where user_id=8518031482094119 and crm_attr_code=‘STOP_FLAG’ and attr_code=‘STOP_FLAG’ and start_date=‘2021-05-28 05:36:58’;

Time: 2021-05-31T12:03:05.466775011+08:00

Txn_start_ts: 425311282140282911

User@Host: bt_xxxxxxxx[bt_xxxxxx] @ xxxxxxxx

Conn_ID: 211

Query_time: 0.418484638

Parse_time: 0.00007041

Compile_time: 0.000187128

Rewrite_time: 0.000093132

Optimize_time: 0

Wait_TS: 0.000078139

DB: d_users

Is_internal: false

Digest: ea760702ec02e4cafc6e6f37820f97dc7ecc4911235e3ce3c66296cc8ed900d5

Num_cop_tasks: 0

Mem_max: 1596

Prepared: false

Plan_from_cache: false

Plan_from_binding: false

Has_more_results: false

KV_total: 0.417605807

PD_total: 0.000413625

Backoff_total: 0

Write_sql_response_total: 0

Succ: true

Plan: tidb_decode_plan(‘pQHYMAkyN18xCTAJMAlOL0EJMAl0aW1lOjE0MS4zwrVzLCBsb29wczoxLCBwcmVwYXJlOjEwMy45wgEbKGluc2VydDozNy40DSskY2tfa2V5czogewVGQDQxOG1zLCByZWdpb246MiwgBR0AMgFVQGNrX3JwYzo0MTcuNjE5MjQ2BSlccGNfY291bnQ6Mn0JMS41NiBLQglOL0EK’)

id              	task	estRows	operator info                                                                                           	actRows	execution info                                                                                                     	memory 	disk
Delete_6        	root	0      	N/A                                                                                                     	0      	time:450.4ms, loops:1, lock_keys: {time:64.2ms, region:2, keys:2, lock_rpc:64.190729ms, rpc_count:2, retry_count:1}	5.41 KB	N/A
└─Selection_11  	root	1      	eq(d_users.tf_f_user_service_item.user_id, 1716092774116388)                                            	1      	time:450.4ms, loops:2                                                                                              	1.54 KB	N/A
  └─Point_Get_10	root	1      	table:tf_f_user_service_item, index:PRIMARY(ATTR_CODE, CRM_ATTR_CODE, SERVICE_ITEM_ID, START_DATE), lock	1      	time:450.3ms, loops:3, Get:{num_rpc:1, total_time:386ms}

[这道题我不会 (Lizhengyang@PingCAP)]

1.请问下集群中是普遍存在 SQL point get 慢的问题，还是偶尔出现这个现象;
2.如果是普遍存在的话，麻烦在问题比较集中的时间段导出下集群的 overview/tidb/pd/tikv-details 的监控面板，导出方法参考：https://metricstool.pingcap.com/#backup-with-dev-tools

[h5n1]

目前是在load数据 磁盘IO可能有些影响，这些SQL是kafka做数据同步产生的DML语句，有个问题是执行计划里lock_keys占了64ms，对于lock_keys占时比较长怎么排查是哪一步影响的？

[这道题我不会 (Lizhengyang@PingCAP)]

你可以先参考这篇文档排查下锁冲突问题：
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-lock-conflicts#tidb-锁冲突问题处理

[h5n1]

Lock Resolve OPS 只有两项指标没有事务和锁相关的

安照官网文章排查没有发现有类似的日志内容

[这道题我不会 (Lizhengyang@PingCAP)]

请问 load 数据阶段已经结束了吗？现在这类 DML 语句的 Query Time 还是和之前一样耗时高吗？另外系统中其他查询的 SQL 也有同样的现象吗？