Kotlin执行PostgreSQL原生查询结果不稳定，与DBeaver同参数结果不一致的问题求助

遇到这种同参数下查询结果忽变的问题确实头疼，结合你描述的情况（DBeaver执行稳定、Kotlin中仅特定参数出现异常、SQL固定无动态变化），我整理了几个高概率的排查方向，你可以逐一验证：

一、参数绑定的隐式类型转换或冲突问题 #

你在Kotlin中设置参数时用到了条件赋值，比如CFOP_USOCONSUMO的if (!params.cfopUsoconsumo.isNullOrEmpty()) params.cfopUsoconsumo else 0，这里很容易出现类型不匹配的隐患：

• PostgreSQL对数据类型的一致性要求严格，如果你传入的参数类型（比如这里的0是Int）和SQL中对应字段的类型（比如VARCHAR）不匹配，会触发隐式转换，甚至导致PostgreSQL生成意外的执行计划；
• 另外你代码中还调用了.withParameters(parametros)，要警惕这个方法是否会和之前的.setParameter设置的参数产生冲突（比如parametros中包含同名key，导致参数值被意外覆盖，且这个Map的内容在不同执行中存在差异）。

排查建议：

1. 显式指定参数类型，确保和SQL中字段类型完全对齐，比如：

   .setParameter("CFOP_USOCONSUMO", if (!params.cfopUsoconsumo.isNullOrEmpty()) params.cfopUsoconsumo else "0", String::class.java)
   

2. 暂时移除.withParameters(parametros)，仅用.setParameter逐一设置参数，测试结果是否稳定；
3. 打印出Kotlin中实际绑定的所有参数的值+类型，和DBeaver中执行时使用的参数做完全对比。

二、事务隔离级别或Session环境不一致 #

DBeaver默认使用READ COMMITTED隔离级别，且会自动同步客户端的时区、字符集等Session参数，但Kotlin中JDBC连接的配置可能和DBeaver存在差异：

• 如果你的Kotlin代码使用了更低的隔离级别（比如READ UNCOMMITTED），可能会读取到未提交的脏数据，导致结果随并发写入变化；
• 连接池复用的连接可能残留了之前执行的Session参数（比如时区、排序规则），影响日期计算或聚合逻辑；
• 如果你在查询期间有并发的写入操作，DBeaver的查询可能因为执行速度快/事务上下文稳定读到一致快照，而Kotlin的查询则可能读到不同的数据版本。

排查建议：

1. 在Kotlin查询前显式设置和DBeaver一致的Session参数，比如：

   SET transaction isolation level READ COMMITTED;
   SET timezone = '你的时区（比如America/Sao_Paulo）';
   

2. 检查连接池配置，确保每次获取的连接都会重置Session参数（比如HikariCP的connectionInitSql）；
3. 在无并发写入的环境下测试（比如停掉写服务），看结果是否恢复稳定。

三、PostgreSQL执行计划缓存与参数嗅探问题 #

PostgreSQL的PREPARE语句会缓存执行计划，但参数嗅探或过时的统计信息可能导致相同参数复用错误的执行计划：

• 你的SQL是复杂聚合查询，涉及多表连接和窗口函数，PostgreSQL可能会根据第一次执行的参数生成执行计划，后续复用该计划时如果参数类型/值的分布和预期不符，会导致结果异常；
• 并行查询（PostgreSQL默认开启）可能因为系统负载变化选择不同的执行路径，导致聚合结果的明显差异。

排查建议：

1. 在Kotlin中执行查询前，先禁用并行查询测试：

   SET max_parallel_workers_per_gather = 0;
   

2. 手动更新涉及表的统计信息：

   ANALYZE 你的表名1, 你的表名2; -- 替换为SQL中涉及的所有表
   

3. 开启PostgreSQL的查询日志，记录Kotlin和DBeaver实际执行的SQL（包括绑定的参数和执行计划），对比两者的执行计划是否完全一致。

四、结果集映射的意外问题 #

你用prepareNativeQuery(..., Tuple::class.java).list()映射结果，要警惕列顺序不匹配或类型转换异常：

• 如果你的SQL返回列的顺序和Tuple类的字段顺序不一致，可能会导致数值被映射到错误的字段；
• 某些JDBC驱动对高精度数值（比如NUMERIC）的映射可能存在bug，导致不同执行中转换结果不同。

排查建议：

1. 在SQL中为所有列指定明确的别名，然后使用基于别名的映射（比如Spring Data JPA的@ColumnResult）替代位置映射；
2. 直接打印ResultSet的原始数据（不映射到Tuple），看ResultSet中的值是否已经存在变化，排除映射阶段的问题。

快速验证步骤 #

1. 把Kotlin中绑定的参数值直接拼到SQL中（模拟DBeaver的执行方式），在Kotlin中执行静态SQL，看结果是否稳定；
2. 对比DBeaver和Kotlin中执行的SQL的完整执行日志（包括参数绑定、执行计划），找出所有差异点。

内容来源于stack exchange