Firebird 2.5中LEFT JOIN查询WHERE子句存储过程传参NULL问题

这个现象确实是Firebird的正常行为，背后是查询执行逻辑和优化器的处理规则在起作用，具体原因可以拆解为两点：

1. WHERE条件会隐式转换LEFT JOIN为INNER JOIN #

你的原查询用了LEFT JOIN Product p，这意味着即使ProductSupplier里的记录找不到匹配的Product，p的所有列也会以NULL值返回。但当你在WHERE子句中加入p.IsStockFlag=1后，这个条件会自动过滤掉两类行：

• 没有匹配到Product的行（此时p的所有列都是NULL，NULL=1的结果是UNKNOWN，会被WHERE子句排除）
• 匹配到Product但IsStockFlag≠1的行

到这一步，你的LEFT JOIN实际上已经等同于INNER JOIN了——只有同时满足"ProductSupplier匹配到Product"和"p.IsStockFlag=1"的行，才会进入后续的子查询评估环节。

2. 关联子查询的执行顺序影响参数传递 #

Firebird的查询优化器在处理关联子查询时，可能会选择先执行子查询（调用ProductQtyBMUToUOM$），再应用WHERE子句的过滤条件。这就导致：

• 对于那些最终会被p.IsStockFlag=1过滤掉的行（比如p.IsStockFlag=0的行，或者p为NULL的行），存储过程仍然会被调用一次。
• 当p为NULL时，存储过程的参数p.Id和p.DefPurcUOMNr自然是NULL；如果你的Product表中存在Id或DefPurcUOMNr本身为NULL的异常记录（尽管主键通常不会为NULL，但不排除业务上的特殊情况），也会导致参数传入NULL。

验证与优化建议 #

• 你可以用EXPLAIN命令查看执行计划（比如EXPLAIN select ps.ProductId...），就能清楚看到优化器是先执行子查询还是先过滤条件。
• 如果你的存储过程无法处理NULL参数，可以在调用时用COALESCE给参数设置默认值，比如：

  select ps.ProductId, p.Id, p.DefPurcUOMNr, p.IsStockFlag 
  from ProductSupplier ps 
  inner join Product p on p.Id = ps.ProductId 
  where p.IsStockFlag=1 
    and (select q.Qty from ProductQtyBMUToUOM$(COALESCE(p.Id, 0), COALESCE(p.DefPurcUOMNr, 0), 1) as q) > 0
  

  （这里的0需要替换为存储过程能接受的合法默认值，或者根据你的业务逻辑调整）
• 既然p.IsStockFlag=1已经把LEFT JOIN转成了INNER JOIN，建议直接写成INNER JOIN，让查询意图更清晰，也可能帮助优化器生成更高效的执行计划。

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