接手有流程审批的系统我最先关注的表永远是ACT_RU_TASK。它不是最复杂的一张表但绝对是最频繁被查询的一张。用户登录后看到的我的待办十有八九就来自这张表任务超时提醒、待办数量角标、撤回重办最终也要落到这张表上。这张表叫运行时任务表属于Activiti的15张运行实例表之一存的是正在进行的任务——只要任务没办完记录就躺在这里一旦流程节点往下走这条记录又会马上被搬进历史表。数据量通常不大但它最容易出问题索引漏建、时区写错、权限过滤没加都会让待办查询变得又慢又乱。这篇文章我就把ACT_RU_TASK从字段结构、生命周期、联表查询到避坑经验完整过一遍给正在做工作流开发、需要自己写待办逻辑或者排查流程异常的同行做个参考。1. 运行实例表里的那张任务表1.1 Activiti的25张表到底怎么分Activiti把数据库表分成几类这个心里要先有个谱流程定义表ACT_RE_*存流程模型、流程部署包这类表只随部署变化不太会频繁增删。运行实例表ACT_RU_*存流程实例、任务、变量、作业、身份关系、事件订阅等运行期数据。整类共15张ACT_RU_TASK就是其中之一。历史表ACT_HI_*流程实例结束、任务完成后生成的归档记录用于追溯和统计分析。通用表ACT_GE_*存系统属性和字节码数据。身份信息表ACT_ID_*存用户、组、关系等身份数据。这种拆分思路和大多数工作流引擎一致把当前状态和历史归档分开。运行表的数据强调实时性和一致性追求的是快速读写历史表的数据只增不改追求的是完整追溯。明白这个分层后面看ACT_RU_TASK的所有设计点都顺了。1.2 ACT_RU_TASK在运行表中的核心定位ACT_RU_TASK对应的业务概念是待办任务。流程实例每次流转到用户任务节点引擎就会在这里插入一条任务记录。它和ACT_RU_EXECUTION的关系很多人容易混EXECUTION表代表流程执行的令牌表示当前流程跑到了哪个节点TASK表代表需要由人来处理的具体工作项。流程走到一个用户节点通常既有EXECUTION记录也会产生TASK记录。但两者不是绑死的——并行网关下一个执行实例可能挂着多个任务而流程走到排他网关时执行实例在跑但未必有任务。因此引擎的待办中心开发任务表的查询逻辑不会只看执行表而是直接以任务表为主表。ACT_RU_TASK还承担了一个隐含作用引擎内部判断流程是否可推进的依据之一。任务如果未完成用户节点后面的连线不会触发只有TASK记录被删掉即完成引擎才会沿着当前执行实例往下找下一个节点。所以这张表的增删记录某种意义上就是流程推进的鼓点。2. ACT_RU_TASK字段逐段拆解2.1 字段总览我常用的是Activiti 6.0的结构这里把核心字段整理成一张表不同版本之间可能有小差异但主体不会变字段类型说明我关心的程度ID_varchar(64)任务主键高REV_int版本号乐观锁用高EXECUTION_ID_varchar(64)执行实例ID高PROC_INST_ID_varchar(64)流程实例ID高PROC_DEF_ID_varchar(64)流程定义ID中NAME_varchar(255)任务名称如部门经理审批高TASK_DEF_KEY_varchar(255)流程模型里用户节点的Key中PARENT_TASK_ID_varchar(64)父任务ID子任务用中DESCRIPTION_varchar(255)任务描述低OWNER_varchar(255)任务的拥有人中ASSIGNEE_varchar(255)当前办理人极高DELEGATION_varchar(64)委派标记POSSIBLE或RESERVED中PRIORITY_int优先级默认50中CREATE_TIME_datetime任务创建时间高DUE_DATE_datetime到期时间催办用高CATEGORY_varchar(255)任务分类低SUSPENSION_STATE_int挂起状态1激活2挂起高TENANT_ID_varchar(255)多租户标识低FORM_KEY_varchar(255)待办表单标识中看到这张表重点不是把字段背下来而是理解每个字段背后的使用场景。下面我挑几个关键的展开讲。2.2 主键、版本号与流程坐标ID_是全局主键引擎生成业务系统不要试图自己构造。REV_是乐观锁版本号每次更新都会加一。这在多人同时操作同一个任务时特别重要比如两个窗口同时抢办同一个任务通过REV_就能避免最后写入覆盖先写入的问题。引擎层会自己校验但作为开发人员查询时尽量以ID_作为唯一条件不要拿业务单据号去关联任务表——那样容易出现一对一变一对多的情况。EXECUTION_ID_、PROC_INST_ID_、PROC_DEF_ID_这三个字段就是任务的全地址。PROC_DEF_ID_指向流程定义PROC_INST_ID_指向某一次具体的流程实例EXECUTION_ID_指向当前执行位置。一般业务系统关注PROC_INST_ID_就够了因为它能关联到具体的业务单据。但要注意一个细节同一个流程实例在并行网关下可能拆出多个执行实例此时如果按EXECUTION_ID_去关联流程变量需要先搞清楚变量挂在哪个执行实例下否则容易查漏。TASK_DEF_KEY_是流程模型里的节点标识。这个字段在做节点权限或者节点配置时非常有用。举个例子某个流程里部门经理审批和总经理审批都叫审批但对应不同权限通过TASK_DEF_KEY_就能精确区分当前待办是哪一个节点产生的而不是靠任务名称去猜。2.3 人、权限与委派ASSIGNEE_是我个人认为最重要、也最容易翻车的字段。它的值表示当前任务的直接办理人。大多数待办查询都长这样SELECT * FROM ACT_RU_TASK WHERE ASSIGNEE_ zhangsan AND SUSPENSION_STATE_ 1;但实际项目里流程配置经常出现候选人而不指定办理人的情况。流程建模时如果把用户节点的办理人设置为一个候选组比如部门经理角色组那么在任务表里ASSIGNEE_是NULL任务实际上是通过ACT_RU_IDENTITYLINK表运行时身份关系表来关联候选人的。这时候查待办只过滤ASSIGNEE_就会漏数据必须把身份关系表关联进来一起查。OWNER_和ASSIGNEE_的区别也容易混淆。OWNER_是任务的创建人或拥有人ASSIGNEE_是当前实际办理人。正常审批时两者可能相同但发生委派后OWNER_保留原办理人ASSIGNEE_变成被委派的人。DELEGATION_字段会标记这次操作是POSSIBLE委派给他人原办理人还可以干预还是RESERVED完全转交。看到这里你应该明白了权限判断不能只看ASSIGNEE_有时候要结合DELEGATION_判断任务是不是被临时委托出去的。2.4 时间、状态与优先级CREATE_TIME_和DUE_DATE_支撑了任务超时提醒这一类需求。主题表结构简单但时区是个坑我后面单列一节说。SUSPENSION_STATE_表示流程实例或任务是否被挂起。流程实例被挂起后它下面的任务一般也会被置为挂起状态值变为2。待办查询如果不加这个过滤条件有可能把已经挂起流程里的任务也查出来用户点了办理还会报错。PRIORITY_默认是50我见过有些项目用这个字段做紧急标识效果还行不过我更习惯用DUE_DATE_加自定义业务字段做催办因为时间维度更直观。3. 任务从生到死的旅程3.1 任务创建时发生了什么流程运行到用户任务节点时引擎会做三件事在执行实例表里定位或生成当前执行记录在ACT_RU_TASK插入一条新任务同时在ACT_RU_IDENTITYLINK插入任务与办理人的关联记录如果有候选人或候选组的话。这时候去观察数据库通常能看到一条执行实例ID相同、任务ID不同的记录。任务ID是新的独立主键不是执行实例ID。很多初学者会把EXECUTION_ID_当成任务ID去查结果发现查不到就是因为这两者的粒度不一样。任务的名称和描述通常来自流程模型里节点配置的name和description但业务系统也经常在流程发起时动态指定任务名称比如把单据编号拼进去报销单[REQ-2024-001] 部门审批。这在待办列表里非常好用——不用再点进详情看是哪条单据列表页直接展示出来。3.2 认领、委派与转办对表的影响装配候选人的任务在ASSIGNEE_为NULL的状态下等待认领。第一个抢到任务的用户点下认领引擎把ASSIGNEE_写成该用户相当于完成了一次常见的抢单操作。从这一点可以推断如果你要用自己的待办列表实现抢单模式其实不需要额外的业务字段依靠ASSIGNEE_是否为NULL即可。委派操作会让DELEGATION_字段值变为POSSIBLE或RESERVED同时ASSIGNEE_换人。转办和委派在业务上看起来差不多但在Activiti引擎里转办通常是把ASSIGNEE_改成另外一个人DELEGATION_保持不设置语义上更像把活儿交出去。这两个操作如果自己通过Service API实现要注意任务权限校验——是否允许当前操作人执行否则会造成流程权限漏洞。加签和减签在引擎层面更复杂加签往往需要新插入子任务记录并设置PARENT_TASK_ID_指向主任务减签则需要把多余的任务记录删除或完成。这里给个经验能用引擎原生API完成的操作尽量别直接改表。直接在数据库里UPDATE ASSIGNEE_会导致引擎的权限缓存、历史记录对不上后续流程追溯时非常头疼。3.3 任务完成与历史归档任务完成后引擎会删除ACT_RU_TASK里的这条记录同时向ACT_HI_TASKINST写入一条完整的历史任务记录。所以你会发现一个规律运行表里查不到已完成的任务这是正常现象不是数据丢了。历史表和运行表的字段结构高度相似但历史表不会删除还会多出几个字段比如END_TIME_、DELETE_REASON_删除原因、DURATION_耗时。做统计报表时比如算某个节点的平均审批时长就应该查ACT_HI_TASKINST而不是ACT_RU_TASK。我有一次就是没分清业务方说审批平均耗时看不到历史数据结果排查发现是报表SQL一直在查运行表——任务一完成记录就没了当然查不到历史。所以设计查询方案前先确认自己是查当前待办还是历史已办两张表绝对不能混用。4. 待办查询与联表查询实践4.1 最基础的待办查询一条最普通的待办SQL过滤条件就三个办理人、激活状态、创建时间排序。SELECT t.ID_ AS taskId, t.NAME_ AS taskName, t.CREATE_TIME_ AS createTime, t.DUE_DATE_ AS dueDate, t.PROC_INST_ID_ AS procInstId, t.FORM_KEY_ AS formKey FROM ACT_RU_TASK t WHERE t.ASSIGNEE_ zhangsan AND t.SUSPENSION_STATE_ 1 ORDER BY t.CREATE_TIME_ DESC;很多团队还会要求加一个权限控制只看当前用户有权限的流程分类。这个条件如果直接关联ACT_RU_IDENTITYLINK要小心一个坑任务有多个候选人或候选组的情况下身份关系表里会有多行记录不加DISTINCT会造成待办列表重复。我一般在SQL层面这样处理SELECT DISTINCT t.ID_, t.NAME_, ... FROM ACT_RU_TASK t LEFT JOIN ACT_RU_IDENTITYLINK li ON li.TASK_ID_ t.ID_ WHERE t.ASSIGNEE_ zhangsan OR (t.ASSIGNEE_ IS NULL AND (li.USER_ID_ zhangsan OR li.GROUP_ID_ IN (manager_group))) AND t.SUSPENSION_STATE_ 1;这段SQL的逻辑就是把ASSIGNEE_直接命中的人和通过候选关系关联到的人合并查询。注意在OR条件组合时加上括号AND和OR的优先级是初学者最容易踩的坑。4.2 关联流程定义和业务表待办列表通常不止展示任务表本身的字段还要展示这是什么流程对应哪个单据。标准做法是关联流程定义表和业务表SELECT t.ID_ AS taskId, t.NAME_ AS taskName, t.CREATE_TIME_, pd.KEY_ AS processKey, pd.NAME_ AS processName, e.BUSINESS_KEY_ AS businessKey FROM ACT_RU_TASK t LEFT JOIN ACT_RU_EXECUTION e ON t.PROC_INST_ID_ e.PROC_INST_ID_ AND e.PARENT_ID_ IS NULL LEFT JOIN ACT_RE_PROCDEF pd ON t.PROC_DEF_ID_ pd.ID_ WHERE t.ASSIGNEE_ zhangsan AND t.SUSPENSION_STATE_ 1;这里的关联逻辑要注意ACT_RU_EXECUTION表里一个流程实例往往有主执行实例和子执行实例主执行实例的PARENT_ID_为NULL。如果直接按EXECUTION_ID_关联可能取不到BUSINESS_KEY_因为业务流程变量经常挂主执行实例上。用PROC_INST_ID_去匹配再过滤PARENT_ID_为空是最稳妥的取单号方式。4.3 超时、挂起与催办场景催办功能一般基于DUE_DATE_。比如找出所有已经过期但尚未完成的任务SELECT t.ID_, t.NAME_, t.ASSIGNEE_, t.DUE_DATE_, t.PROC_INST_ID_ FROM ACT_RU_TASK t WHERE t.DUE_DATE_ IS NOT NULL AND t.DUE_DATE_ NOW() AND t.SUSPENSION_STATE_ 1;需要注意两点第一DUE_DATE_为NULL的任务不参与超时判断有些流程可能根本就没设截止时间这种任务理论上不该被催办第二数据库时间与应用服务器时间必须保持一致否则过期判断会提前或延后业务方最反感的就是明明没过期却收到催办短信。挂起任务的排查也很常见。流程管理员可以把某个实例暂停对应任务表的SUSPENSION_STATE_变成2。此时待办查询加上AND t.SUSPENSION_STATE_ 1就能把它们排除。但如果业务方要求挂起流程的待办也展示只是不能办理那查询就不应过滤这个字段而是在前端按钮上做置灰处理。判断能不能办理不能只看这个字段还要通过引擎API校验流程状态这样更安全。4.4 通过Java API查询的推荐做法大部分场景我建议直接用Activiti的TaskQuery不要手写SQL。因为引擎内部会处理权限、租户、历史记录等逻辑手写SQL容易遗漏状态条件。ListTask tasks taskService.createTaskQuery() .taskAssignee(zhangsan) .active() .orderByTaskCreateTime().desc() .listPage(0, 20);如果需要查询候选任务用taskCandidateUser引擎会自动去身份关系表匹配ListTask tasks taskService.createTaskQuery() .taskCandidateUser(zhangsan) .active() .list();但有些场景必须手写SQL比如大数据量的报表查询、跨库联表导出、或者部门维度的统计。这时候才走JDBC或MyBatis。我的原则是在线交互操作走引擎API离线统计和运维SQL直接走数据库两边结合才算完整方案。5. 常见问题排查与避坑5.1 ASSIGNEE_为NULL导致待办漏查这是我在实际项目里排查最多的问题。现象是明明某个用户有权限审批打开待办却看不到那条任务。查任务表发现ASSIGNEE_是NULL但ACT_RU_IDENTITYLINK里确实有候选记录。原因就是查询SQL只按ASSIGNEE_过滤没处理候选关系。处理办法见前面4.1那段SQL。但还有一个容易被忽视的坑候选人可能挂在组下面业务系统在查询时必须先把用户所属的全部组查出来再用li.GROUP_ID_ IN (...)匹配。组数据往往在ACT_ID_GROUP里如果业务系统有自己的组织架构表要注意与Activiti身份模块同步否则新建用户进组后待办权限会不一致。5.2 任务表数据与执行实例不一致有次我遇到一个诡异现象ACT_RU_TASK里任务还挂着但对应的ACT_RU_EXECUTION记录不见了。流程界面显示流程实例结束待办里却还留着那条任务用户点都点不开。后来排查发现是某次历史数据清理脚本误删了执行实例表而任务表没同步清理。所以任何针对运行表的清理脚本必须同时考虑执行实例、任务、身份关系、变量表的一致性。我自己执行清理前一定会先备份并且按流程实例ID逐个检查四张表ACT_RU_EXECUTION、ACT_RU_TASK、ACT_RU_VARIABLE、ACT_RU_IDENTITYLINK。宁可慢不能错。5.3 时间字段的时区陷阱CREATE_TIME_和DUE_DATE_在数据库里存的是datetime。如果数据库连接参数没设置好JDBC驱动写入时可能按服务器时区转换读取时又按另一套时区转换导致任务创建时间相差8小时。这种问题在日志里不容易发现但用户会明显感觉到我上午提交的审批显示创建时间是凌晨。排查思路很直接先确认数据库服务器时区、应用服务器时区、JDBC连接参数特别是serverTimezone配置三者一致。再拿一条已知时间的数据对比判断偏差是恒定若干小时还是只有几秒。我踩过之后养成了习惯在应用启动时打印当前时间和数据库时间做一次显式校准然后统一使用应用服务器的标准时区。DUE_DATE_的写入也一样所有接口传参必须带时区信息不能传2024-01-01 00:00:00这种裸字符串否则web容器和数据库容器时区不同又会差出几个小时。5.4 运行表数据膨胀按说ACT_RU_TASK只存运行中任务任务完成就删数据量不会爆炸。但在高并发、流程异常、或者外部系统反复驳回的场景下这张表可能会积压大量未完成任务甚至变成几百万行。主要原因通常有三类任务没人认领流程一直挂在用户节点流程实例被异常中断子任务没有正确归档业务系统并发发起大量流程审批节奏跟不上。性能下降的表现很直接待办查询越来越慢。不要急着加索引解决全部问题先去看看积压任务到底是哪些节点产生的是不是业务上已经不再需要把它们做挂起、作废或批量删除。我见过一个项目ACT_RU_TASK长期超过几百万行加了索引后查询速度恢复一段时间但根本问题没解决下个月又慢了。治理数据膨胀的核心不是加索引而是让业务闭环按时完成任务、及时作废僵尸流程。5.5 索引选择与慢查询优化索引是按业务查询模式设计的。一般来说ACT_RU_TASK上默认有主键索引但实际业务经常需要这些组合索引CREATE INDEX idx_ru_task_assignee ON ACT_RU_TASK(ASSIGNEE_); CREATE INDEX idx_ru_task_proc_inst ON ACT_RU_TASK(PROC_INST_ID_); CREATE INDEX idx_ru_task_due_date ON ACT_RU_TASK(DUE_DATE_);建索引时要看实际SQL的WHERE条件和JOIN条件。比如查询经常带ASSIGNEE_ SUSPENSION_STATE_ CREATE_TIME_排序那把三个字段做成联合索引的效果比每个字段建独立索引好得多CREATE INDEX idx_ru_task_assignee_state_time ON ACT_RU_TASK(ASSIGNEE_, SUSPENSION_STATE_, CREATE_TIME_ DESC);这里要注意不同数据库对索引顺序的敏感程度不同但总体原则是等值查询字段放前面范围查询和排序字段放后面。也别为了优化把所有字段都放进索引写多读少的表过多的索引反而拖慢插入和更新因为每次DML都要维护索引。我给过一个项目做优化只加了一个联合索引待办查询从2秒掉到200毫秒以下效果非常明显。6. 日常维护与设计上的一些建议6.1 建立任务归档与清理机制即使运行表设计上有自动删除也建议单独建一张业务侧的任务归档表把已经完成的任务和业务单据编号一起留存。我不是说ACT_HI_TASKINST不够用而是很多团队会需要按业务类型时间范围处理人的查询如果直接查历史表历史表也会越来越大。我常用的方案是业务层在任务完成回调里把关键信息写入业务自己的归档表。每周定时任务扫描ACT_RU_TASK把超过90天未完成且流程实例已结束的孤儿任务捞出来做异常处理。对ACT_HI_TASKINST做分区按月分区时间长的走归档库。这套机制坚持下去ACT_RU_TASK的体积基本可以稳定控制历史查询也不会拖垮主库。6.2 日常巡检SQL我建议运维侧每天跑一次下面几条SQL提前发现问题-- 当前待办总数 SELECT COUNT(*) FROM ACT_RU_TASK WHERE SUSPENSION_STATE_ 1; -- 超过7天未完成的任务 SELECT t.ID_, t.NAME_, t.ASSIGNEE_, t.CREATE_TIME_, t.PROC_INST_ID_ FROM ACT_RU_TASK t WHERE t.SUSPENSION_STATE_ 1 AND t.CREATE_TIME_ DATE_SUB(NOW(), INTERVAL 7 DAY);如果待办总数突然翻倍或者大批任务超过7天无人处理说明流程链路上要么人员配置有问题要么某个节点配置错了比如候选人算出来是空集。这两个指标比CPU、内存更早暴露问题。6.3 一些长期维护的经验做流程引擎最重要的原则是能让引擎管的事别自己写SQL去改。ACT_RU_TASK的增删改特别是删除一定要走引擎的complete、deleteTask等API否则跳过引擎的内部逻辑轻则历史记录查不到重则流程实例状态错乱。我在一个项目里为了批量清理历史测试数据直接DELETE了ACT_RU_TASK结果导致一批执行实例无法归档后来花了一晚上才修复。从那之后我给自己定了条铁律线上环境运行表不做直接DELETE即使要清理也要先保证流程实例状态完全停掉并且对该PROC_INST_ID下的所有运行表数据一并处理。另外改表结构这种操作要非常谨慎。ACT_RU_TASK的字段虽然不多但Activiti引擎启动时会对表结构做校验如果你把某个字段长度改小了或者删掉了引擎版本依赖的字段启动大概率会失败。遇到需要扩展信息的需求优先把业务扩展字段放在自己的业务表里以PROC_INST_ID_关联而不是往ACT_RU_TASK上随便加列。这样升级引擎版本的时候你就不用纠结兼容性问题了。最后分享一个排查待办问题的小技巧吧当用户报待办不见了我一般不看应用日志优先查两张表——ACT_RU_TASK和ACT_RU_IDENTITYLINK。先确认任务还在不在再确认任务和人到底是怎么关联的。任务在、关联丢了就是权限配置问题任务都不在了就看是流程推进走了还是被误删了。这两步做完八成的问题都能定位。工作流项目里数据本身会说话把表和业务逻辑对应起来排查效率真的会高很多。
接手有流程审批的系统我最先关注的表永远是ACT_RU_TASK。它不是最复杂的一张表但绝对是最频繁被查询的一张。用户登录后看到的我的待办十有八九就来自这张表任务超时提醒、待办数量角标、撤回重办最终也要落到这张表上。这张表叫运行时任务表属于Activiti的15张运行实例表之一存的是正在进行的任务——只要任务没办完记录就躺在这里一旦流程节点往下走这条记录又会马上被搬进历史表。数据量通常不大但它最容易出问题索引漏建、时区写错、权限过滤没加都会让待办查询变得又慢又乱。这篇文章我就把ACT_RU_TASK从字段结构、生命周期、联表查询到避坑经验完整过一遍给正在做工作流开发、需要自己写待办逻辑或者排查流程异常的同行做个参考。1. 运行实例表里的那张任务表1.1 Activiti的25张表到底怎么分Activiti把数据库表分成几类这个心里要先有个谱流程定义表ACT_RE_*存流程模型、流程部署包这类表只随部署变化不太会频繁增删。运行实例表ACT_RU_*存流程实例、任务、变量、作业、身份关系、事件订阅等运行期数据。整类共15张ACT_RU_TASK就是其中之一。历史表ACT_HI_*流程实例结束、任务完成后生成的归档记录用于追溯和统计分析。通用表ACT_GE_*存系统属性和字节码数据。身份信息表ACT_ID_*存用户、组、关系等身份数据。这种拆分思路和大多数工作流引擎一致把当前状态和历史归档分开。运行表的数据强调实时性和一致性追求的是快速读写历史表的数据只增不改追求的是完整追溯。明白这个分层后面看ACT_RU_TASK的所有设计点都顺了。1.2 ACT_RU_TASK在运行表中的核心定位ACT_RU_TASK对应的业务概念是待办任务。流程实例每次流转到用户任务节点引擎就会在这里插入一条任务记录。它和ACT_RU_EXECUTION的关系很多人容易混EXECUTION表代表流程执行的令牌表示当前流程跑到了哪个节点TASK表代表需要由人来处理的具体工作项。流程走到一个用户节点通常既有EXECUTION记录也会产生TASK记录。但两者不是绑死的——并行网关下一个执行实例可能挂着多个任务而流程走到排他网关时执行实例在跑但未必有任务。因此引擎的待办中心开发任务表的查询逻辑不会只看执行表而是直接以任务表为主表。ACT_RU_TASK还承担了一个隐含作用引擎内部判断流程是否可推进的依据之一。任务如果未完成用户节点后面的连线不会触发只有TASK记录被删掉即完成引擎才会沿着当前执行实例往下找下一个节点。所以这张表的增删记录某种意义上就是流程推进的鼓点。2. ACT_RU_TASK字段逐段拆解2.1 字段总览我常用的是Activiti 6.0的结构这里把核心字段整理成一张表不同版本之间可能有小差异但主体不会变字段类型说明我关心的程度ID_varchar(64)任务主键高REV_int版本号乐观锁用高EXECUTION_ID_varchar(64)执行实例ID高PROC_INST_ID_varchar(64)流程实例ID高PROC_DEF_ID_varchar(64)流程定义ID中NAME_varchar(255)任务名称如部门经理审批高TASK_DEF_KEY_varchar(255)流程模型里用户节点的Key中PARENT_TASK_ID_varchar(64)父任务ID子任务用中DESCRIPTION_varchar(255)任务描述低OWNER_varchar(255)任务的拥有人中ASSIGNEE_varchar(255)当前办理人极高DELEGATION_varchar(64)委派标记POSSIBLE或RESERVED中PRIORITY_int优先级默认50中CREATE_TIME_datetime任务创建时间高DUE_DATE_datetime到期时间催办用高CATEGORY_varchar(255)任务分类低SUSPENSION_STATE_int挂起状态1激活2挂起高TENANT_ID_varchar(255)多租户标识低FORM_KEY_varchar(255)待办表单标识中看到这张表重点不是把字段背下来而是理解每个字段背后的使用场景。下面我挑几个关键的展开讲。2.2 主键、版本号与流程坐标ID_是全局主键引擎生成业务系统不要试图自己构造。REV_是乐观锁版本号每次更新都会加一。这在多人同时操作同一个任务时特别重要比如两个窗口同时抢办同一个任务通过REV_就能避免最后写入覆盖先写入的问题。引擎层会自己校验但作为开发人员查询时尽量以ID_作为唯一条件不要拿业务单据号去关联任务表——那样容易出现一对一变一对多的情况。EXECUTION_ID_、PROC_INST_ID_、PROC_DEF_ID_这三个字段就是任务的全地址。PROC_DEF_ID_指向流程定义PROC_INST_ID_指向某一次具体的流程实例EXECUTION_ID_指向当前执行位置。一般业务系统关注PROC_INST_ID_就够了因为它能关联到具体的业务单据。但要注意一个细节同一个流程实例在并行网关下可能拆出多个执行实例此时如果按EXECUTION_ID_去关联流程变量需要先搞清楚变量挂在哪个执行实例下否则容易查漏。TASK_DEF_KEY_是流程模型里的节点标识。这个字段在做节点权限或者节点配置时非常有用。举个例子某个流程里部门经理审批和总经理审批都叫审批但对应不同权限通过TASK_DEF_KEY_就能精确区分当前待办是哪一个节点产生的而不是靠任务名称去猜。2.3 人、权限与委派ASSIGNEE_是我个人认为最重要、也最容易翻车的字段。它的值表示当前任务的直接办理人。大多数待办查询都长这样SELECT * FROM ACT_RU_TASK WHERE ASSIGNEE_ zhangsan AND SUSPENSION_STATE_ 1;但实际项目里流程配置经常出现候选人而不指定办理人的情况。流程建模时如果把用户节点的办理人设置为一个候选组比如部门经理角色组那么在任务表里ASSIGNEE_是NULL任务实际上是通过ACT_RU_IDENTITYLINK表运行时身份关系表来关联候选人的。这时候查待办只过滤ASSIGNEE_就会漏数据必须把身份关系表关联进来一起查。OWNER_和ASSIGNEE_的区别也容易混淆。OWNER_是任务的创建人或拥有人ASSIGNEE_是当前实际办理人。正常审批时两者可能相同但发生委派后OWNER_保留原办理人ASSIGNEE_变成被委派的人。DELEGATION_字段会标记这次操作是POSSIBLE委派给他人原办理人还可以干预还是RESERVED完全转交。看到这里你应该明白了权限判断不能只看ASSIGNEE_有时候要结合DELEGATION_判断任务是不是被临时委托出去的。2.4 时间、状态与优先级CREATE_TIME_和DUE_DATE_支撑了任务超时提醒这一类需求。主题表结构简单但时区是个坑我后面单列一节说。SUSPENSION_STATE_表示流程实例或任务是否被挂起。流程实例被挂起后它下面的任务一般也会被置为挂起状态值变为2。待办查询如果不加这个过滤条件有可能把已经挂起流程里的任务也查出来用户点了办理还会报错。PRIORITY_默认是50我见过有些项目用这个字段做紧急标识效果还行不过我更习惯用DUE_DATE_加自定义业务字段做催办因为时间维度更直观。3. 任务从生到死的旅程3.1 任务创建时发生了什么流程运行到用户任务节点时引擎会做三件事在执行实例表里定位或生成当前执行记录在ACT_RU_TASK插入一条新任务同时在ACT_RU_IDENTITYLINK插入任务与办理人的关联记录如果有候选人或候选组的话。这时候去观察数据库通常能看到一条执行实例ID相同、任务ID不同的记录。任务ID是新的独立主键不是执行实例ID。很多初学者会把EXECUTION_ID_当成任务ID去查结果发现查不到就是因为这两者的粒度不一样。任务的名称和描述通常来自流程模型里节点配置的name和description但业务系统也经常在流程发起时动态指定任务名称比如把单据编号拼进去报销单[REQ-2024-001] 部门审批。这在待办列表里非常好用——不用再点进详情看是哪条单据列表页直接展示出来。3.2 认领、委派与转办对表的影响装配候选人的任务在ASSIGNEE_为NULL的状态下等待认领。第一个抢到任务的用户点下认领引擎把ASSIGNEE_写成该用户相当于完成了一次常见的抢单操作。从这一点可以推断如果你要用自己的待办列表实现抢单模式其实不需要额外的业务字段依靠ASSIGNEE_是否为NULL即可。委派操作会让DELEGATION_字段值变为POSSIBLE或RESERVED同时ASSIGNEE_换人。转办和委派在业务上看起来差不多但在Activiti引擎里转办通常是把ASSIGNEE_改成另外一个人DELEGATION_保持不设置语义上更像把活儿交出去。这两个操作如果自己通过Service API实现要注意任务权限校验——是否允许当前操作人执行否则会造成流程权限漏洞。加签和减签在引擎层面更复杂加签往往需要新插入子任务记录并设置PARENT_TASK_ID_指向主任务减签则需要把多余的任务记录删除或完成。这里给个经验能用引擎原生API完成的操作尽量别直接改表。直接在数据库里UPDATE ASSIGNEE_会导致引擎的权限缓存、历史记录对不上后续流程追溯时非常头疼。3.3 任务完成与历史归档任务完成后引擎会删除ACT_RU_TASK里的这条记录同时向ACT_HI_TASKINST写入一条完整的历史任务记录。所以你会发现一个规律运行表里查不到已完成的任务这是正常现象不是数据丢了。历史表和运行表的字段结构高度相似但历史表不会删除还会多出几个字段比如END_TIME_、DELETE_REASON_删除原因、DURATION_耗时。做统计报表时比如算某个节点的平均审批时长就应该查ACT_HI_TASKINST而不是ACT_RU_TASK。我有一次就是没分清业务方说审批平均耗时看不到历史数据结果排查发现是报表SQL一直在查运行表——任务一完成记录就没了当然查不到历史。所以设计查询方案前先确认自己是查当前待办还是历史已办两张表绝对不能混用。4. 待办查询与联表查询实践4.1 最基础的待办查询一条最普通的待办SQL过滤条件就三个办理人、激活状态、创建时间排序。SELECT t.ID_ AS taskId, t.NAME_ AS taskName, t.CREATE_TIME_ AS createTime, t.DUE_DATE_ AS dueDate, t.PROC_INST_ID_ AS procInstId, t.FORM_KEY_ AS formKey FROM ACT_RU_TASK t WHERE t.ASSIGNEE_ zhangsan AND t.SUSPENSION_STATE_ 1 ORDER BY t.CREATE_TIME_ DESC;很多团队还会要求加一个权限控制只看当前用户有权限的流程分类。这个条件如果直接关联ACT_RU_IDENTITYLINK要小心一个坑任务有多个候选人或候选组的情况下身份关系表里会有多行记录不加DISTINCT会造成待办列表重复。我一般在SQL层面这样处理SELECT DISTINCT t.ID_, t.NAME_, ... FROM ACT_RU_TASK t LEFT JOIN ACT_RU_IDENTITYLINK li ON li.TASK_ID_ t.ID_ WHERE t.ASSIGNEE_ zhangsan OR (t.ASSIGNEE_ IS NULL AND (li.USER_ID_ zhangsan OR li.GROUP_ID_ IN (manager_group))) AND t.SUSPENSION_STATE_ 1;这段SQL的逻辑就是把ASSIGNEE_直接命中的人和通过候选关系关联到的人合并查询。注意在OR条件组合时加上括号AND和OR的优先级是初学者最容易踩的坑。4.2 关联流程定义和业务表待办列表通常不止展示任务表本身的字段还要展示这是什么流程对应哪个单据。标准做法是关联流程定义表和业务表SELECT t.ID_ AS taskId, t.NAME_ AS taskName, t.CREATE_TIME_, pd.KEY_ AS processKey, pd.NAME_ AS processName, e.BUSINESS_KEY_ AS businessKey FROM ACT_RU_TASK t LEFT JOIN ACT_RU_EXECUTION e ON t.PROC_INST_ID_ e.PROC_INST_ID_ AND e.PARENT_ID_ IS NULL LEFT JOIN ACT_RE_PROCDEF pd ON t.PROC_DEF_ID_ pd.ID_ WHERE t.ASSIGNEE_ zhangsan AND t.SUSPENSION_STATE_ 1;这里的关联逻辑要注意ACT_RU_EXECUTION表里一个流程实例往往有主执行实例和子执行实例主执行实例的PARENT_ID_为NULL。如果直接按EXECUTION_ID_关联可能取不到BUSINESS_KEY_因为业务流程变量经常挂主执行实例上。用PROC_INST_ID_去匹配再过滤PARENT_ID_为空是最稳妥的取单号方式。4.3 超时、挂起与催办场景催办功能一般基于DUE_DATE_。比如找出所有已经过期但尚未完成的任务SELECT t.ID_, t.NAME_, t.ASSIGNEE_, t.DUE_DATE_, t.PROC_INST_ID_ FROM ACT_RU_TASK t WHERE t.DUE_DATE_ IS NOT NULL AND t.DUE_DATE_ NOW() AND t.SUSPENSION_STATE_ 1;需要注意两点第一DUE_DATE_为NULL的任务不参与超时判断有些流程可能根本就没设截止时间这种任务理论上不该被催办第二数据库时间与应用服务器时间必须保持一致否则过期判断会提前或延后业务方最反感的就是明明没过期却收到催办短信。挂起任务的排查也很常见。流程管理员可以把某个实例暂停对应任务表的SUSPENSION_STATE_变成2。此时待办查询加上AND t.SUSPENSION_STATE_ 1就能把它们排除。但如果业务方要求挂起流程的待办也展示只是不能办理那查询就不应过滤这个字段而是在前端按钮上做置灰处理。判断能不能办理不能只看这个字段还要通过引擎API校验流程状态这样更安全。4.4 通过Java API查询的推荐做法大部分场景我建议直接用Activiti的TaskQuery不要手写SQL。因为引擎内部会处理权限、租户、历史记录等逻辑手写SQL容易遗漏状态条件。ListTask tasks taskService.createTaskQuery() .taskAssignee(zhangsan) .active() .orderByTaskCreateTime().desc() .listPage(0, 20);如果需要查询候选任务用taskCandidateUser引擎会自动去身份关系表匹配ListTask tasks taskService.createTaskQuery() .taskCandidateUser(zhangsan) .active() .list();但有些场景必须手写SQL比如大数据量的报表查询、跨库联表导出、或者部门维度的统计。这时候才走JDBC或MyBatis。我的原则是在线交互操作走引擎API离线统计和运维SQL直接走数据库两边结合才算完整方案。5. 常见问题排查与避坑5.1 ASSIGNEE_为NULL导致待办漏查这是我在实际项目里排查最多的问题。现象是明明某个用户有权限审批打开待办却看不到那条任务。查任务表发现ASSIGNEE_是NULL但ACT_RU_IDENTITYLINK里确实有候选记录。原因就是查询SQL只按ASSIGNEE_过滤没处理候选关系。处理办法见前面4.1那段SQL。但还有一个容易被忽视的坑候选人可能挂在组下面业务系统在查询时必须先把用户所属的全部组查出来再用li.GROUP_ID_ IN (...)匹配。组数据往往在ACT_ID_GROUP里如果业务系统有自己的组织架构表要注意与Activiti身份模块同步否则新建用户进组后待办权限会不一致。5.2 任务表数据与执行实例不一致有次我遇到一个诡异现象ACT_RU_TASK里任务还挂着但对应的ACT_RU_EXECUTION记录不见了。流程界面显示流程实例结束待办里却还留着那条任务用户点都点不开。后来排查发现是某次历史数据清理脚本误删了执行实例表而任务表没同步清理。所以任何针对运行表的清理脚本必须同时考虑执行实例、任务、身份关系、变量表的一致性。我自己执行清理前一定会先备份并且按流程实例ID逐个检查四张表ACT_RU_EXECUTION、ACT_RU_TASK、ACT_RU_VARIABLE、ACT_RU_IDENTITYLINK。宁可慢不能错。5.3 时间字段的时区陷阱CREATE_TIME_和DUE_DATE_在数据库里存的是datetime。如果数据库连接参数没设置好JDBC驱动写入时可能按服务器时区转换读取时又按另一套时区转换导致任务创建时间相差8小时。这种问题在日志里不容易发现但用户会明显感觉到我上午提交的审批显示创建时间是凌晨。排查思路很直接先确认数据库服务器时区、应用服务器时区、JDBC连接参数特别是serverTimezone配置三者一致。再拿一条已知时间的数据对比判断偏差是恒定若干小时还是只有几秒。我踩过之后养成了习惯在应用启动时打印当前时间和数据库时间做一次显式校准然后统一使用应用服务器的标准时区。DUE_DATE_的写入也一样所有接口传参必须带时区信息不能传2024-01-01 00:00:00这种裸字符串否则web容器和数据库容器时区不同又会差出几个小时。5.4 运行表数据膨胀按说ACT_RU_TASK只存运行中任务任务完成就删数据量不会爆炸。但在高并发、流程异常、或者外部系统反复驳回的场景下这张表可能会积压大量未完成任务甚至变成几百万行。主要原因通常有三类任务没人认领流程一直挂在用户节点流程实例被异常中断子任务没有正确归档业务系统并发发起大量流程审批节奏跟不上。性能下降的表现很直接待办查询越来越慢。不要急着加索引解决全部问题先去看看积压任务到底是哪些节点产生的是不是业务上已经不再需要把它们做挂起、作废或批量删除。我见过一个项目ACT_RU_TASK长期超过几百万行加了索引后查询速度恢复一段时间但根本问题没解决下个月又慢了。治理数据膨胀的核心不是加索引而是让业务闭环按时完成任务、及时作废僵尸流程。5.5 索引选择与慢查询优化索引是按业务查询模式设计的。一般来说ACT_RU_TASK上默认有主键索引但实际业务经常需要这些组合索引CREATE INDEX idx_ru_task_assignee ON ACT_RU_TASK(ASSIGNEE_); CREATE INDEX idx_ru_task_proc_inst ON ACT_RU_TASK(PROC_INST_ID_); CREATE INDEX idx_ru_task_due_date ON ACT_RU_TASK(DUE_DATE_);建索引时要看实际SQL的WHERE条件和JOIN条件。比如查询经常带ASSIGNEE_ SUSPENSION_STATE_ CREATE_TIME_排序那把三个字段做成联合索引的效果比每个字段建独立索引好得多CREATE INDEX idx_ru_task_assignee_state_time ON ACT_RU_TASK(ASSIGNEE_, SUSPENSION_STATE_, CREATE_TIME_ DESC);这里要注意不同数据库对索引顺序的敏感程度不同但总体原则是等值查询字段放前面范围查询和排序字段放后面。也别为了优化把所有字段都放进索引写多读少的表过多的索引反而拖慢插入和更新因为每次DML都要维护索引。我给过一个项目做优化只加了一个联合索引待办查询从2秒掉到200毫秒以下效果非常明显。6. 日常维护与设计上的一些建议6.1 建立任务归档与清理机制即使运行表设计上有自动删除也建议单独建一张业务侧的任务归档表把已经完成的任务和业务单据编号一起留存。我不是说ACT_HI_TASKINST不够用而是很多团队会需要按业务类型时间范围处理人的查询如果直接查历史表历史表也会越来越大。我常用的方案是业务层在任务完成回调里把关键信息写入业务自己的归档表。每周定时任务扫描ACT_RU_TASK把超过90天未完成且流程实例已结束的孤儿任务捞出来做异常处理。对ACT_HI_TASKINST做分区按月分区时间长的走归档库。这套机制坚持下去ACT_RU_TASK的体积基本可以稳定控制历史查询也不会拖垮主库。6.2 日常巡检SQL我建议运维侧每天跑一次下面几条SQL提前发现问题-- 当前待办总数 SELECT COUNT(*) FROM ACT_RU_TASK WHERE SUSPENSION_STATE_ 1; -- 超过7天未完成的任务 SELECT t.ID_, t.NAME_, t.ASSIGNEE_, t.CREATE_TIME_, t.PROC_INST_ID_ FROM ACT_RU_TASK t WHERE t.SUSPENSION_STATE_ 1 AND t.CREATE_TIME_ DATE_SUB(NOW(), INTERVAL 7 DAY);如果待办总数突然翻倍或者大批任务超过7天无人处理说明流程链路上要么人员配置有问题要么某个节点配置错了比如候选人算出来是空集。这两个指标比CPU、内存更早暴露问题。6.3 一些长期维护的经验做流程引擎最重要的原则是能让引擎管的事别自己写SQL去改。ACT_RU_TASK的增删改特别是删除一定要走引擎的complete、deleteTask等API否则跳过引擎的内部逻辑轻则历史记录查不到重则流程实例状态错乱。我在一个项目里为了批量清理历史测试数据直接DELETE了ACT_RU_TASK结果导致一批执行实例无法归档后来花了一晚上才修复。从那之后我给自己定了条铁律线上环境运行表不做直接DELETE即使要清理也要先保证流程实例状态完全停掉并且对该PROC_INST_ID下的所有运行表数据一并处理。另外改表结构这种操作要非常谨慎。ACT_RU_TASK的字段虽然不多但Activiti引擎启动时会对表结构做校验如果你把某个字段长度改小了或者删掉了引擎版本依赖的字段启动大概率会失败。遇到需要扩展信息的需求优先把业务扩展字段放在自己的业务表里以PROC_INST_ID_关联而不是往ACT_RU_TASK上随便加列。这样升级引擎版本的时候你就不用纠结兼容性问题了。最后分享一个排查待办问题的小技巧吧当用户报待办不见了我一般不看应用日志优先查两张表——ACT_RU_TASK和ACT_RU_IDENTITYLINK。先确认任务还在不在再确认任务和人到底是怎么关联的。任务在、关联丢了就是权限配置问题任务都不在了就看是流程推进走了还是被误删了。这两步做完八成的问题都能定位。工作流项目里数据本身会说话把表和业务逻辑对应起来排查效率真的会高很多。
