【摘要】
追溯这件事，客户在合同里写的是一句话——"能从成品查到原材料"。真正落地时，这句话背后是十几层加工、两三次拆合批、若干次换载具、还有一堆离线设备的手工记录。
断链几乎不是技术问题，是建模问题：大多数项目的追溯表在需求阶段就被设计成了一张宽表（批号、父批号、工单号），上线三个月后遇到第一次拆批，链就断了，而且断得无声无息——查的时候才发现少了三层。
这篇讲断链的四个源头、父子关系表该长什么样、片级和批级怎么选、以及唯一一个能自动抓到断链的校验方法。
【核心要点】
- 追溯用节点+边建模，不用宽表；一条关系一行，关系类型必须显式记录
- 断链四个源头：拆合批未建父子、换载具不记片、返工当新批、离线站补录缺失
- 片级追溯比批级贵一个量级，但 300mm 前段没有选择余地；200mm 和后段可以批级 + 载具级
- 数量守恒校验是唯一能自动发现断链的手段，日跑一次，出断链清单交数据治理岗
- 十层递归不要在主库实时查，做闭包表预计算或异步导出
- 保留期按行业定：消费类 2 年，车规 5 年，医疗 10 年
---
一、断链的四个源头
上线后追溯查不通，九成落在这四类：
| 断链源头 | 现场怎么发生的 | 检测信号 |
|---|---|---|
| 拆合批未建父子 | 操作员在 MES 手动拆批，新批号生成了，但没人录父批；合批只留主批号，被合掉的批"消失" | 良率 >100% 或 <0；同批数量前后不一致 |
| 换载具不记片 | 片从 A 号 FOUP 倒到 B 号 FOUP，系统只更新了载具字段，没留事件 | 同一个 Wafer ID 出现在两条不同批的链上 |
| 返工/重跑当新批 | Rework 建新批，原批与新批之间没有关系 | 反查层数明显偏少，通常少于 5 层 |
| 离线站补录缺失 | 量测机、手工装配站、外协工序靠纸质单据，晚一天录或干脆不录 | 某批在两工序之间"跳跃"，中间无记录 |
四类里最致命的是第一类。因为拆合批是结构性的，一旦父子关系缺失，后面所有层都挂不上，而现场往往三个月才盘点一次追溯完整性。
处置办法不复杂：把拆批、合批、返工、换载具做成系统的标准事务，操作员不能"自己填个新批号"，只能走系统动作。系统事务天然带父子关系，人手工填的表单不会。
二、数据模型：一条关系一行
最小可用的关系表就这些字段：
| 字段 | 说明 |
|---|---|
| child_lot | 子批（下游批号） |
| parent_lot | 父批（上游批号，合批时多行） |
| relation_type | split / merge / rework / recassette / consume |
| op_no + step | 发生关系的工序 |
| equipment_id | 发生关系的设备（拆批在哪个站做的） |
| event_time | 事件时间（不是录入时间，两个都要存） |
| qty_in / qty_out | 数量（片数或批数，口径固定一个） |
| operator | 操作人 / 系统账号 |
两个容易漏的点：一是 event_time 和录入时间必须都存，补录数据的可信度全靠这两个时间差来判断；二是 relation_type 不能省，没有类型就只能靠猜，而拆批和换载具在链上的语义完全不同——前者改变批的边界，后者不改变。
再建一张闭包表 lot_path(ancestor, descendant, depth)，写关系时同步维护。查询"这批成品用了哪些原材料"就变成一次索引扫描，深度十层也不慢。
三、片级还是批级：先算清代价
| 维度 | 批级 | 片级 |
|---|---|---|
| 存储量 | 1 行 / 事件 | 25 行 / 事件（300mm 单批 25 片） |
| 客诉定位 | 只能定到批 → 整批报废 | 定到片，可能只废 3 片 |
| 良率分析 | 无法做 wafer map 空间关联 | 可做 spatial pattern 与机台/腔体关联 |
| 适合 | 200mm、后段封装、辅料包材 | 300mm 前段、先进封装、车规 |
选型不看技术偏好，看一片错杀的成本。300mm 前段一批报废的代价，通常几天就抵掉片级追溯多出来的存储和开发成本；反过来，辅料和包材做到片级纯属浪费。
一个折中做法：主线片级、辅料批级。片级只管 Wafer ID → die 坐标 → 成品批这一段，辅料（光刻胶、化学品）按批次和开封时间挂到工序上，不追到每片。
四、数量守恒：唯一能自动发现断链的校验
断链本身不会报错，系统只会安静地少一条记录。能让它自己暴露的，只有一个约束：
Σ qty_out(child) = qty_in(parent) （对每个 relation 事件）差异不为零就是断链或错录。每天凌晨跑一次全链校验，输出三张清单：数量不守恒的批、反查层数少于 5 层的成品批、event_time 与录入时间差超 24 小时的事件。
这三张清单不要发给产线，发给数据治理岗或 MES 管理员。发给产线的结果是所有人都说"不是我录的"，然后清单没人看。治理岗的 KPI 是每周清单条数下降，这个指标比"追溯功能已上线"有意义的得多。
五、查询性能与保留策略
反查十层，MySQL 5.7 上用手写递归或应用层循环，几千批就会超时。三种做法按成本排序：
- 闭包表预计算（首选）：写时维护路径，读时一次查询；
- 异步导出：客诉追溯是低频高价值场景，允许等 30 秒，做成任务队列 + 报告下载；
- 列存/数仓：追溯数据量到亿级后，主库只留近 6 个月，历史进数仓。
保留期别照抄模板，按行业定：消费电子 2 年、车规 5 年、医疗 10 年。保留策略要在设计阶段写进合同，事后扩容的代价是重做归档。
六、可复用点
- 节点+边建模，一条关系一行；relation_type、event_time、录入时间三件套不能省。
- 拆批/合批/返工/换载具做成系统标准事务，禁止人工填新批号。
- 主线片级、辅料批级；选型看一片错杀的成本，不看技术偏好。
- 数量守恒校验日跑，清单交数据治理岗，KPI 是清单条数下降。
- 闭包表预计算路径，实时递归查询不上主库。
- 保留期按行业定并写进合同，别等客诉来了才扩容。
下一篇是卷3 最后一篇：报表与看板——先定指标口径，再写一行代码。CIM 项目最终被评价好坏的场合，往往就是一块屏。
判断口诀：追溯链不会因为你画了图就连上，只会因为你每一步都记了一行关系才连上。