SQL Server转换Hijri日期后与GETDATE()比较报越界错误

这个报错和嵌套查询的写法本身没有关系，核心是SQL Server查询优化器调整执行顺序，触发了谓词下推导致的：

• 你单独执行内层子查询时，优化器生成的执行计划遵循了「先过滤my_col is not null的行，再对剩余行做回历转datetime」的逻辑，加上查询返回结果时只需要按扫描顺序输出，刚好没碰到表里存的非法日期值，所以能正常返回结果。
• 当你在外层加了ff.cc < getdate()的过滤条件后，优化器为了提升查询性能，会把convert(datetime, my_col,131)的转换逻辑提前到基表扫描阶段执行，不会严格按照你写的书写顺序先筛非空、再转换、最后比较。这时候转换会扫到表中所有行，只要碰到my_col非空但不符合Hijri回历格式、或者转换后公历日期超出datetime类型支持范围（1753-01-01到9999-12-31）的脏数据，就会抛出转换出界的242错误。
• 补充说明：my_col is not null只能过滤空值，完全没法识别非空但格式非法的字符串，所以单独跑子查询不报错只是执行计划带来的巧合，不代表你的转换逻辑对所有行都生效。

优先用从根源规避转换异常的方案，不要依赖执行计划的偶然行为：

• 推荐方案：用TRY_CONVERT替换CONVERT（支持SQL Server 2012及以上版本）
  TRY_CONVERT是SQL Server专门提供的安全转换函数，遇到转换失败的值不会直接抛错，会返回NULL，不管优化器怎么调整执行顺序都不会触发异常，最后只需要过滤掉转换为NULL的非法行即可：

  SELECT * 
  FROM (
      SELECT TRY_CONVERT(datetime, my_col, 131) AS cc 
      FROM my_table
      WHERE my_col IS NOT NULL
  ) ff 
  WHERE ff.cc < GETDATE() AND ff.cc IS NOT NULL;
  

• 低版本兼容方案（适配SQL Server 2008及更早没有TRY_CONVERT的环境）
  用CASE表达式包裹转换逻辑，SQL Server会严格保证CASE逐行按顺序判断执行，不会被优化器随意重排顺序，可以先做基础格式校验再执行转换：

  SELECT * 
  FROM (
      SELECT 
          CASE 
              -- 如果ISDATE对回历格式识别不准，可以替换成自定义LIKE规则匹配实际存储的日期格式
              WHEN ISDATE(my_col) = 1 THEN CONVERT(datetime, my_col, 131)
              ELSE NULL
          END AS cc 
          FROM my_table
          WHERE my_col IS NOT NULL
  ) ff 
  WHERE ff.cc < GETDATE() AND ff.cc IS NOT NULL;
  

• 临时规避方案（不推荐长期使用）
  如果你暂时不想修改转换逻辑，可以把内层子查询的结果先插入临时表物化，再做外层比较，强制SQL Server先完成内层转换再执行过滤，但这种方式性能不如前两种，且属于绕开优化器的取巧行为，稳定性差。

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