PostgreSQL与SSRS执行同一查询结果不一致的问题求助

这种跨平台查询结果不匹配的情况确实容易让人头疼，结合你给出的SQL和问题描述，咱们一步步拆解可能的原因：

1. 先排查INNER JOIN的关联过滤逻辑 #

你的查询用了INNER JOIN "public".aircraft ON "public".flight.aircraft_id = "public".aircraft.id，这意味着只有flight表中aircraft_id在aircraft表存在匹配id的记录才会被返回。如果那些“实际存在但缺失”的数据是flight表中的记录，且对应的aircraft_id在aircraft表中没有匹配项，就会被INNER JOIN直接过滤掉。

验证步骤：

• 先单独查询flight表中符合条件的记录总数：

  SELECT COUNT(*) FROM "public".flight WHERE maintenance_flight_time > 0;
  

• 再执行你的完整SQL，对比两者的数量差
• 如果数量不一致，直接定位缺失的记录：

  SELECT aircraft_id FROM "public".flight 
  WHERE maintenance_flight_time > 0 
  AND aircraft_id NOT IN (SELECT id FROM "public".aircraft);
  

如果有结果返回，说明这些记录因为关联不到aircraft表被过滤了，根据业务需求可以改成LEFT JOIN来保留flight表的所有符合条件的记录。

2. 检查时区与日期格式化的潜在影响 #

你用to_char处理了flight_date、health_start_date和health_end_date，如果PostgreSQL的时区设置和SSRS的时区不一致，可能会导致日期时间的格式化结果出现偏差，甚至间接影响数据返回（比如某些记录的时间字段为空，格式化后产生异常值）。

验证步骤：

• 查看PostgreSQL当前时区：

  SHOW timezone;
  

• 对比SSRS数据源连接的时区设置（SSRS通常会使用服务器时区或连接字符串指定的时区）
• 尝试去掉格式化，用原始字段执行查询，看结果是否正常：

  SELECT "public".aircraft.aircraft_id, "public".aircraft.register_number, 
         "public".flight.flight_date, "public".flight.health_start_date, 
         "public".flight.health_end_date, "public".flight.maintenance_flight_time 
  FROM "public".flight 
  INNER JOIN "public".aircraft ON "public".flight.aircraft_id = "public".aircraft.id 
  WHERE "public".flight.maintenance_flight_time > 0 
  ORDER BY "public".flight.flight_date;
  

如果这个查询能返回缺失的数据，说明格式化过程中出现了问题，可能是部分记录的时间字段类型不匹配（比如health_start_date是date类型而非timestamp，用hh24:mi格式化会丢失信息）。

3. 确认maintenance_flight_time的字段类型与精度 #

如果maintenance_flight_time是浮点数类型（比如numeric、double precision），可能存在精度问题导致一些看起来大于0的值被判定为0（比如0.0000001在某些场景下被截断）。

验证方法：

SELECT maintenance_flight_time FROM "public".flight 
WHERE maintenance_flight_time > 0.0 AND maintenance_flight_time < 1.0;

如果有结果返回，说明这些小数值可能是被遗漏的原因，可以尝试调整WHERE条件为maintenance_flight_time >= 0.000001（根据实际业务精度需求），或者考虑将字段类型改为interval来更合理地存储飞行时间。

4. 排查PostgreSQL的权限与行级安全策略 #

如果执行查询的PostgreSQL用户被设置了行级安全（RLS）策略，或者没有flight表某些记录的读取权限，也会导致数据缺失。

验证步骤：

• 用超级用户（比如postgres）执行相同的查询，看是否能返回缺失的数据
• 查看flight表的行级安全策略：

  SELECT * FROM pg_policies WHERE tablename = 'flight';
  

5. 再次排除SSRS的隐藏干扰 #

你已经删除了.rdl.data文件，但可以再确认：

• SSRS的数据源是否使用了正确的PostgreSQL连接字符串，有没有指定额外的参数（比如时区、编码）
• SSRS报表是否设置了隐藏的筛选器或参数，导致结果与直接查询不同

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