Snowflake中current_date()日期过滤为何慢于to_char(current_date())？

运行时间差异的核心原因 #

你的两个查询性能差距的本质是是否触发了Snowflake的分区修剪（Partition Pruning）：

1. 第一个查询 dt = current_date() - 1 中，current_date()-1 返回的是 DATE 类型。如果你的 dt 字段是字符串类型（比如 YYYY-MM-DD 格式的文本），Snowflake会对表中每一行的 dt 做隐式类型转换（把字符串转成DATE）后再比较——这种操作会导致Snowflake无法利用分区键的索引，只能扫描大量分区（从你提供的执行剖析图能看到，查询1扫描的分区数远多于查询2），最终拖慢查询速度。
2. 第二个查询 dt = to_char(current_date() - 1) 中，to_char() 把DATE类型的结果转成了字符串，和 dt 字段的类型完全匹配。此时Snowflake可以直接基于分区键的字符串值做过滤，只扫描目标分区，因此执行时间大幅缩短。

Snowflake日期过滤的性能优化原则 #

• 严格匹配过滤条件的类型：确保过滤条件左右两边的类型和分区键的类型完全一致，避免隐式类型转换——这是触发分区修剪的前提。
• 避免对分区键做函数转换：如果分区键是字符串类型，不要写 to_date(dt) = current_date()-1 这类语句；同理，如果分区键是DATE类型，不要用字符串值去匹配。
• 优先使用预计算的常量值：可以提前计算好目标日期的字符串或DATE值，再带入查询，避免在过滤条件中嵌套复杂函数（虽然 current_date() 是简单函数，但类型不匹配依然会出问题）。
• 查看执行计划验证分区修剪：通过Snowsight的执行剖析工具，检查表扫描步骤的分区扫描数量——如果扫描分区数远少于总分区数，说明分区修剪生效；反之则需要检查过滤条件的写法。

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