是有点这意思，但内存释放的太慢了，你看时间，都过了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

是的，卡住DDL后，有个tidb节点就一直在刷这些日志 我上面发的auto analyze的错误日志，是前面找到的错误日志，不知道跟这有没关系 [2025/04/03 10:31:28.711 +08:00] [INFO] [syncer.go:362] ["[ddl] syncer check all versions, someone is not synced"] [info="instance ip 192.168.241.85, port 4000, id 7437fbe2-6533-4d58-80ec-9028800c06c2"] ["ddl job id"=2462] [ve…

通过重启tidb server后，再次执行ddl 还是会卡住~我这问题好像是必现了 查看了下日志，好像有很多这种错误，不知道我这卡DDL跟这有什么关系？ 还有auto analyze 这个能关了吗 [2025/04/03 09:56:10.208 +08:00] [INFO] [server.go:855] [kill] [conn=991431833788874755] [query=true] [2025/04/03 09:56:10.308 +08:00] [WARN] [expensivequery.go:77] ["auto analyze timeout, kill it"]…

这个问题只能通过重启tidb server解决吗有没有其他办法？ 这是个BUG吗 在哪个版本中得到了修复？ 这俩问题谁了解呀

重启这个tidb server就好了~ 那个ddl 没了~