ClickHouse 物化视图刷新/口径回填与在线交互查询共享同一集群：靠 settings.priority 错峰真的够吗？你们用什么机制给重算任务「限速」而不拖垮看板的 P99？

背景

我做了 15 年数据管道，目前维护一个 ClickHouse 集群（2 shard × 2 replica，单机 64C/256G），上面同时跑两类负载：

1. 在线交互查询：运营看板 + 自助 SQL，QPS 不高（峰值约 80 QPS），但 P99 SLO 是 3s，超时业务方就会来投诉；
2. MV 刷新 + 口径回填重算：几十个物化视图（Refreshable MV，REFRESH EVERY 5 MINUTE）+ 不定期的大表回填（单批扫 5 亿行做重算，单次跑 20 分钟到 2 小时不等）。

现象

这两类负载落在同一批 shard 上时，冲突非常具体：

• 一次口径变更回填（INSERT INTO SELECT 重算 28 天分区）跑起来后，看板聚合查询 P99 从 400ms 直接飙到 25s，不是 OOM、不是锁等待，就是 CPU + 磁盘 IO 被吃满——system.processes 里回填查询占 60 个线程中的 56 个；
• 更隐蔽的是 Refreshable MV 的定时刷新：几十个 MV 的刷新窗口如果撞在一起（比如都在整 5 分钟触发），会叠成一次"中等规模的全表重扫"，看板 P99 抖 3~5 分钟。我按创建时间错开过触发点，缓解了，但没有根治——因为重算耗时本身会漂移。

已尝试的排查与结果

1. settings.priority 区分两类查询：交互查询 priority=1，回填/MV 刷新 priority=10。结果：只影响 max_concurrent_queries 被占满时的排队顺序，不影响已经在跑的查询的 CPU 分配——回填跑着的时候，priority 高的交互查询照样慢。也就是说 priority 解决的是"排队权"，不是"资源配额"。
2. 错峰调度：回填统一排到凌晨低峰（2:00-6:00），Refreshable MV 的刷新窗口按 137ms 步长错开。效果：白天 P99 稳了，但凌晨窗口只有 4 小时，回填排期开始排队，而且一旦某个 MV 刷新耗时漂移进下一个刷新窗口，错峰就失效。
3. 拆集群：评估过给重算单独起一套 shard 组（读同一份对象存储上的 part），但写入侧要双写、口径对账成本上升，团队目前倾向不动集群拓扑。

想请教的具体问题

1. Refreshable MV 的刷新调度：除了错开 REFRESH EVERY 的触发点，你们有没有更硬的机制？比如给 MV 刷新的查询单独设 max_threads / max_memory_usage（通过 SETTINGS 子句或 user 级默认值），把"单次刷新最多吃多少 CPU/内存"钉死？阈值你们怎么定的？
2. 回填重算的限速：INSERT INTO SELECT 除了 max_threads，你们还压哪些参数（max_memory_usage、max_block_size、max_execution_time 兜底）？有没有按"分区分批 + 每批之间 sleep"的自调度脚本？批与批之间怎么判断"集群闲下来了"再发下一批——是靠 system.metrics 的 ActiveQueries/QueriesInFlight，还是直接看节点 load？
3. 观测口径：怎么把"看板 P99 抖动"归因到"某个 MV 刷新/回填"上？你们是在查询侧打来源标签（settings 里塞业务标记），还是靠 system.query_log 的 query_id 前缀 + 时间窗口对齐？有没有踩过"归因归到 MV 刷新、实际是并发回填"这种误判？
4. 一个取舍问题：如果只能选一个——"重算慢一点但看板永远稳"（严格限速，回填窗口拉长）还是"重算快一点但允许看板 P99 偶发抖动"（宽松限速，SLO 允许月度 99% 达标）——你们的线上策略是哪个？依据是什么（业务投诉成本 vs 回填排期成本）？

期望得到的回答形态：带具体 settings 参数与阈值的实践（max_threads 给多少、max_memory_usage 怎么算、错峰步长怎么定），以及至少一条"我试过 A 不行、换 B 才行"的取舍记录。纯原理推导也可以，但请带上你们集群的规模与查询量级，方便对号入座。