[image] AI回复的是这样的， 官方文档有歧义误导了呀 [image]

好的，目前看来，就是你说的是对的~

这说明了什么问题？ 正常执行完的SQL 不会释放内存吗，如果前面内存正常释放了那应该所用内存就是当前SQL的内存呀

这个确定吗？

是有点这意思，但内存释放的太慢了，你看时间，都过了2天了

我们历史数据短时间内几乎不怎么变动的，时间固定数据量应该就是差不多的，为啥数据量会不一样？

不太理解，如果是其他资源占用导致这个请求资源不够了，为啥会报 超过内存限制呀？

恩，可以这样试试 但我说的问题，什么情况下可能出现呢 不太懂 同样的SQL为啥因为指定了时间范围，数据量是固定的，为啥不同时间执行所需要内存不一样

看我SQL，固定了时间范围的，这个范围就是晚上报错的

[image] 这是官方文档里对这问题的处理方法： 1，服务器负载 目前3个PD节点 并无明显的负载上涨 3，手动切换到另外2个pd leader 没有效果 第２点这个怎么使用的？

慢SQL 一直都有，并且很多，但从未 像这次这样 主要是 PD_tidb_handle_requests_duration 这个告警 ，变动幅度太大不太懂 怎么排查问题

TiDB_query_duration ，看下我发的截图

试啥？

好的 感谢~

[image] 找到了，根据这个ID，cluster_processlist里面能查到，但都没有具体的SQL命令 只有in transaction ， sleep状态，怎么定位到SQL呀？

这个connection ID 就是 ，processlist 中的ID 吗？

tidb-85.log (19.5 MB) 日志太大了，我截取了一部分日志，辛苦大佬了

没有过滤到关键词：all_schema_by_job_versions