docs(gap): 步 3 负面结果 —— 集合式在并发+内存受限下慢一倍,全口对照组(同一条SQL)慢7~12倍坐实是资源争抢

docs/design/gap-set-based-rewrite-plan.md

@@ -356,3 +356,48 @@ C/D 相邻,长时间后台负载对两者影响相近,不单边偏袒;若数字
 本地 extraction ×0.60)都在带缓存优势的情况下仍然更慢 —— 集合式的 CTE 物化是**固定开销**,
 结果集太小就摊不掉。绝对值都在 2 秒以内,对总墙钟无影响,不值得为它加"按规模切形态"的分叉
 (那会让单一真理源裂成两条路径,得不偿失)。
+
+### 🔴 测试机结果 · 步 3:集合式在**并发 + 内存受限**下大幅变慢
+
+A(legacy) vs B(setbased) 逐子场景 SQL 耗时(全量重算路径,`SUBSCENARIO_CONCURRENCY=4`):
+
+| 子场景 | A legacy | B setbased | |
+|---|---|---|---|
+| **ortho_no_consult**(全口,两轮同一条 SQL) | 38.2s | **443.8s** | ×11.6 慢 |
+| **perio_no_srp**(全口,两轮同一条 SQL) | 104.9s | **796.6s** | ×7.6 慢 |
+| missing_tooth | 241.8s | 978.7s | ×4.0 慢 |
+| endo_no_rct | 180.2s | 703.1s | ×3.9 慢 |
+| gum_alveolar_lesion | 20.5s | 86.5s | ×4.2 慢 |
+| jaw_cyst | 12.5s | 25.1s | ×2.0 慢 |
+| impacted_tooth | 148.9s | 176.8s | ×0.84 慢 |
+| hard_tissue_damage | 204.9s | 180.8s | ×1.13 快 |
+| caries_no_filling | 296.2s | 194.9s | ×1.52 快 |
+
+场景段合计:**670s → 1,334s(慢一倍)**。
+
+#### 决定性证据:两个全口子场景跑的是**逐字节相同的 SQL**
+
+`buildGapSetBased` 对 `rule.wholeMouth` 直接 `return null` → 回落 legacy。
+所以 ortho/perio 两轮的 SQL 一模一样,却慢了 7~12 倍 ——
+**慢的不是集合式 SQL 本身,是它把整台机器的资源抢光了,连没改的查询一起拖垮。**
+
+#### 机器状态(2026-08-30 02:41,B 轮刚跑完)
+
+```
+Mem: 14G total / 0G free        Swap: 15G total / 9G 已用
+vmstat wa = 76% / 67%           ← 全程 I/O 等待,机器在颠簸
+PG: shared_buffers=160MB(!)     work_mem 默认 4MB(场景查询单独抬到 256MB)
+pg_stat_database: temp_files=12,954  temp_bytes=187GB
+磁盘 94% 满
+```
+
+#### 归因
+
+集合式把 **I/O 密集的嵌套循环 + 索引探查**换成了**内存密集的哈希聚合 / 排序 / 反连接**。
+单条串行跑时内存够用 → 快(步 2 的数字);
+四条并发 × 每条多个哈希节点 × work_mem=256MB → 内存打穿 → 溢到本就 94% 满的磁盘 → 全线拖垮。
+
+**这不是"集合式写错了"(11/11 零差异已证口径正确),是形态与机器资源画像不匹配。**
+
+⛔ **纠正步 2 的读法**:步 2 是**串行单条**跑的,所以它测出的"集合式更快"只在串行下成立;
+生产/测试跑的是**并发 4**。拿串行数字给并发场景下结论,就是这次差点犯的错。