我会先确认影响范围，同时控制故障继续放大。从 OLAP 执行模型、线程、内存、IO 与后台合并解释 ClickHouse 并发边界。

止损之后，我会按请求链路建立证据，而不是凭经验猜。沿着「请求进入查询队列 → 分配线程与内存 → 并行扫描和聚合 → 争用磁盘/CPU/网络 → 限流或溢写后完成」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 请求进入查询队列 单个查询会使用多个线程和较大内存，几十个复杂查询可能放大为数百执行线程。 分配线程与内存 并发查询共享 CPU、page cache、磁盘和网络，资源达到饱和后尾延迟非线性上升。 system.processes：运行查询资源。 system.querylog：峰值内存与排队。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

定位时我最关注这些参数、指标和容量关系。ClickHouse 不是“不能并发”，而是不擅长让大量资源密集型 OLAP 查询同时无约束运行。它通过多线程并行加速单条查询，因此单查询性能很强，但高并行度会放大多查询之间的资源竞争。 并发能力必须结合查询重量描述。几百个只读少量数据的查询与几十个扫描数十亿行的聚合，压力完全不同。

找到根因后先做最小修复，再用同样的流量验证。每个看板触发十余个重聚合查询，上午整点同时刷新，磁盘和 CPU 饱和。把低优先级探索查询限流、缓存共享结果并对核心看板预聚合后，资源隔离才生效。 只限制单查询内存忽略并发总量：运行/排队查询数：按 workload 配额。 merge 与查询争用磁盘未隔离：总内存与查询峰值：客户端超时同步取消。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「running queries」为主基线，记录值应满足「记录稳态基线」；同时保存 运行/排队查询数、总内存与查询峰值，使后续变化能够回到同一时间轴比较。

恢复阶段要逐步放量，最后把监控和边界补齐。方案：更适合的场景：主要收益：代价与边界。 全局并发限制：实例资源统一保护：配置简单：无法区分业务优先级。 按用户/工作负载配额：多租户和核心/离线混部：隔离清晰：配额设计与动态调整复杂。 预聚合+结果缓存：重复查询比例高：减少根本计算量：数据新鲜度与失效治理。 选型至少带上 日增量、分区规模、查询并发、扫描行数和压缩比，并用上面的量化基线验证；未知数据应明确为待测假设。