1. Flowable表名设计背后的逻辑
第一次接触Flowable的表结构时，看着79张表名确实有点懵。但当我花时间梳理后发现，这些命名就像一套精密的密码系统，每个部分都暗藏玄机。最让我惊喜的是，这套命名体系完美体现了Flowable作为流程引擎的设计哲学。
表名采用三段式结构，就像"姓-辈分-名"的家谱体系。前缀ACT_和FLW_相当于姓氏，告诉我们这个表属于哪个家族；中缀如RU、HI相当于辈分，表明表的世代；后缀如TASK、VARINST则是名字，直接说明表的用途。这种设计让开发者即使不看文档，也能猜出表的大致功能。
我在实际项目中验证过，理解这套命名规则后，排查流程问题效率提升了至少3倍。比如看到ACT_HI_TASKINST，就能立刻想到这是存储历史任务实例的表，而ACT_RU_TASK则是运行时任务表。
2. 前缀解析：ACT_与FLW_的渊源
刚开始用Flowable时，我很好奇为什么有的表以ACT_开头，有的却是FLW_。后来查阅源码才发现，这背后藏着一段"继承与发展"的故事。
ACT_前缀继承自Activiti，就像Java的java.util包名一样，保留这个前缀是为了兼容原有生态。而FLW_前缀则是Flowable团队的原创设计，主要用于Work和Engage等商业版本特有的功能模块。这种命名策略既尊重历史，又为未来发展留出空间。
实际开发中最常见的ACT_前缀表占总数的85%左右，主要包括：
- 流程引擎核心表（ACT_RU_*）
- 历史数据表（ACT_HI_*）
- 身份认证表（ACT_ID_*）
而FLW_前缀表虽然数量不多，但往往涉及高级功能。比如FLW_EVENT_*系列表就专门处理复杂的事件驱动场景，我在实现消息中间件集成时就深有体会。
3. 中缀详解：模块功能的密码本
表名中缀就像功能模块的身份证，我整理了最常用的12类中缀及其含义：
| 中缀 | 全称 | 典型表示例 | 核心功能 |
|---|---|---|---|
| RU | Runtime | ACT_RU_TASK | 存储运行时的任务实例 |
| HI | History | ACT_HI_PROCINST | 记录已完成流程实例 |
| ID | Identity | ACT_ID_USER | 管理用户和权限 |
| CMMN | Case Management | ACT_CMMN_RU_CASE_INST | 处理CMMN规范案例 |
| DMN | Decision Model | ACT_DMN_DECISION | 存储决策表定义 |
| RE | Repository | ACT_RE_PROCDEF | 保存流程定义版本 |
特别要说下RU和HI这对黄金组合。RU表就像内存中的工作区，只保留当前活跃数据；HI表则是持久化存储，记录所有历史轨迹。这种设计让Flowable既保持运行时高效，又能完整追溯历史。
4. 后缀规范：数据类型的指纹
表名后缀是最直观的功能说明，主要分为三大类：
通用资源类后缀
- DEPLOYMENT：部署记录（如ACT_RE_DEPLOYMENT）
- RESOURCE：资源内容（如ACT_APP_DEPLOYMENT_RESOURCE）
- DEFINITION：模型定义（如ACT_CMMN_CASEDEF）
运行时实体类后缀
- INST：实例记录（如ACT_RU_EXECUTION）
- VAR：变量存储（如ACT_RU_VARIABLE）
- TASK：任务数据（如ACT_RU_TASK）
特殊功能类后缀
- BYTEARRAY：二进制内容（如ACT_GE_BYTEARRAY）
- LOG：日志记录（如ACT_EVT_LOG）
- CHANGELOG：数据库变更（如ACT_DATABASECHANGELOG）
在调试流程时，我经常通过后缀快速定位问题。比如发现变量值异常，就直接查*_VAR表；需要分析任务流转，就重点看_TASK和*_ACTINST表。
5. 核心模块表组解析
5.1 运行时引擎表组（ACT_RU_*）
这组表就像流程引擎的工作内存，存储着所有正在运行的流程实例。其中最重要的三张表是：
ACT_RU_EXECUTION：流程执行树结构表
- 记录流程实例的当前执行路径
- 通过PARENT_ID_字段形成树形结构
- 包含当前活动的节点信息
ACT_RU_TASK：用户任务表
- 存储所有待办任务
- 包含Assignee、DueDate等任务属性
- 与ACT_RU_IDENTITYLINK关联处理任务分配
ACT_RU_VARIABLE：流程变量表
- 存储流程实例级别的变量
- 支持多种数据类型（String、Integer、Serializable等）
- 通过EXECUTION_ID_关联到具体实例
我在处理高并发流程时发现，这些RU表的索引设计非常关键。建议为ACT_RU_TASK的ASSIGNEE_字段添加索引，可以大幅提升任务查询效率。
5.2 历史归档表组（ACT_HI_*）
如果说RU表是工作台，那么HI表就是档案室。最常用的历史表包括：
ACT_HI_PROCINST：流程实例历史
- 记录流程从创建到结束的全生命周期
- 包含开始时间、结束时间、持续时间等关键指标
- 业务KEY与业务系统关联的重要字段
ACT_HI_TASKINST：任务实例历史
- 记录每个任务的处理轨迹
- 包含处理人、处理时间、耗时等数据
- 生成报表时的主要数据来源
ACT_HI_VARINST：变量历史
- 记录流程变量的变更历史
- 通过VAR_TYPE_字段区分变量类型
- 支持按时间范围查询变量快照
有个实际经验分享：当历史数据量过大时，可以配置Flowable的HistoryLevel来控制归档粒度。我们项目就改用ACTIVITY级别，只记录关键节点信息，使历史数据量减少了60%。
6. 扩展模块表组精讲
6.1 决策引擎表组（ACT_DMN_*）
DMN表组实现了决策自动化功能，核心表包括：
ACT_DMN_DECISION：决策表定义
- 存储决策表的输入输出定义
- 通过DECISION_KEY_版本化管理
- 支持多版本决策表共存
ACT_DMN_HI_DECISION_EXECUTION：决策执行历史
- 记录每次决策调用的输入输出
- 包含执行时间、执行人等审计字段
- 可用于决策结果追溯
在信贷风控项目中，我们利用这套表实现了自动化审批。通过DECISION_KEY_关联业务规则，当规则更新时只需部署新版本，不影响正在进行的流程。
6.2 表单引擎表组（ACT_FO_FORM_*）
表单表组实现了动态表单功能，主要包含：
ACT_FO_FORM_DEFINITION：表单定义
- 存储表单的JSON结构定义
- 支持版本控制和多租户隔离
- 包含表单校验规则等元数据
ACT_FO_FORM_INSTANCE：表单实例
- 记录每个流程实例关联的表单数据
- 通过PROC_INST_ID_关联流程实例
- 支持表单数据版本追溯
有个实用技巧：表单定义通常较大，建议单独部署表单资源，避免影响流程部署性能。我们项目中将表单部署与流程部署分离后，部署速度提升了40%。
7. 表结构设计的最佳实践
经过多个项目实践，我总结了几个关键经验：
索引优化方案
- 为所有外键字段创建索引（如PROC_INST_ID_）
- HI表按时间范围查询的字段加索引（如START_TIME_）
- RU表为常用查询条件建组合索引
分区策略建议
- 对ACT_HI_PROCINST按时间范围分区
- 将ACT_HI_VARINST按变量类型分区
- 考虑业务维度分区（如租户ID）
维护注意事项
- 定期归档历史数据（保留最近3个月即可）
- 监控RU表增长情况，防止内存泄漏
- 避免在流程变量中存储大对象
曾经踩过一个坑：没有及时清理历史数据，导致ACT_HI_TASKINST表达到千万级，查询性能急剧下降。后来我们建立了每月归档机制，问题才得到解决。
