【Doris 使用环境】 生产上线
【Doris 版本】 3.0.6 ，三台FE、三台BE
【问题描述】
集群中ahdoc查询和线上服务的查询混用该集群，hadoc查询有时会占用大量资源，开启了Workload Group,只做了scan_thread_num个数限制
按照上述给线上查询配置新Workload Group 组后，在查询不是分区的明细模型表时基本不受影响，但是查询分区的明细模型表时就出现延迟特别高，还是想请问一下，对be服务做资源隔离时scan这块出了线程个数还有其他的资源可以限制的嘛，麻烦各位大佬给一下解决思路，感谢～
具体表现：
【操作系统】CentOS Linux release 7.5.1804
【机器配置】包括： 40核 ，256G 磁盘 8*500G
【集群相关监控和日志】
1.查询的建表语句，该每日大约1亿条
普通明细表
DUPLICATE KEY(`uid`, `is_d_user`, `is_fenqi_miniprogram`, `is_operable_user`, `inoperable_reason`, `register_user_segment`)
DISTRIBUTED BY HASH(`uid`) BUCKETS 4
分区明显表
DUPLICATE KEY(`uid`, `is_d_user`, `is_fenqi_miniprogram`, `is_operable_user`, `inoperable_reason`, `register_user_segment`)
PARTITION BY RANGE(`etl_dt`)()
DISTRIBUTED BY HASH(`uid`) BUCKETS 4
线上查询语句
SELECT uid,is_d_user,is_fenqi_miniprogram,is_operable_user,inoperable_reason,etl_dt FROM user_tag_i_d WHERE (uid = 15631435349592 AND etl_dt IN ('2026-05-13','2026-05-12')) ORDER BY etl_dt DESC limit 1
当出现延迟时BE节点会出现大量的scan,查看监控指标时 scan的线程数没有大满
BE的日志（开始和执行中间没有显示中间其他事情）
I20260514 14:30:08.649009 52942 fragment_mgr.cpp:703] query_id: 2d4afc6dbe2b4047-8099148f05a1bde0, coord_addr: TNetworkAddress(hostname=10.11.39.166, port=9020), total fragment num on current host: 20, fe process uuid: 1757066418378, query type: SELECT, report audit fe:TNetworkAddress(hostname=10.11.39.166, port=9020), use wg:TG[id = 1757070410188, name = wg_online, cpu_share = 512, memory_limit = 90.59 GB, enable_memory_overcommit = true, version = 4, cpu_hard_limit = -1, scan_thread_num = 60, max_remote_scan_thread_num = 512, min_remote_scan_thread_num = 8, spill_low_watermark=50, spill_high_watermark=80, is_shutdown=false, query_num=13, read_bytes_per_second=-1, remote_read_bytes_per_second=-1]
I20260514 14:30:08.671181 52965 fragment_mgr.cpp:634] Query 2d4afc6dbe2b4047-8099148f05a1bde0 start execution
I20260514 14:30:18.646327 141975 runtime_query_statistics_mgr.cpp:283] register x profile done 2d4afc6dbe2b4047-8099148f05a1bde0, fragment 0, profiles 5
I20260514 14:30:18.646428 141975 query_context.cpp:200] Query 2d4afc6dbe2b4047-8099148f05a1bde0 deconstructed, mem_tracker: deregister query/load memory tracker, queryId=2d4afc6dbe2b4047-8099148f05a1bde0, Limit=2.00 GB, CurrUsed=192.00 B, PeakUsed=192.00 B
I20260514 14:30:18.653007 52690 runtime_query_statistics_mgr.cpp:335] Send 2d4afc6dbe2b4047-8099148f05a1bde0 profile succeed
