MES 生产执行系统数据模型怎么设计？核心表、状态历史与数据质量

数据模型设计的基础：从业务对象到实体关系

MES 的核心业务对象包括工单、物料、工序、设备、人员和质量检验。数据模型设计的第一步，是确定这些对象之间的实体关系，而不是直接开始建表。

工单（Work Order）是 MES 的驱动中心。一个工单包含多个工序（Operation），每个工序可能关联多台设备、多个质检批次和多个操作人员。物料在这个链条中表现为批次和序列号，设备则通过状态记录参与工序执行。

实体关系设计的关键约束有两个：

• **工单与工序是一对多**，工序之间通过顺序号和并行标志表示工艺路线。
• **工序与设备是多对多**，但实际执行时一个工序在同一时间只能绑定一台主设备，因此需要一张“工序执行记录”表来解耦。

实践中常见的一个错误是直接将工单、工序、设备三张表通过外键关联，导致每次查询都要做三层 JOIN，性能在日产量超过 5000 条记录时急剧下降。更好的做法是引入“执行实例”（Execution Instance）作为中间实体，将工单与工序的静态关系、工序与设备的动态绑定分开存储。

例如：工单 WO-2026-001 包含 3 道工序。系统为每一道工序生成一个执行实例 ID，每个实例记录开始时间、结束时间、操作人员、设备 ID 和质检结果。这样查询某个工单的完整执行历史时，只需要扫描执行实例表，而不需要反复关联工单和工序主表。

物料关联的处理原则类似。物料批次信息应该挂在执行实例上，而不是挂在工单上。因为同一工单在不同工序可能消耗不同批次，挂在工单上会导致数据冗余和更新冲突。

核心表结构：工单、工序、执行实例与物料消耗

基于上述实体关系，MES 的数据库核心表至少包含以下四张主表和两张关联表：

**工单主表（work_order）**：存储工单号、产品编码、计划数量、优先级、创建时间、截止时间、状态。状态字段建议使用 tinyint 枚举，而不是字符串，以减少存储和索引开销。常见状态包括：已创建、已下发、执行中、已暂停、已完成、已关闭。

**工序主表（operation）**：存储工序编号、工序名称、所属工单 ID、顺序号、标准工时、并行标志。工序主表是静态数据，一旦工单下发后不应修改，否则已生成的执行实例会与工序定义不一致。

**执行实例表（execution_instance）**：这是 MES 中最活跃的表。字段包括实例 ID、工单 ID、工序 ID、设备 ID、操作人员 ID、开始时间、结束时间、状态、产出良品数、产出不良品数、质检批次 ID。状态字段建议增加“准备中”“运行中”“已完成”“异常终止”四个状态。

**物料消耗表（material_consumption）**：记录每个执行实例消耗的物料批次和数量。字段包括实例 ID、物料编码、批次号、消耗数量、单位。注意：每个执行实例可能消耗多个物料批次，因此物料消耗表与执行实例是一对多关系。

**设备状态日志表（equipment_status_log）**：记录设备在某个时间点的状态变化，包括设备 ID、状态编码、开始时间、结束时间、操作人员。这张表不是执行实例的子表，而是独立记录设备全生命周期状态。

**质检结果表（qc_result）**：关联执行实例或物料批次，存储检验项目、检验值、判定结果、检验人员、检验时间。

这六张表构成了 MES 数据模型的主干。新增功能时，比如追溯、设备保养、人员考勤，应围绕这些核心表扩展，而不是重建。

状态历史记录：为什么不能只用状态字段

许多 MES 项目初期只在工单或执行实例表中放一个状态字段，每次更新直接覆盖。这种做法在数据量小的时候看不出问题，但一旦需要做追溯、分析或异常排查，就会陷入困境。

假设一个工单状态从“执行中”变为“已暂停”，操作员在 10 分钟后恢复为“执行中”，然后又变为“已完成”。如果只记录当前状态，系统无法回答“暂停了多长时间”“谁操作的暂停”“恢复时有没有异常”这类问题。

正确的做法是建立独立的状态历史表（status_history），记录每一次状态变更。字段包括：

• 对象类型（工单、执行实例、设备）
• 对象 ID
• 变更前状态
• 变更后状态
• 变更时间
• 操作人员 ID
• 变更原因（可选，但强烈建议）

这张表按对象 ID 和变更时间建立联合索引，查询某工单的状态演变只需一次索引扫描。

状态历史表的数据量增长很快。一条工单在生产过程中可能经历 10 到 20 次状态变化，一个工厂每天 500 个工单，一年就是 180 万条记录。因此，状态历史表需要定期归档，比如按季度分区，或者将超过 6 个月的数据迁移到历史库。

