好的，实验环境的架构是为了找出问题调整的，当然以生产环境为准，稍等我给你提供截图。
你好，另外就是没有tidb的gc逻辑可以解释一下吗，我去对应的源码里面试试分析看看能不能找出一些问题。这个我做了许多的尝试包括不同版本、是否启动tidb组件等用txn.go（tikv_client）测试结果都一样。都是这个日志输出以及同样的无法分裂
GC 机制的介绍在官网有一些文档说明：
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-overview#gc-机制简介
另外，也可以在论坛检索 GC 相关的帖子：
谢谢但是这些文章我都看了并没有得出有无tidb组件两种模式下的gc机制详细执行过程，在相关的源码组件tidb/store/gcworker和tikv/src/sever/gc_worker/gc_worker.rs找到了相应的日志输出但是详细的执行细节不是不清楚没法把源码运行逻辑搞懂。这个问题还是解决不了
如上所述，如果是 TiKV+PD 这样的架构，理论上不会自动触发 GC，即使有 GC，那么也是需要外部触发，比如 tikv-client for go 并且使用 txnapi，使用 there is no GC api for txnkv · Issue #74 · tikv/client-go · GitHub 中描述的方式触发 GC 的情况除外。你可以看下你生产环境 TiKV-Details GC 相关的监控面板是否没有数据来确认 ~
如果你的生产环境如果没有外部触发 GC ，那么 batch split 的问题，和 GC 理论上没有强相关性。所以，现在建议你那里确认下，生产环境是否有实现外部触发 GC ~
好的一会我就去生产环境查看现在我还没得到权限
方便上传下 grafana 对应的监控面板吗？这样更直观，辛苦~
你好问题得到解决了，技术人员解释直接同一个 key 反复插入… 这种情况 rocksdb 中虽然有很多 mvcc 版本数据。但是对 tikv 来说只有一个 key，所以是分裂不了的。这是tikv设计的考虑最后的话不会升级为error。感谢社区的答疑
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。