按诊所补摄的三步里,前两步(cold-import / recompute-persona)都能用 --clinics 收窄, 只有 plans 是全量:每批 patientsHit 26-29 万、耗时 1h50m,其中约 1h43m 花在 selectHits 全表扫。今晚四批补摄,plans 一项就吃掉约 7 小时,而 90%+ 的扫描结果是 unchanged。 本次给 recompute-plans 加 --clinics=<orgId,...>,口径与 cold-import / recompute-persona 完全一致(patient_transactions.clinic_id 反查患者),把 selectHits 收窄到子集。 ⚠️ 关键点:收窄命中集**必须同步收窄关闭步骤**。runAllForHost 第 3 步会扫全租户的 active+assigned,凡患者不在本轮命中集就判定"信号消失"关掉,挂在客服名下的还各记一条 auto_release。只收窄 selectHits 不收窄关闭 = 一条命令清空整个召回池。故 runAllForHost 新增 patientIds 入参时,两处一起收窄;关闭侧用内存 Set 过滤而非 SQL in(),避开 PG 32767 bind 上限(子集动辄数万)。 ⚠️ SQL 形式踩坑:子集过滤写 `IN (SELECT … unnest(array))` 而非 `= ANY(array)`。 结果等价但代价差一个数量级 —— 后者让规划器转去嵌套循环,而本 SQL 带 gap lateral join 每行代价很高。本地实测(30000 患者库 / 子集 5825 人 / 11 个子场景): = ANY(array) 53.6s ← 比全量 42.3s 还慢,perio_no_srp 一个就 35.5s IN (SELECT unnest()) 10.2s ← 命中数逐个相同,快 4.2 倍 细节写进 treatment-initiation-recall.scenario.ts 注释,改那行前先按同口径量一遍。 本地验证(jvs-dw 30000 患者 / 18591 active + 283 assigned): - 子集跑(5825 人):patientsHit 2552,plansClosed 0,duration 9.8s 范围外 active 16317 / assigned 278 —— 跑前跑后逐字相同,一条没动 (没有护栏的话这 16595 条会被全部关掉,plansClosed=0 就是护栏生效的证据) - 全量跑:patientsHit 19147,日志标 (全量),行为与改动前一致,无回归 - 重复跑幂等:第二次 created=0 superseded=0 closed=0 ⚠️ --clinics 只用于「补摄后立刻补计划」,**不能替代日常全量**:召回是时间驱动的, 数据一个字没变、沉默时长跨过阈值也该出计划,收窄就等于其余诊所当天不评估。 定时全量照跑,这个参数只省掉补摄后的那一次全扫。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