归档策略取决于查询频率。如果企业经常需要回溯一年前的工单状态，建议使用数据库分区功能，按月份分区，删除旧分区时直接 drop 而不是 delete，避免产生大量日志。

索引策略：查询性能与写入开销的平衡

MES 系统对实时性要求高，但写入频率也高。工单下发、状态变更、物料消耗、质检结果录入，每秒可能产生数十条写入。索引设计不当，写入性能会迅速恶化。

核心原则是：**索引服务于最频繁的查询模式，而不是所有可能的查询**。

MES 中最频繁的查询模式包括：

• 按工单号查询执行实例：在 execution_instance 表的 work_order_id 上建索引。
• 按时间范围查询执行实例：在 execution_instance 表的 start_time 上建索引。
• 按设备查询历史状态：在 equipment_status_log 表的 equipment_id 和 start_time 上建联合索引。
• 按物料批次追溯：在 material_consumption 表的 batch_number 上建索引。

不建议在每一张表的所有外键字段上建索引。比如物料消耗表已经有 work_order_id 字段，但如果查询时并不通过工单号查找物料消耗（而是通过实例 ID），那么 work_order_id 索引就是多余的。

联合索引的字段顺序很重要。对于状态历史表，查询条件通常是“对象 ID + 时间范围”，所以索引顺序是 (object_id, change_time)，而不是反过来。

写入频繁的表（如 execution_instance、material_consumption）要避免过多索引。每增加一个索引，写入速度大约下降 5% 到 10%。如果业务允许，可以先将数据写入无索引的临时表，再定时批量插入主表，但这会增加系统复杂度，适合高吞吐场景。

对于 MySQL 用户，注意 InnoDB 的二级索引会自动包含主键，因此主键不要使用太长的字符串。工单号虽然是业务标识，但不适合做主键，建议使用自增 ID 或雪花算法生成的整数 ID。

扩展字段设计：避免 EAV 陷阱

MES 定制开发中最常见的问题之一是扩展字段。不同工厂、不同产线对同一实体（比如工单）有不同的附加属性。有的工厂需要工单关联客户订单号，有的需要关联采购单号，有的需要记录批次备注。

最简单的做法是在主表中预留 10 个 varchar 字段（如 extra1, extra2...）。这种方案在数据量小的时候可用，但随着扩展字段增多，代码可读性下降，查询时无法区分字段含义，数据质量也难以保证。

更好的方案是使用 JSON 字段。MySQL 5.7 以上、PostgreSQL 9.4 以上都支持 JSON 类型。在工单主表中增加一个 attributes JSON 字段，存储所有扩展属性。查询时可以使用 JSON_EXTRACT 或 -> 操作符。

JSON 字段的优点是灵活，新增属性不需要改表结构。缺点是 JSON 字段无法直接建普通索引（但可以建虚拟列索引），且 JSON 字段的更新会重写整个字段，不适合频繁修改。

如果扩展字段需要参与频繁的查询或排序，建议单独建一张扩展属性表（work_order_attribute），字段包括工单 ID、属性名、属性值、值类型。这张表与工单主表是一对多关系。查询时通过属性名过滤，性能优于 JSON 方案，但写入和查询需要关联，复杂度增加。

选择哪种方案取决于扩展字段的使用频率：

• 扩展字段数量少（少于 5 个），且不经常查询：使用 JSON 字段。
• 扩展字段数量多，且经常用于过滤或排序：使用扩展属性表。
• 扩展字段数量中等，且查询量不大：两种方案均可，优先选择 JSON 字段，因为实现简单。

无论选择哪种方案，都要在业务层面约束属性名规范。属性名建议使用驼峰命名，并在系统文档中维护一个属性字典，避免不同开发人员使用不同的命名导致数据混乱。

数据质量治理：从源头控制脏数据

MES 的数据质量直接影响生产决策。工单状态错误会导致排产系统误判，物料批次错误会导致追溯失败。数据治理不是上线后的补救工作，而是设计阶段就要考虑的问题。

数据质量治理的五个关键点：

**1. 约束在数据库层面强制执行**

状态字段使用枚举类型或 CHECK 约束，避免程序 bug 写入非法状态。外键约束要开启，确保执行实例引用的工单 ID 一定存在于工单主表中。虽然有些团队为了性能禁用外键，但在 MES 这种数据一致性要求高的系统中，外键的收益远大于性能损失。

**2. 必填字段不可为空**

执行实例的开始时间、结束时间、设备 ID、操作人员 ID 都定义为 NOT NULL。如果某个字段在业务上可能为空（如结束时间在开始执行时未知），可以设置默认值或使用业务规定的占位值。

**3. 状态变更的合法性校验**

