sql解析耗时很长

[magongyong]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
3台物理机混合部署，centos 7.5

【概述】 场景 + 问题概述

【背景】 做过哪些操作
update操作

【现象】 业务和数据库现象
update解析耗时长
【问题】 当前遇到的问题
update解析耗时长
【业务影响】
测试环境测试
【TiDB 版本】
v4.0.13
【应用软件及版本】

【附件】 相关日志及配置信息

• TiUP Cluster Display 信息
• TiUP CLuster Edit config 信息

监控（https://metricstool.pingcap.com/)

• TiDB-Overview Grafana监控
• TiDB Grafana 监控
• TiKV Grafana 监控
• PD Grafana 监控
• 对应模块日志（包含问题前后 1 小时日志）

---

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[magongyong]

这个问题网上基本搜不到，不知道哪位同学是否遇到过类似问题

[xfworld (魔幻之翼)]

就这个类型的，和这个表相关的就比较慢，还是所有的都这样？

[magongyong]

目前只测试这一个表了，里面几百万条数据

[Cong-PingCAP]

我们之前没有遇到过类似的 case

@magongyong 请问，是否可以在执行 update 的时候使用 curl http://{TIDB_IP}:10080/debug/pprof/profile > profile 取一下 CPU profiling 结果，然后在这里分享一下？谢谢

注意 http://{TIDB_IP}:10080/debug/pprof/profile 取的时间是 30 秒，请保证中间一直有 update 在执行。

[magongyong]

目前看应该是热点问题，update是批量操作，一次几十个update，update的where条件id=xxx是主键，连续更新了，谢谢回答

[Cong-PingCAP]

不好意思我没太理解，这里的批量操作，是指几十个 update 在同一个事务里面吗？按理说这样也不会造成 parser 时间很长。

目前这个延迟高的问题解决了么？

[dbaspace]

1、线上集群IO不行，之前遇到导致慢
2、检查下TIDB-SERVER 负载问题，并发过高也是影响

[Orange_sword (orange_constr)]

学习了

[TiDBer_NtDbUm7p]

找到原因了？

[疾风之狼]

热点会影响Update语句的解析？按说这么多的同样的Update语句，不需要每个语句解析一次，应该缓存有执行计划才对。

[逍遥_猫]

那位大神解答下，这个解析到底都干了些什么呢？？？

[magongyong]

解决了，是并发操作的，不同的事务

[magongyong]

我们这是改业务sql解决的，不连续更新主键，应该是热点问题，或者锁问题

[Orange_sword (orange_constr)]

如果是锁等的话，应该可以读到锁信息吧