调整Kusto默认工作负载组后仍触发旧maxmemoryconsumptionperiterator限制

以下是可能导致配置不生效的几个关键点及对应解决方法：

• 检查查询绑定的工作负载组
  部分客户端或工具会默认指定非default的工作负载组，比如通过连接字符串参数workload_group，或查询前的set workload_group=xxx;语句。可在查询开头执行show context;，确认当前生效的工作负载组是否为default。

• 验证集群级内存策略是否存在限制
  集群级的内存参数（如max_memory_consumption_per_query、max_total_memory_consumption_per_node）优先级高于工作负载组的单迭代器配置，可能会覆盖你设置的阈值。执行.show cluster policy memory查看当前集群内存策略，若存在更低的限制，需同步调整集群级配置。

• 优化summarize算子的内存使用
  高基数场景下的summarize操作容易触发内存溢出，即使调高迭代器内存限制也可能无效。可尝试：

  • 给summarize添加hint.strategy=shuffle，通过分片处理降低单节点内存压力
  • 启用hint.spark_partitioning=true（集群支持Spark兼容分区时）

• 确认配置全节点同步
  虽然.show workload_groups显示配置已更新，但部分节点可能存在缓存未刷新的情况。执行.show workload_groups with (details)查看各节点的配置同步状态，若存在不同步，可等待数分钟或重启查询节点（业务允许时）。

• 排查查询内存使用的实际情况
  用.show query_tracing或监控指标QueryMemoryConsumption查看查询的真实内存占用，确认报错中的旧阈值是否为缓存提示，还是实际内存占用确实触达了未生效的限制。

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