Polars中始终设置join_nulls=True进行连接会遇到哪些问题？

一、始终设置join_nulls=True会遇到的问题 #

• 结果集冗余爆炸：空值在数据中通常代表缺失信息，而非有意义的匹配键。开启该参数后，两个表中所有连接键为空的记录会互相匹配——比如左表有1000条空值记录，右表也有1000条，连接后会生成100万条无意义的关联数据，直接占用大量内存，甚至导致任务失败。
• 业务逻辑错误：绝大多数场景下，空值不应该被视为“相等”的匹配条件。比如用户ID为空的两条记录，本质是未知用户，强行关联会生成错误的业务结论（比如把两个不同的未知用户当成同一个）。
• 性能额外损耗：Polars默认不处理空值连接是经过性能优化的逻辑，开启join_nulls=True后，引擎需要额外处理大量空值的匹配计算，在大表场景下会显著拖慢连接速度。

二、为何不建议基于空值进行连接 #

核心原因是空值的语义特性：

• 按照SQL标准及主流数据工具的设计，NULL不等于任何值（包括自身），它代表“未知”或“缺失”，而非一个确定的取值。把未知值视为可匹配的键，完全违背了数据的语义定义。
• 空值匹配的结果不可控：数据中空值的数量往往难以预测，一旦开启空值连接，结果行数可能远超预期，后续排查问题、验证结果的成本极高，且这种匹配几乎没有业务价值。

三、显式调用drop_nulls vs 依赖join隐式过滤 #

更推荐显式调用drop_nulls，原因如下：

• 逻辑更清晰：提前通过df.drop_nulls(subset=["连接键列"])过滤连接键为空的记录，能让代码逻辑一目了然，后续维护者能直接理解你对空值的处理策略，避免误解。
• 避免意外风险：依赖join默认的空值不匹配逻辑，可能因后续参数修改、版本变动（虽然概率低）导致逻辑偏离预期；显式过滤则把空值处理逻辑固化，可靠性更高。
• 灵活性更强：drop_nulls可以指定仅过滤连接键的空值，保留其他列的空值，更贴合业务需求；而join的隐式过滤只是在连接时不匹配空值，不会移除原表中的空值记录（比如左连接时左表的空值行会保留在结果中），如果需要彻底清除这些无意义记录，显式操作更直接。

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