一、报错现象当单条预编译 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驱动版本不同导致的协议设计区别老版本驱动上限 32767根源沿用早期 PostgreSQL 协议设计参数计数采用有符号 2 字节整数存储报错层级由数据库服务端校验返回典型报错为bind message supplies X parameters, but format array requires 32767 at most新版本驱动6.x 官方系列上限 65535根源对齐 PostgreSQL 社区新版驱动优化参数计数升级为无符号 2 字节整数三、业务场景的双重坑实际项目中SQL 解析超时往往比参数上限更早触发 当 IN 语句参数达到几千至上万量级时MyBatis-Plus 等框架的 SQL 解析插件依赖 JSqlParser会因语法树节点过多、解析耗时过长抛出TimeoutException。此时请求还未触达 JDBC 驱动层自然不会出现参数超限报错。四、生产环境最佳实践无论上限是 32767 还是 65535都不建议在 IN 语句中放置大量参数数据库优化器难以对超长 IN 生成高效执行计划大概率触发全表扫描易导致分页、数据权限、SQL 审计等中间件插件出现解析性能问题单次 IN 参数控制在 1000 以内超出则分批查询超大量数据可改用临时表关联或数组匹配语法
