关于R2DBC批量插入性能及相关功能支持的技术咨询

1. Azure SQL批量插入性能远低于H2的原因 #

• 环境本质差异：H2是嵌入式本地数据库，所有操作在本地内存/磁盘完成，无网络延迟；Azure SQL是云数据库，每个批量请求都存在网络往返开销，10k条记录的多次批次请求会累加延迟，这是核心差距来源。
• 资源配额限制：Azure SQL的性能受DTU/vCore配额、存储类型（标准存储vs Premium存储）影响，如果当前实例的资源配额不足，会导致插入操作排队等待资源，进一步拉长耗时。
• 批量策略问题：如果批次设置过小（比如每次仅插入几十条），会大幅增加网络往返次数；另外，未开启参数化批量、连接池配置不合理（如连接数不足）也会拖慢性能。
• 数据库内部开销：Azure SQL的事务日志写入、索引维护（若目标表存在多个索引）、锁竞争等都会增加插入耗时，而H2在默认配置下这些开销更低。

2. R2DBC Batch为何没有对象列表的saveAll等价方法 #

R2DBC的Batch API是底层驱动级别的设计，专注于原生SQL批量执行的精细控制，并未封装高层的对象映射逻辑。而saveAll是Spring Data这类ORM框架提供的抽象能力，用于简化对象到数据库记录的批量持久化。

如果需要类似能力，可以通过以下方式实现：

• 使用Spring Data R2DBC的ReactiveCrudRepository.saveAll()，并配置spring.data.r2dbc.batch-size参数（如设置为500），让框架将多个对象插入合并为真正的数据库批量操作。
• 基于DatabaseClient手动封装：将对象列表转换为参数绑定的批量SQL，例如通过DatabaseClient.inSql()构建批量插入语句，循环绑定对象属性作为参数。

3. R2DBC SQL Server驱动TVP支持的上线时间及替代方案 #

目前R2DBC SQL Server驱动官方并未公布TVP支持的明确上线时间，该功能的进度依赖社区贡献和项目优先级规划。你可以关注驱动的官方代码仓库里程碑或对应功能Issue，跟踪开发进展。

在TVP支持上线前，若需保证性能，可尝试以下优化策略：

• 调整批次大小：测试并选择最优批次（如500-1000条/批），平衡网络往返次数与数据库单次负载。
• 优化Azure SQL配置：临时升级实例的DTU/vCore配额、使用Premium存储以提升IO性能；插入前禁用非必要索引，完成后再重建。
• 使用COPY INTO命令：若数据可导出为CSV等格式，通过COPY INTO批量导入，性能远高于普通批量插入。
• 混合方案：若允许部分非纯反应式代码，可通过Mono.fromCallable()调用JDBC的TVP插入逻辑，在反应式流程中包装同步JDBC操作（需注意线程池配置避免阻塞）。

内容的提问来源于stack exchange，提问作者Adam Krawiec