从 3 BE 扩容到 5 BE 后，带 ORDER BY LIMIT 的点查慢查询从正常（毫秒级）变为 2-8 秒，开盘高并发时更严重。CPU 和内存使用率都不高。
环境信息：
Doris 版本：doris-3.0.8-rc01-09b0cc49a6
集群：5 FE + 5 BE（从 3 BE 扩容而来，balance 已完成）
问题出现时间：扩容后持续存在
关键 Profile（query_id: cf344a53a6da4306-801458a579ed6d0a）：
Total: 2sec 13ms
Plan Time: 2ms
Schedule Time: 14ms
Wait and Fetch Result Time: 1sec 996ms
RESULT_SINK_OPERATOR:
ExecTime: 1sec 988ms
FetchRowIdTime: 1sec 988ms ← 99%的时间在这里
InputRows: 481
OLAP_SCAN_OPERATOR（3个BE合计）:
ExecTime: avg 3.370ms, max 5.504ms
RowsProduced: 3252
RowsRead: 3252
Physical Plan: PhysicalDeferMaterializeResultSink → PhysicalDeferMaterializeTopN
Total Instances Num: 73
Parallel Fragment Exec Instance Num: 24
Instances Num Per BE: be-0:24, be-1:24, be-4:25
Fragment 0 (ResultSink) 执行在 be-4 上
数据 tablet 分布在 be-0, be-1, be-4
SQL：
select symbol, trading_session_type, exchange_id, open, close, low, high,
change, volume, quote_volume, trades, kline_type, time, end_time
from tb_quote_kline_302_1m
where exchange_id = 302 and trading_session_type in(4)
and symbol = 'RAM' and kline_type = '1m'
and time between '2026-07-24 00:00:00' and '2026-08-04 23:59:59.044'
and end_time is not null
order by time desc limit 481;
题总结：
DeferMaterialize 的 FetchRowIdTime 占了 99% 的查询时间（1.988s），实际 scan 只需 3-5ms
3 BE 时正常，扩到 5 BE 后出现
怀疑 FetchRowId 跨节点回读在 5 BE 场景下存在性能问题
同时存在高并发时 LIMIT_REACH 报错
想确认：
DeferMaterialize ResultSink 的 FetchRowId 是否走跨节点 RPC？3 BE → 5 BE 后路径变化是否导致性能退化？
关闭 enable_defer_materialize_result_sink 是否是正确的规避方案？
parallel_fragment_exec_instance_num=24 对只有 3 个 tablet 的查询是否过高？
FetchRowId 的回读请求在 BE 端走的是哪个线程池？是否和 fragment 执行共用？高并发下是否存在排队？
