WITH子查询取表数据与手动定义数据查询结果不一致问题排查

• NULL/空字符串不一致：如果tbl1的字段包含NULL值，但你手动构造数据时用了空字符串（''），或者反过来，后续查询的过滤/关联逻辑会因为NULL = 任意值结果为UNKNOWN而排除所有行，而空字符串能正常匹配。比如tbl1的value1是NULL，手动写成''，当后续用something.value1 = t.col1时，NULL的情况全不匹配，空字符串则可能匹配成功。

• 数据类型隐性不匹配：tbl1的字段类型和手动构造的数据类型存在差异。比如tbl1的value2是DECIMAL(10,2)，你手动写的是整数100（被识别为INT类型），部分数据库在类型转换时会导致值的匹配逻辑异常，或者索引失效，最终过滤掉所有行。

• 字符集/排序规则差异：字符串字段的字符集或排序规则不一致。比如tbl1的value3是'Apple'（排序规则区分大小写），你手动写成'apple'，后续查询的字符串比较会因大小写敏感而不匹配；或者全角/半角字符、不同字符集的特殊字符，看起来相同但编码不同，导致匹配失败。

• 优化器的谓词下推差异：部分数据库（如Oracle、MySQL）对WITH子查询的优化逻辑和手动UNION ALL构造的临时数据集不同。WITH子查询可能被视为可优化的视图，优化器会把后续SELECT的过滤条件提前推到WITH子查询中执行，如果tbl1的索引统计信息过时，优化器可能误判所有行都不满足条件，导致返回0行；而手动UNION ALL的数据集不会被谓词下推，能保留全部14条数据。

• 行级权限或数据实时变更：运行WITH子查询时，tbl1可能因其他事务的修改（如临时删除后又恢复）导致实际返回行数为0，或者你没有tbl1的完整行级权限，部分数据被隐性过滤，而你误以为tbl1始终有14条数据；手动构造的数据不受这些因素影响。

• 窗口函数/聚合逻辑的执行顺序差异：如果后续查询使用了窗口函数（如ROW_NUMBER()）或聚合函数，WITH子查询的排序逻辑和手动UNION ALL临时表的排序逻辑不同，可能导致窗口函数生成的结果不符合过滤条件，最终返回0行。

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