为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【概述】 循环batchPut写入tikv时，在region拆分过程中写入会有大量写入出错（region拆分前获取到key对应的region，在put写入的时候原region拆分，对应需写入的id变化导致写入报错），请教下有什么好的办法可以规避或者减轻此类问题么
【应用框架及开发适配业务逻辑】
【背景】
【现象】 业务和数据库现象
【问题】 当前遇到的问题
【业务影响】
【TiDB 版本】
【附件】 org.tikv.common.exception.RegionException: Region Exception occurred EpochNotMatch current epoch of region 48 is conf_ver: 5 version: 11, but you sent conf_ver: 5 version: 10
不是通过tidb server而是直接连接tikv写入的吧，能不能加入重试机制
是的，直接使用tikv，本身客户端有重试机制，但是拆分的那段时间对性能影响比较大。
可以试试在每次put之前，到pd获取leader所在的region位置再去写入。
也可以在发现写入失败的时候，在业务程序逻辑添加重试的机制，不过在遇到失败后重试时的性能不好保证。有tidb-server时，它内部会帮我们做一定的重试，客户端的感知没有比直接使用tikv那么明显
感谢答复。目前我使用的是RawKVClient，看了源码的写入逻辑会首先去PD获取对应的region位置，然后再写入至对应的region中。但是在这两步中间出现region拆分时会就会出现region版本不一致的错误导致写入失败。tidb内部对这类问题有做啥优化么
region发生拆分、合并、迁移是系统根据各方面因素综合打分判定的调度结果，通常会是因为节点空间不足、有读写热点、扩缩容等现象触发，如果想要在大数据量写入时的region拆分，感觉没有根治的办法，但是可以尝试通过调整pd的调度参数减缓这一过程、也可以调整tikv读写热点判断的阈值来缓解。
试试修改region-split-key-count 和region-split-size 参数的值，以减少拆分的频率;尽量避免使用长时间运行的事务，导致 region 拆分的频率加快。
方便使用transactionKVClient吗
啥业务，能使用乐观锁不
看一下这个贴子
嗯嗯，这部分参数适当调大了点。另外，对region做了预分区并把自动拆分region的参数调大了些
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。