SQL Server UNION查询单独正常但联合时报Msg 537错误

这个错误本质上是传给LEFT或SUBSTRING函数的长度参数无效（比如负数、零，或者超过目标字段的实际长度），你说单独执行每个子查询都正常，突然报错，大概率是数据层面新增/修改了符合以下情况的行：

先定位问题根源 #

虽然单独子查询没报错，但很可能是执行计划的差异导致单独执行时没扫到坏数据（比如用了索引覆盖、TOP限制，或者统计信息没更新），而UNION因为要做去重、排序，会触发全表扫描或者不同的执行逻辑，从而碰到了问题行。

你可以按以下步骤排查：

• 先把每个子查询中用到LEFT()或SUBSTRING()的地方找出来，重点看那些长度参数是动态计算的表达式（比如基于其他字段的长度、数值运算）。比如：

  -- 这种动态计算长度的写法很容易踩坑
  LEFT(ProductName, LEN(CategoryCode) - 3)
  SUBSTRING(LogContent, 5, CHARINDEX('|', LogContent) - 5)
  

• 针对每个可疑的表达式，在对应的表中查询是否存在导致长度参数≤0的行：
  比如上面第一个例子，你可以跑这条SQL找问题数据：

  SELECT CategoryCode, LEN(CategoryCode)
  FROM YourProductTable
  WHERE LEN(CategoryCode) - 3 <= 0
  

  这样就能精准定位到那些让长度参数失效的脏数据。

修复方案 #

找到问题后，有两种解决思路：

1. 修正数据：如果这些脏数据是业务上不应该存在的，直接更新或删除它们（比如把过短的CategoryCode补全）。
2. 优化查询逻辑：在函数里增加安全判断，确保长度参数始终有效。比如：

   -- 用GREATEST确保长度至少为1（返回空字符串的话可以用0）
   LEFT(ProductName, GREATEST(LEN(CategoryCode) - 3, 1))
   -- 或者用CASE处理边界情况
   SUBSTRING(LogContent, 5, CASE WHEN CHARINDEX('|', LogContent) >5 THEN CHARINDEX('|', LogContent)-5 ELSE 0 END)
   

补充说明 #

为什么单独子查询没问题？因为SQL Server的执行计划可能会根据数据分布、索引情况选择不同的扫描方式，单独执行时可能刚好跳过了那条坏数据，但UNION操作需要合并所有结果集并去重，会强制扫描更多数据，所以才触发了错误。

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