看来问题还是出在下游上，换了下游就解决了。

以往论坛碰上的ddl卡住的问题，基本都是这3类。你可以排查一下，前2个重点查。因为第三个问题是分布式执行框架的问题，这个特性在7.1还是实验特性，需要手动开启，如果你没有改这块的设置，应该不太可能是第三个案例的情况。

https://github.com/pingcap/tidb/issues/61173 是这个问题，因为tidb节点部署在了一个异构的节点上，每个tidb节点的cpu不一致。这个issue提到在这种节点上执行import也卡住了，import和add index都用了ddl分布式执行框架。

[2025/07/30 10:59:13.419 +08:00] [INFO] [SegmentReader.cpp:60] [“Pop fail, stop=true”] [thread_id=865] [2025/07/30 10:59:13.419 +08:00] [INFO] [SegmentReader.cpp:60] [“Pop fail, stop=true”] [thread_id=888] [2025/07/30 10:59:13.419 +08:00] [INFO] [SegmentReader.cpp:60] [“Pop fail, stop=true”] [thr…

8.5是不错的

https://docs.pingcap.com/zh/tidb/stable/dumpling-overview/#导出为-sql-文件 -t 用于指定导出的线程数。增加线程数会增加 Dumpling 并发度提高导出速度，但也会加大数据库内存消耗，因此不宜设置过大。一般不超过 64。 有意义的，就和这个参数作用类似。

千里之行，始于足下。 想学只管学就好了。

你思路没错，应该就是block-cache的问题。 通过set config往下压就行了。 https://docs.pingcap.com/zh/tidb/stable/dynamic-config/#在线修改集群配置

别明目张胆的胡说八道

prometheus的bug。 5月26日才彻底修好。 [image] 这个issue里面的处理方法和版本应该更新到那个版本我研究了一下没搞懂，这块你可以自己研究一下。但是这个回复说，应该在http头里面加 Content-Type: text/plain; version=0.0.4 我看明白了。 实在不行你给2.27.1的exporter都加个反向代理，代理回传的时候加这个http头，应该就能解决兼容性问题。

https://docs.pingcap.com/zh/tidb/stable/tiflash-configuration/#max-days-从-v540-版本开始引入 tiflash: log.file.max-days=3 试试这样。

我的问题，这个地方8.5.2才会有这个日志输出，8.5.1是没有的。 我只能说这两个地方的写法，随着子版本的变化，确实不一样。 8.5.2多了一个btreeSet方法。我翻了下是在lighting/br使用过程中可能出现问题。然后加的。 我不确定升级后能不能解决你的问题，但如果没有更好的办法，还是可以尝试一下的。 [image] 就是红圈处这个方法。

这个靠谱，这样真的可以。 CREATE global BINDING FOR SELECT LOW_PRIORITY SQL_NO_CACHE id FROM test.t1 WHERE id >= ? AND id < ? AND create_time < FROM_UNIXTIME( ? ) ORDER BY id ASC LIMIT 500 USING SELECT LOW_PRIORITY SQL_NO_CACHE id FROM test.t1 use index(i_ct) WHERE id >= ? AND id < ? AND create_tim…

infoschema v2 btree concurrently multiple writes detected, this should be rare 搜一下这条日志，看看有没有什么内容？

感觉是bug。 select /*+use_index(test.t1, i_ct)*/ LOW_PRIORITY SQL_NO_CACHE id 这样可以， [image] 但是绑定的时候就是会报错。提示和楼主一样的。 [image]

我也好奇，试了一下，还真可以。 [image]

确实不像了。

不，你还是仔细阅读一下我上面的关于bug的那个帖子。 如果确定是扫描information_schema下的表，引起的oom。 我判断你这个问题和这个issue相关，主要是你之前发的帖子里面提到有频繁的ddl，所以我怀疑你的information_schema下的元数据会比较多。如果对这些数据做扫描，极有可能触发这个bug。不过这个推断目前还没有得到你的证实。 而且现在问题棘手的地方就在于，没有可用的LTS分支包含这个修复。 那个issue下的修复是合并在master分支上的，生产环境不太可能从master分支做修复的。还要等这个修复合并到8.5分支上去，才有可用的LTS子版本用。