使用jsonb_array_elements做PostgreSQL批量插入存在哪些缺点与坑？

这个方案在性能上确实有明显优势，但大规模落地前需要注意以下实际问题：

• 单批次数据量上限限制
  所有数据拼接为单个jsonb参数传入，会同时受应用端JDBC报文大小限制、PostgreSQL服务端work_mem、max_stack_depth等参数约束。测试1万条没问题，但如果单批次提升到5万甚至10万条，很容易触发参数限制直接报错，且超大JSON的序列化、反序列化开销会陡增，反而性能不如传统批量插入，极端场景还会导致应用或数据库OOM。
• 异常排查成本极高
  不管是字段类型不匹配还是约束违反，该方案的报错信息都非常模糊：比如某一行的年龄字段传了字符串，报错只会提示cannot cast jsonb string to integer，不会告诉你是批量数组里的第几条数据出问题；如果触发唯一键约束，也不会返回冲突的具体行信息，整个批次直接失败后，要定位问题只能把整个jsonb拉出来逐一核对，生产环境排查效率极低。甚至如果出现隐式类型转换精度丢失的问题，你连脏数据都很难发现。
• 数据库侧CPU开销更高
  本地测试快的核心是省了多次网络往返和SQL解析开销，但实际生产环境中数据库通常是整体瓶颈，jsonb解析、字段类型转换的逻辑全部运行在数据库侧，批量越大对数据库CPU的额外消耗越明显，高并发场景下很容易打满数据库CPU，影响整个实例上的所有业务，而传统批量插入的类型转换逻辑在应用侧执行，应用水平扩容成本远低于数据库。
• 事务风险高
  单条大SQL的执行时间更长，持有表锁、行锁的时间也更久，高并发下很容易出现锁等待甚至死锁。如果执行过程中出现异常需要回滚，大事务的回滚耗时会非常长，严重影响数据库可用性。
• 工具链适配成本高
  这种非标准的插入写法无法适配JPA、MyBatis Plus等ORM框架的自动SQL生成、审计、分库分表等能力，所有相关CRUD都需要手写维护，后续项目迭代、架构调整的适配成本远高于普通INSERT语句。

如果一定要落地该方案，建议将单批次大小控制在1000~2000条，且在应用层提前做好所有字段的类型、约束校验，避免把校验逻辑抛到数据库侧。

内容的提问来源于stack exchange，提问作者Ilya Tatsiy