优化之前先把现状量下来,否则改完只能凭感觉说"快了"。

脚本同时产出两样,⛔ 缺一不可：
  · **耗时**：EXPLAIN ANALYZE 的 Execution Time,每档取 N 轮**最快值**
    ⚠️ ⛔ 不取平均 —— 本机跑着别的东西,实测同一条件 1388~2130ms 都出现过,
      平均值被噪声主导,最快值才稳定可比。
  · **结果快照**：24 格逐格的数,拼成一行可逐字比对
    🔴 只比耗时是不够的 —— 把 join 改掉、把标签预计算,最容易的失败是
      **悄悄少算一批人**,而那正是产品最不能接受的
      （矩阵那段注释里写着「主管一对数就觉得系统在骗他」）。

本地基线（15,884 plan 的诊所,与测试服 15,770 几乎同规模）：
  15884 →  958 ms  · 磁盘读 119,861 buffers
   2458 →  127 ms
     14 →   11 ms   ← 地板

⭐ 顺带印证了一件事：本地 `patient_facts` 只有 111 万行(测试服 1567 万,1/14),
  但同规模诊所耗时同一量级(958ms vs 1399ms)。⇒ **表大小不是主因,查询次数才是**
  —— 15,884 个 plan 摊出的三万多次随机查才是,这正是「标签落 plan_reasons」要消掉的东西。