带EXISTS时间过滤的聚合SELECT查询：SQL客户端正常、SQLAlchemy返回空值

你看到的(None, None)返回值，本质是无GROUP BY的聚合查询的固有特性：哪怕WHERE条件过滤掉了所有明细行，查询也不会返回0行，而是返回1行、所有聚合函数值为NULL的结果。结合你“移除EXISTS条件就返回正常聚合值”的对照结果，问题完全锁定在SQLAlchemy会话执行EXISTS子查询时，对“昨日记录存在性”的判定逻辑和DBeaver会话不一致，常见原因有三类：

1. 会话时区配置差异（最高发场景） #

datetime::date = (now() - '1 day'::interval)::date 这个判定逻辑高度依赖当前会话的时区设置：

• now() 返回的是带时区的事务启动时间戳，转换为date类型时，会严格按照当前数据库会话配置的时区计算对应的日期
• DBeaver等图形SQL客户端，通常在建立连接时会自动匹配本地操作系统的时区，主动执行SET TIME ZONE调整会话时区，计算出的“昨日日期”和你日常感知的本地日期完全一致
• SQLAlchemy建立连接时，默认不会主动修改会话时区，会直接沿用数据库服务端的默认时区（绝大多数生产环境的PostgreSQL默认时区是UTC）。如果你的业务使用东八区等和UTC有时差的时区，会直接导致两边算出的“昨日日期”差出整整1天，自然匹配不到stats表中存储的昨日记录，EXISTS条件直接判定为FALSE
• 这种场景下，外层查询被EXISTS过滤后没有任何明细行，聚合函数sum()计算空结果集时返回两个NULL值，和你观测到的现象完全吻合

2. 会话schema搜索路径差异 #

图形客户端和SQLAlchemy建立连接时的会话初始化参数如果不一致，可能导致EXISTS子查询访问的stats表不是同一张物理表：

• 外层查询的s1因为带fk_id = :id的过滤条件，能返回正确的sum值，说明s1指向的表是正确的
• 但EXISTS子查询是独立执行的逻辑，如果两边的schema搜索路径顺序不一样，可能s2指向的是另一个schema下的同名stats表，这个表里没有对应外键的昨日记录，就会导致EXISTS判定为FALSE

3. 参数绑定的隐式类型转换偏差 #

虽然你传入的:id参数值完全一致，但如果SQLAlchemy对参数的类型推断和DBeaver存在差异（比如将整数字段误绑为字符串类型），可能导致EXISTS里的关联条件s2.fk_id = s1.fk_id因为隐式类型不匹配，无法关联到任何记录：

• 外层查询的s1.fk_id = :id因为直接绑定参数，类型转换正常能匹配到对应行，但s2的关联条件因为类型不一致，无法匹配到任何记录

• 分别在DBeaver和SQLAlchemy的会话里执行SHOW timezone;、SHOW search_path;，对比两个会话的参数值是否完全一致
• 在SQLAlchemy的会话中单独执行SELECT (now() - '1 day'::interval)::date as check_date，对比计算出的日期和DBeaver中算出的日期是否相同
• 在两个会话里分别手动执行EXISTS对应的独立查询：SELECT count(*) FROM stats WHERE fk_id = 测试id AND datetime::date = (now() - '1 day'::interval)::date，看返回的计数是否一致

补充说明：你写的EXISTS子查询中省略SELECT列的写法，是PostgreSQL对SQL标准的特殊兼容（因为EXISTS只关心有没有行，不关心子查询返回的列值），不会导致判定逻辑差异。

内容的提问来源于stack exchange，提问作者GG.