我的也是这样，正打算 debug 看看能不能复现

autocommit

一样的，你看改写后的sql，同样有limit 80000，200

我觉着应该不是，你看我改写之后的sql，同样有这个查询，而且，我把这一个去掉了，还是一样，结果出来了，但是还是在一直运行。 [image]

cpu.profile (91.1 KB) heap.profile (3.0 MB) goroutine (12.9 KB)

对集群设置了全局的 max_execution_time=3600000 也同样没效果。 [image]

因为业务原因，该条sql的改写对源码的影响太大，目前不支持改写，所以各位有什么好的解决办法？或者知道造成这种现象的原因吗？

tidb 还不支持 returning 关键字

可以的，可以使用 -N 指定节点，可以参考文档 tiup cluster start | PingCAP Docs

处理出错的 DDL 语句 | PingCAP Docs 具体处理方式可以参考这篇文档

工作的时候好好工作，工作外的时间，家庭第一

这里就不得不放出这两张图了 [image] [image]

可以参考Grafana 监控面板中 TiKV 监控指标详解 | PingCAP Docs Compression ratio：每一层的压缩比 可以参考这个监控项。

可以的，可以看看这两个文档。 PD 调度策略最佳实践 | PingCAP Docs PD Control 使用说明 | PingCAP Docs

tidb、tikv事务处理的相关源码

你前面发的，tidb里面一直刷的 TIME_COP_PROCESS 是有慢查询，所以会一直刷。 至于后面发的OOM的这个，有这条日志前面几条的信息嘛？找找 error 、warning之类的

tidb oom，日志里面会有关键字的，你把oom的位置找到，看看前后文