FRIDAY 对接增量 push 报 `SocketTimeoutException: Read timed out`,今天在测试服
按他们的路径(公网域名 + HMAC)模拟推 2 行患者主档定位到:

  单次请求 74s,74s **全部**耗在这一条 SQL 上
  (逐 6s 采 pg_stat_activity,同一条查询年龄从 6s 一路涨到 74s):

    SELECT id, patient_id, tenant_id FROM patient_transactions
    WHERE sync_log_id = $1 AND patient_id IS NOT NULL

  来源 cold-import.service.ts `touchedRows`(push / cold-import / 增量共用这条路径)。
  EXPLAIN:Parallel Seq Scan (cost=0.00..2150645.78)

外键约束不会自动建索引,这句从上线起就在全表扫:
  测试服 patient_transactions 12,519,060 行 / 33 GB
  生产   同表           24,074,031 行 / 64 GB  ← 生产更慢,FRIDAY 真上生产会更糟

本地建索引后 plan 变 Index Scan(cost=0.29..4.31)。

── 顺带更正一处仓库里的错误注释 ──
20260701060607 那份迁移写着「CONCURRENTLY 不能跑在事务里,Prisma migrate 对整份
migration.sql 有事务包裹,故不能靠 migrate deploy 直接跑」。**当前 Prisma 6.19 已不成立** ——
本地实测 migrate deploy 直接把 CONCURRENTLY 跑通、索引建出、plan 生效。
新迁移里写清了真实情况,并保留「推荐手动先建」的建议,但理由改成正确的那个:
deploy 时 pac-service 要等 pac-migrate 退出才启动,33/64GB 建索引几分钟 = 白等的停机。

push 侧本身是好的:同一次模拟 accepted=2 / failed=0 / mappingMisses=0,
canonical 映射(externalId/name/gender/birthDate/medicalRecordNumber/phone)全对。

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