只读:每条子场景 SQL 外套 count(*),不写库。判据用**墙钟**,不看各查询耗时之和
(并发下单条会被争抢拉长,和不可比 —— 这正是 2026-08-29 那次误判的成因之一)。

背景:代码注释里「⛔ 别指望靠并发提速」的依据是「并发3=24.1分 vs 串行23.3分」,
3% 的差距落在 ±25% 的环境噪音里,什么也没证明,却成了生产不开并发的理由。
今晚测试机 C 轮(legacy,并发4)各子场景耗时之和 1,736s 而场景段墙钟仅 794s
—— 墙钟远小于求和 = 并发确实在重叠,与「瓶颈是共享I/O、并行无用」的旧归因矛盾。

本地(30K,8000 患者子集,两对交替):
  conc=4  4.8s / 5.2s
  conc=1 10.5s / 10.0s     → 稳定 ×2.0,可复现

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