列式查询并发增加后，先守住哪条线
混合检索把过滤、向量计算和聚合放在同一条查询路径上，问题通常不在某个算子“慢”，而在并发下内存、CPU 和排队相互放大。治理的第一步是测出业务查询的资源画像，再决定准入与降级方式。
容量估算要基于实测
可以把单查询的常驻内存、峰值内存、扫描行数和执行时间记录下来，并按查询模板与参数范围分组。并发预算不是简单把单查询峰值相加：还要留出 Merge、缓存、网络以及其他租户的余量。不同版本、表设计和索引类型的结果不可直接套用。
三层控制分别处理不同问题
入口层限制单租户并发、排队时间和请求体大小，避免突发流量直接冲进集群。引擎层为查询设置合理的内存、执行时间和扫描量边界；边界应从压测与线上观测得到，而非照搬示例。业务层准备可接受的降级，例如缩短时间范围、降低返回条数、改为异步任务或只返回结构化过滤结果。
不要把“降低向量精度”当作通用开关。若使用近似检索，召回率和延迟的取舍应由离线基准与样本复核支持，并明确告知调用方结果语义。
验证方式
在与生产结构相近的环境里，分别压测正常请求、热点模板、宽时间范围和队列堆积。观察内存峰值、拒绝率、取消原因、排队时间，以及其他查询的尾延迟。把这些数据写成发布门槛，并保留按模板关闭新检索路径的开关。
并发治理的目标不是压住所有峰值，而是在资源不足时让系统按可预期的方式拒绝或降级。
