Flowable表结构解析：从ACT_RE到ACT_HI，一文搞懂所有核心表的作用与关联
Flowable核心表结构深度解析：从存储设计到底层交互逻辑
如果你正在使用Flowable构建业务流程系统，是否遇到过这些困惑：为什么运行时表数据会莫名消失？历史记录到底存储在哪里？用户权限和流程实例如何关联？本文将彻底拆解Flowable的数据库设计哲学，让你掌握表结构背后的设计意图和交互逻辑。
1. Flowable表结构设计哲学与分类体系
第一次打开Flowable的数据库时，面对数十个以ACT_开头的表，大多数开发者都会感到困惑。实际上，这些表按照功能被划分为五个清晰的类别，每个类别对应不同的生命周期阶段和业务场景。
存储层（ACT_RE_*）是流程定义的"保险箱"，这里存放着永远不会改变的静态数据。当你使用RepositoryService部署一个请假流程的BPMN文件时，ACT_RE_DEPLOYMENT会记录部署操作，而ACT_RE_PROCDEF则保存流程定义的核心元数据。有趣的是，ACT_RE_MODEL表专门为Flowable Modeler可视化设计器服务，存储着流程图JSON数据和版本信息。
运行时层（ACT_RU_*）就像流程的"工作记忆"，只保留当前活跃的流程实例数据。这个设计非常巧妙——当流程实例结束时，相关运行时数据会自动清除。ACT_RU_EXECUTION表记录着流程实例的执行路径，而ACT_RU_TASK则管理着待办任务。我曾在一个电商订单系统中发现，高峰期该表始终保持在几百条记录量级，这正是Flowable"运行时数据零持久化"设计的优势体现。
身份层（ACT_ID_*）提供了灵活的身份管理体系。不同于其他表，这部分设计允许完全替换。ACT_ID_USER和ACT_ID_GROUP构成了经典的用户-组模型，而ACT_ID_MEMBERSHIP则维护着多对多的关联关系。在最近的一个项目中，我们通过扩展ACT_ID_INFO表，成功集成了企业原有的LDAP系统。
历史层（ACT_HI_*）是流程的"黑匣子记录仪"。ACT_HI_PROCINST记录每个流程实例的完整生命周期，包括开始/结束时间和耗时。而ACT_HI_TASKINST则保存了所有已完成任务的详细信息。要注意的是，历史数据的详细程度可以通过引擎配置精确控制，这对性能优化至关重要。
通用层（ACT_GE_*）包含系统级数据。ACT_GE_BYTEARRAY是个特殊的存在，它存储所有二进制资源（如图片、流程定义文件），而ACT_GE_PROPERTY则维护着引擎内部的版本和配置信息。
2. 核心表关联与数据流转机制
理解单个表的结构只是第一步，掌握表间的关联关系才能真正驾驭Flowable。让我们通过一个采购审批流程的实际案例，看看数据如何在各表间流转。
当部署一个新的采购流程时，首先在ACT_RE_DEPLOYMENT中创建一条部署记录，相关的BPMN文件内容会被存入ACT_GE_BYTEARRAY。接着ACT_RE_PROCDEF表会生成对应的流程定义条目，其中KEY字段对应BPMN文件中process元素的id属性。
员工发起采购申请时，系统在ACT_RU_EXECUTION创建流程实例，其PROC_DEF_ID指向流程定义。此时ACT_RU_TASK会产生第一个任务节点"部门审批"，任务的ASSIGNEE字段会根据流程定义设置为部门经理的角色ID。
-- 典型的多表关联查询示例 SELECT t.*, p.NAME_ as PROC_NAME FROM ACT_RU_TASK t JOIN ACT_RE_PROCDEF p ON t.PROC_DEF_ID_ = p.ID_ WHERE t.ASSIGNEE_ = 'deptManager'当部门经理审批通过后，运行时数据会发生一系列变化：ACT_RU_TASK中的当前任务被标记完成，ACT_RU_EXECUTION更新流程路径，同时ACT_HI_TASKINST会记录完整的任务执行历史。这个过程中最精妙的是ACT_RU_VARIABLE和ACT_HI_DETAIL的协作——前者管理当前流程变量，后者则持久化重要的变量变更历史。
关键关联关系总结表：
| 关联场景 | 主表 | 关联表 | 关联字段 | 典型用途 |
|---|---|---|---|---|
| 流程定义-实例 | ACT_RE_PROCDEF | ACT_RU_EXECUTION | PROC_DEF_ID_ | 版本控制 |
| 任务-流程实例 | ACT_RU_TASK | ACT_RU_EXECUTION | PROC_INST_ID_ | 任务上下文 |
| 变量-执行流 | ACT_RU_VARIABLE | ACT_RU_EXECUTION | EXECUTION_ID_ | 变量作用域 |
| 历史任务-用户 | ACT_HI_TASKINST | ACT_ID_USER | ASSIGNEE_ | 绩效分析 |
3. 运行时表组的瞬时性特征与优化实践
ACT_RU_*表组的设计体现了Flowable的独特哲学——运行时数据就像计算机的内存，只在需要时存在。这种设计带来了显著的性能优势，但也需要特别注意一些使用细节。
ACT_RU_EXECUTION表是理解这个机制的最佳示例。它采用树形结构记录流程实例的执行路径，SUPER_EXEC_字段形成了父子关系链。当子流程完成时，整个分支会从表中彻底消失。这解释了为什么很多开发者抱怨"我的流程数据不见了"——实际上它们只是正常结束了。
运行时表清理机制对比：
| 表名 | 清理触发条件 | 数据去向 | 性能影响 |
|---|---|---|---|
| ACT_RU_TASK | 任务完成 | ACT_HI_TASKINST | 中等 |
| ACT_RU_VARIABLE | 作用域结束 | ACT_HI_DETAIL | 较高 |
| ACT_RU_EXECUTION | 流程分支结束 | ACT_HI_PROCINST | 最高 |
针对高频使用的ACT_RU_TASK表，我们总结了几条优化经验：
- 避免在任务查询中使用复杂的JOIN操作，优先使用ASSIGNEE_和PROC_DEF_ID_等索引字段
- 对超大规模部署，考虑按业务线拆分TENANT_ID_
- 定期监控ACT_RU_IDENTITYLINK表体积，该表容易因动态任务分配而膨胀
// 高性能任务查询的最佳实践 List<Task> tasks = taskService.createTaskQuery() .processDefinitionKey("procurement") .taskCandidateGroup("finance") .orderByTaskCreateTime().desc() .listPage(0, 100);特别要注意ACT_RU_JOB及其衍生表（如ACT_RU_TIMER_JOB）的管理。这些表存储着异步作业和定时器，一旦堆积会导致严重性能问题。建议配置专门的作业执行器，并设置合理的重试策略。
4. 历史表组的可配置性与审计应用
与运行时表的瞬时性相反，ACT_HI_*表组是流程的永久记忆。Flowable提供了细粒度的历史级别配置，允许在数据详细度和性能间取得平衡。
ACT_HI_PROCINST是历史层的核心表，记录每个流程实例的完整元数据：
- START_TIME_和END_TIME_便于计算平均处理时长
- DELETE_REASON_字段揭示流程终止原因
- DURATION_字段以毫秒存储总耗时
历史级别配置对照表：
| 配置值 | 记录内容 | 存储需求 | 适用场景 |
|---|---|---|---|
| none | 无历史 | 最低 | 纯自动化流程 |
| activity | 节点活动 | 低 | 基本监控 |
| audit | 节点+变量 | 中 | 大多数业务 |
| full | 完整细节 | 高 | 法律合规 |
ACT_HI_DETAIL表是最灵活也最容易误用的历史表。它默认记录变量变更，但在full级别下会捕获所有细节。某次系统审计中，我们发现该表占用了整个数据库60%的空间——原来是因为开启了full级别并配置了过长的变量历史保留时间。
对于需要深度分析的历史数据，推荐使用Flowable提供的专门查询API而非直接SQL：
HistoricProcessInstanceQuery query = historyService.createHistoricProcessInstanceQuery() .finished() .processDefinitionKey("contractApproval") .includeProcessVariables();ACT_HI_COMMENT表的特殊之处在于它既存储系统事件也存储人工注释。在审批场景中，我们扩展了这个表的结构，添加了ATTACHMENT_ID_字段关联到ACT_HI_ATTACHMENT，实现了批注与附件的一体化管理。
5. 身份表组的扩展实践与集成方案
ACT_ID_*表组提供了开箱即用的身份管理功能，但在企业级应用中往往需要定制扩展。我们的经验表明，这套体系足够灵活，可以适应大多数集成场景。
ACT_ID_USER表的设计非常简洁，只包含基本字段。在实际项目中，我们通常这样做扩展：
- 使用ACT_ID_INFO存储额外属性（如部门、职级）
- 通过ACT_ID_GROUP实现RBAC权限模型
- 利用ACT_ID_MEMBERSHIP建立用户-组关系
常见身份集成模式对比：
| 集成方式 | 实现复杂度 | 实时性 | 适用场景 |
|---|---|---|---|
| 同步写入 | 低 | 实时 | 小型系统 |
| 定期同步 | 中 | 延迟 | 中型部署 |
| 视图映射 | 高 | 实时 | 已有身份库 |
| 完全替换 | 最高 | 自定义 | 特殊需求 |
一个金融客户的案例展示了灵活运用身份表的方法：他们将ACT_ID_GROUP的TYPE_字段扩展为"role|department|region"多类型，配合自定义的权限检查逻辑，实现了复杂的跨国审批矩阵。
-- 多维度身份查询示例 SELECT u.ID_, u.FIRST_, u.LAST_, g.NAME_ as DEPT FROM ACT_ID_USER u JOIN ACT_ID_MEMBERSHIP m ON u.ID_ = m.USER_ID_ JOIN ACT_ID_GROUP g ON m.GROUP_ID_ = g.ID_ AND g.TYPE_ = 'department' WHERE u.ID_ IN (SELECT USER_ID_ FROM ACT_RU_IDENTITYLINK WHERE TASK_ID_ = '1001')对于已有成熟身份管理的企业，完全可以绕过ACT_ID_*表，通过实现Flowable的IdentityService接口直接集成现有系统。某电信运营商项目就采用了这种方案，将Flowable与200万用户的LDAP目录无缝对接。
6. 通用表与特殊表的使用技巧
ACT_GE_BYTEARRAY是Flowable中最特殊的表之一，它像是一个二进制仓库，存储着各种类型的资源：
- 流程定义文件（BPMN/XML）
- 流程图图片
- 表单定义
- 变量序列化值
这个表的设计有几个精妙之处：
- GENERATED_字段区分用户上传和系统生成资源
- BYTES_字段使用BLOB类型，适应不同数据库
- 通过DEPLOYMENT_ID_与部署记录关联
我们曾遇到一个性能问题：某流程包含大型图片资源，导致ACT_GE_BYTEARRAY查询变慢。解决方案是分离存储——将图片存到文件系统，数据库中只保留路径引用。
ACT_EVT_LOG表常被忽视，但它对调试复杂问题非常有用。该表记录引擎内部事件，如事务提交、作业执行等。在排查一个定时器不触发的问题时，我们正是通过这个表发现了时区配置错误。
特殊表使用场景指南：
| 表名 | 启用条件 | 主要用途 | 维护建议 |
|---|---|---|---|
| ACT_EVT_LOG | 配置开启 | 引擎诊断 | 定期归档 |
| ACT_PROCDEF_INFO | 动态创建 | 流程元数据 | 自动清理 |
| ACT_GE_PROPERTY | 系统内置 | 版本管理 | 勿手动修改 |
ACT_PROCDEF_INFO表存储着流程定义的扩展信息，采用JSON格式。在最近的一个创新应用中，我们利用这个表存储了每个流程版本的数据模型定义，实现了完全动态的表单生成。