生产全量实测(113 万患者 / 54.8 万命中,同一台 RDS,相邻两轮):
  串行(=1): 场景段 7,200,096ms(2h00m)  整轮 8,654,105ms(2h24m)
  并发(=4): 场景段 3,115,928ms(51m56s) 整轮 4,806,869ms(1h20m)
  → 场景段 ×2.31,整轮 ×1.80,省 64 分钟
先在生产一个 39,148 患者的诊所交替标定(×2.18),再由全量复现(×2.31)。

🔴 推翻原有的「⛔ 别指望靠这个旋钮提速」结论 —— 它让生产一年多没开这根杠杆。
原依据是「并发3=24.1分 vs 串行23.3分」,两处都错:
① 3% 差距落在 ±25% 的环境噪音里(用「两边跑同一条 SQL」的对照组量过),那次比较
   什么也没证明;
② 机制归因也错:真瓶颈是**延迟**(逐次索引探查等 page,CPU 与磁盘都闲着)不是吞吐,
   所以并发 2 就超线性(生产 ×1.50 / 测试机 ×2.88)。若真是吞吐受限,墙钟应约等于
   各查询耗时之和;实测墙钟只有求和的 43%。

同时把「集合式重写是唯一出路」那段改成现状:并发已解决窗口问题,集合式转为可选。
.env.example 补文档,含「判据只能看阶段墙钟、不能看单条 sql=」的读数陷阱。

本提交只改注释与 .env.example,不改任何运行逻辑(生产开关已于 2026-08-30 09:16 生效)。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>