如果你插入若干条，实际却返回了极多的 ids, 我觉得可能是产生了溢出导致的。 drizzle-orm 源码遍历 lastInsertId 到 lastInsertId + affectedRows. 但 serverless-js 的 lastInsertId 存在 overflow 的问题：lastInsertId not correct with AUTO_RANDOM id · Issue #65 · tidbcloud/serverless-js · GitHub 你可以检查发生 OOM 时的数据中，id 实际值是否超过 MAX_SAFE_INTEGER，即 900719925…

我理解你的场景是自增主键的场景 代码在这里：drizzle-orm/drizzle-orm/src/tidb-serverless/session.ts at a086f59fba7f46f3a077893ba912c99e91eaa760 · drizzle-team/drizzle-orm · GitHub 根据这个代码，理论返回的 $returningId() 的数据量是你实际插入行数，不应该是个大数组才对。 但它这里有个 bug，插入多行的时候，除了第一个 id，后续的 id 都可能是错的，因为 tidb cloud id 不一定连续。会不会是后续基于返回的 id 处理的时候导致…

登山礼盒太应景了! 我最近在爬山，TiDB 何尝不是～。希望 TiDB 越爬越高，带我们走向下一个10年的高峰。

能否 tispark 升级到 v3.2.3 试一下是否还有问题？ https://github.com/pingcap/tispark/releases/tag/v3.2.3

可以了，上 aliyun 了

没有官方说明。 但据我了解能支持 <= v6，更加新的版本可能要自己评估是否能接受可能的不兼容。 但是最好能用 client-go 就用 client-go，因为他稳定性可靠性有保障

-r 开启表内并发，dumpling 并没有聚合的逻辑，这个并发处理的数据量少，文件就小。 -r 开启后如何拆分数据是自动的，不是外部能控制的 -F 可以理解为每个并发生成的文件的上限

一直可以使用的，https://tidbcloud.com/. 只是托管在 AWS 上，开放了 5个 region。国内可以选最近的新加坡，相当于数据库部署在新加坡，延迟肯定稍高，你可以自己测具体多少延迟

emm，看了大家的回答，感觉可能是我表述的不太对。 我是这么理解的： Backup&Restore：纯从 TiKV 导入导出 SST file lighting 的物理导入模式：支持各种格式的导入。首先需要把 sql/csv/parquet 等格式编码处理成键值对，然后再直接插入 TiKV Dumpling: 仅支持从 TiDB 读取。 我的问题是，为什么没有这样一个工具：当想导出某一个大表时，从 TiKV 直接读取，然后解码成 sql/csv/parquet 等格式

BR 那不一样啊，只能在 TiDB 之间做备份恢复。 这就和即使有 restore ，还有 lighting 的物理导入道理一样。lighting 的物理导入可以支持各种格式。 虽然有 backup 了，但他并不能导出为其他格式，直接用于分析或者导入到其他数据库。

咱们业务上能否切换成 spark jdbc 写入呢，如果可以推荐做一下切换。 错误原因主要是写入前的 scatterRegion （预切region）失败。考虑到这个错误只在 TiDB 8.1 上出现，可能是兼容性方面的问题，这方面目前官方也没有保证和 TiDB 8.1 的兼容性。 时间变长可能是中间有许多错误，在重试。

It should be fixed in this pr Support localdate convert to date in datetype by shiyuhang0 · Pull Request #2780 · pingcap/tispark · GitHub

Fix in this PR https://github.com/pingcap/tispark/pull/2775.

之前写了一个小 blog

写时候的读取是用于冲突等判断 根据之前的 bechmark, 4000w 的数据用 tispark / spark jdbc 应该都是分钟级别的。如果不需要全局事务还是建议 spark jdbc 你现在的并发度是多少，benchmark 里的是 32。如果低了可以增加 executor 数量/核心数来增加并发

应该是设计的时候没有考虑好，我觉得这个参数不应该影响写入。 提了一个 issue，https://github.com/pingcap/tispark/issues/2756。 但这个问题很好规避 fix 不是很急，我有空再搞一下，或者大家有兴趣也可以贡献

这里上下文就是 learner 了 [image]

感觉确实是日志级别不太合适，但不影响正常功能。欢迎在 client-java contribute

spark-sql 还不支持相应 hint，也无法在 spark-sql 中进行语句级别的配置。 目前应该只能： 在配置文件中配置，但这就不是语句级别的 使用 spark-shell/pyspark 等可编程的方式，可以进行语句级别的配置 spark.tispark.isolation_read_engines https://github.com/pingcap/tispark/blob/master/docs/userguide_3.0.md