SQL Server 2019 DateTime条件查询返回不匹配记录 跨机器表现异常

核心根因梳理 #

这类“列展示值正常、但WHERE比较逻辑完全反向、同结构同库在其他机器正常”的问题，通常和单实例的环境配置、版本bug、持久化列的存储错位相关，常见触发点包括：

• 持久化计算列的存储值与列定义脱节（场景匹配度最高）
  *PERSISTED计算列的计算结果是物理固化到数据页的，不会每次查询实时计算。*当实例对该表做过在线DDL修改、页级损坏、或者触发特定版本bug时，会出现数据页上存储的固化值二进制错位，但查询时返回的列值是通过实时计算逻辑填充的“显示值”，一旦WHERE子句走页扫描直接读取固化的二进制值做比较，就会出现比较逻辑完全反向的现象。
• 实例本地化配置错位导致的谓词解读偏差
  即使建表语句、表结构完全一致，单实例的默认语言、DATEFORMAT配置偏差，会直接影响统计信息生成时对datetime值的解读：如果故障实例的默认日期格式被设置为dmy（日/月/年），而正常实例是ymd（年/月/日），统计信息直方图中存储的时间边界值会被完全错位解读，最终优化器会按照错误的边界值过滤数据，出现<条件返回大于临界值的记录、>条件返回空的完全反向逻辑。
• 特定SQL Server版本的已知计算列比较bug
  多个旧版本SQL Server存在公开的已知缺陷：当表上存在基于持久化datetime计算列的索引时，查询优化器在做谓词下推时，会错误交换比较运算符的逻辑，导致过滤结果完全反向，该问题在低版本CU补丁的实例上复现率极高。

分步排查操作 #

• 第一步：验证持久化列的存储值是否存在错位
  执行以下对比语句，逐行对比列的实际存储值和实时重新计算的值：

  SELECT 
    [time],
    [DateTime] AS 存储列值,
    DATEADD(SECOND, ROUND([time] / 1000000000.0, 0), CONVERT(datetime, '1970-01-01', 120)) AS 实时计算值
  FROM [EE_2].[dbo].[Hist]
  WHERE [DateTime] <> DATEADD(SECOND, ROUND([time] / 1000000000.0, 0), CONVERT(datetime, '1970-01-01', 120))
  

  如果语句返回不一致的记录，说明是持久化列的存储值损坏，通过删除列后按原定义重新添加PERSISTED列，触发全表重算即可修复。
• 第二步：对比实例本地化配置
  在故障机器和正常机器上分别执行以下命令，对比输出结果的差异：

  -- 查询实例当前的语言配置
  SELECT @@LANGID, name, dateformat FROM sys.syslanguages WHERE langid = @@LANGID;
  -- 查询会话级的日期格式设置
  DBCC USEROPTIONS;
  

  如果发现配置差异，可临时在查询前执行SET DATEFORMAT ymd;强制指定日期格式，再重新执行原查询验证是否恢复正常。
• 第三步：排查统计信息偏差
  对目标表执行全扫描级别的统计信息更新，消除旧统计信息的错位影响：

  UPDATE STATISTICS [dbo].[Hist] WITH FULLSCAN;
  

  更新完成后重新执行原查询，同时查看执行计划中是否存在“对计算列直接做二进制比较”的节点，判断是否是旧统计信息导致的过滤逻辑错误。
• 第四步：检查SQL Server版本补丁
  执行SELECT @@VERSION获取故障实例的版本号，和正常机器对比：如果故障实例版本处于受已知bug影响的区间（SQL Server 2016 SP2 CU15之前、2017 CU23之前、2019 CU9之前），安装对应版本的最新累积更新即可修复这类比较逻辑反向的已知缺陷。

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