不是所有状态转换都是允许的。例如，已完成的工单不能变回执行中。状态变更逻辑应该在应用层实现，但数据库层可以通过触发器做二次校验。触发器会增加数据库负载，因此建议只在关键状态（如工单状态、执行实例状态）上使用。

**4. 数据录入的防呆设计**

操作员手动录入的数据最容易出错。物料批次号、设备编码等字段应该通过扫码枪或下拉选择录入，避免键盘输入。如果必须手动输入，前端要做格式校验，后端也要做二次校验。

**5. 异常数据的定期巡检**

即使有约束和校验，数据异常仍然会发生。系统需要提供数据巡检功能，每天自动检查：

• 执行实例的开始时间是否晚于结束时间
• 物料消耗数量是否大于工单计划数量
• 设备状态日志中是否存在重叠的时间段
• 工单状态与执行实例状态是否一致

巡检结果生成报告，发送给系统管理员。异常数据需要人工确认或自动修复，修复逻辑必须在系统设计时预留。

数据归档与历史数据查询

MES 系统运行两年后，核心表的数据量可能超过千万条。如果不做归档，查询性能会显著下降，备份和恢复的时间也会变长。

数据归档的策略取决于业务需求：

• **按时间归档**：将超过一定期限（如 6 个月）的已关闭工单及其关联数据迁移到历史库。历史库与生产库分离，查询历史数据时通过专门的接口访问。
• **按状态归档**：工单状态为“已关闭”后，如果超过 30 天没有变更，可以归档。这种方式比按时间归档更灵活，因为有些工单可能长期处于“已完成”状态而不关闭。
• **分区表**：在数据库层面按月或按季度分区，删除旧分区时直接 drop。分区表对应用层透明，但需要数据库支持分区功能。

归档时需要注意关联数据的完整性。一个工单归档，其关联的执行实例、物料消耗、质检结果、状态历史都需要同步归档。建议使用存储过程或脚本统一处理，避免遗漏。

历史数据查询的频率通常很低，因此历史库可以使用更便宜的存储，或者使用列式存储数据库（如 ClickHouse）来支持分析查询。生产库只保留最近的数据，保证实时操作的响应速度。

数据模型设计中的常见风险

MES 数据模型设计中有几个容易忽视的风险点，在项目前期识别并规避，可以避免后期返工。

**风险一：过度设计**

有些团队在设计初期就考虑所有可能的扩展场景，导致表结构异常复杂，字段数量超过 50 个。过度设计会增加开发周期和后期维护成本。正确的做法是先实现核心功能，预留扩展字段，后续根据实际需求逐步完善。

**风险二：忽略并发写入**

MES 系统在产线高负荷运行时，多个操作员同时录入数据，可能出现并发写入冲突。例如，两个操作员同时更新同一个工单的状态，导致状态历史记录丢失。解决方案是使用乐观锁或悲观锁。乐观锁通过版本号字段实现，适合冲突概率低的场景；悲观锁通过 SELECT ... FOR UPDATE 实现，适合冲突概率高的场景。

**风险三：时序数据存储不当**

设备状态日志、执行实例的开始结束时间都是时序数据。如果将这些数据存储在普通的关系表中，查询性能会随着数据量增长而下降。对于高频率的时序数据（每秒采集一次），建议使用时序数据库（如 InfluxDB 或 TimescaleDB）。如果频率较低（每分钟一次），关系数据库配合分区表仍然可用。

**风险四：数据模型与业务模型脱节**

数据模型设计者如果对 MES 业务理解不深，容易设计出与业务流程不符的表结构。例如，将工序与设备直接关联，忽略了一个工序可能需要在多台设备上切换执行。解决方法是设计阶段让业务人员参与评审，或者由有 MES 项目经验的技术人员主导设计。SystemDo 在多个 MES 定制项目中发现，业务人员参与评审的阶段越早，后期返工的次数越少。

总结：数据模型设计的工程原则

MES 数据模型设计的核心是平衡：平衡查询性能与写入性能，平衡扩展性与简单性，平衡数据完整性与开发效率。

几个可以长期参考的原则：

• 核心表不超过 10 张，每张表的字段控制在 20 个以内。
• 状态历史独立建表，不要在主表中覆盖更新。
• 索引服务于最频繁的查询模式，不要为所有字段建索引。
• 扩展字段优先使用 JSON，需要频繁查询时使用扩展属性表。
• 数据质量治理从数据库约束开始，辅以应用层校验和定期巡检。
• 归档策略在系统设计时就要确定，而不是等到性能下降后再考虑。

这些原则不是绝对的，每个工厂的产线规模、数据量和业务复杂度不同，具体设计时需要根据实际情况调整。但在大多数 MES 定制开发项目中，遵循这些原则可以避免 80% 以上的数据模型问题。