openGauss JDBC PreparedStatement 参数上限问题

一、报错现象

当单条预编译 SQL 中的?占位符数量超过驱动上限时，会抛出如下异常：

org.opengauss.util.PSQLException: PreparedStatement can have at most 65,535 parameters. Please consider using arrays, or splitting the query in several ones, or using COPY. Given query has 65,536 parameters

该问题常见于超长IN(?,?,?)查询、批量插入等场景。

二、两个上限值的由来：32767 vs 65535

驱动版本不同导致的协议设计区别：

1. 老版本驱动：上限 32767

   • 根源：沿用早期 PostgreSQL 协议设计，参数计数采用有符号 2 字节整数存储
   • 报错层级：由数据库服务端校验返回，典型报错为bind message supplies X parameters, but format array requires 32767 at most

2. 新版本驱动（6.x 官方系列）：上限 65535

   • 根源：对齐 PostgreSQL 社区新版驱动优化，参数计数升级为无符号 2 字节整数

三、业务场景的双重坑

实际项目中，SQL 解析超时往往比参数上限更早触发： 当 IN 语句参数达到几千至上万量级时，MyBatis-Plus 等框架的 SQL 解析插件（依赖 JSqlParser）会因语法树节点过多、解析耗时过长抛出TimeoutException。此时请求还未触达 JDBC 驱动层，自然不会出现参数超限报错。

四、生产环境最佳实践

无论上限是 32767 还是 65535，都不建议在 IN 语句中放置大量参数：

1. 数据库优化器难以对超长 IN 生成高效执行计划，大概率触发全表扫描
2. 易导致分页、数据权限、SQL 审计等中间件插件出现解析性能问题
3. 单次 IN 参数控制在 1000 以内，超出则分批查询；超大量数据可改用临时表关联或数组匹配语法