Kusto自定义函数如何动态处理where子句的null可选参数

最优实现逻辑 #

直接在where子句中使用逻辑或短路判断实现，这是Kusto官方推荐的写法，查询优化器可以自动识别这种模式做谓词下推优化，性能和硬编码固定过滤条件几乎无差异，不需要在调用侧动态拼接KQL语句，也不会出现全表扫描的性能问题。
核心判断规则：

• 先判断传入的可选参数是否为null/空值，如果是，当前判断分支直接返回true，逻辑或不会执行后续列匹配逻辑，等价于不添加该过滤条件
• 如果参数存在有效值，空值判断分支返回false，自动执行后续列的匹配过滤逻辑

函数实现示例 #

对应你需要的单可选参数场景，函数定义如下：

// 定义自定义函数，可选参数设置默认空值，兼容不传参的调用场景
.create function Calculate(
    test:string = ""
) {
    T
    | where (isempty(test) or 对应过滤列名 == test)
    | order by timestamp desc
}

如果需要扩展多个可选过滤参数，直接按相同规则追加判断条件即可，示例如下：

.create function Calculate(
    test:string = "",
    logLevel:int = int(null),
    startTs:datetime = datetime(null)
) {
    T
    | where 
        (isempty(test) or 对应测试列名 == test)
        and (isnull(logLevel) or Level列名 == logLevel)
        and (isnull(startTs) or timestamp >= startTs)
    | order by timestamp desc
}

C#调用注意事项 #

• 直接使用官方Kusto.Data客户端调用即可，不要在C#侧动态拼接KQL字符串，所有参数通过KustoParameter传入，避免注入风险
• 不需要启用过滤的参数直接传C# null即可，客户端会自动映射为Kusto的null值，自动触发跳过过滤的逻辑
• 不要用case()/iif()函数包裹过滤逻辑，这类写法Kusto优化器无法做谓词下推，会导致全表扫描，性能差距可达数倍到数十倍

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