感谢各位， 找到问题了，是我的条件没走索引， 通过 --sql " force index" 速度就很快了，700万数据2分钟就跑完了。 就很奇怪， 明明是加了索引，为啥找不到索引，好像我们项目上也遇到过这问题

最后竟然报错了，不止是慢。 [tidb@b67 tidb-toolkit]$ ./dumpling -uroot -P 4000 -hb85 -p 'xxxx' -T bsppr.xpost --where "update_time < '2025-02-10 00:00:00'" -t 16 -o /tmp/dumpling-bsppr-xpost-test -r 100000 -F 256MiBRelease version: v7.1.5 Git commit hash: caa60c0917a886933a525d25e17057faac5b4da2 Git branch: …

按你说的加上了-F 256MiB -r 100000 ，但感觉还是一样的效果 [2026/07/10 11:28:08.229 +08:00] [INFO] [versions.go:54] ["Welcome to dumpling"] ["Release Version"=v7.1.5] ["Git Commit Hash"=caa60c0917a886933a525d25e17057faac5b4da2] ["Git Branch"=HEAD] ["Build timestamp"="2024-04-24 11:09:23"] ["Go Version"="go version go1…

为啥不在工作日工作时间段啊？ 大家都不喜欢摸鱼吗？？

[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 ，看下我发的截图

试啥？

好的 感谢~