如果你因为项目接入了Flowable第一次打开数据库大概率会被那一堆以ACT_开头的表搞得有点懵。网上能找到的建表SQL一大把但真正把表结构和字段注释用中文整理清楚、能直接拿来用的脚本并不多。这篇博文就是我整理并验证过的Flowable表结构笔记和中文注释SQL脚本覆盖部署、流程定义、执行实例、任务、变量、历史归档这些最常用的表复制到对应数据库执行就能补上注释。适合刚开始做Flowable二次开发、排查数据库报错、或者想把表结构导入PowerDesigner做模型管理的同学。Flowable的表不是随便建的前缀已经帮你分好了类。把这套分组逻辑先搞清楚后面查任何表都有方向不会一上来就在几十张表里迷路。1. 先看懂Flowable表的分组逻辑后面才不会乱1.1 六类前缀对应六种职责Flowable的表前缀主要分六种ACT_GE_、ACT_RE_、ACT_RU_、ACT_HI_、ACT_ID_、ACT_EVT_。这六个前缀代表的是完全不同的数据职责理解清楚之后再查表基本可以做到“心里有数”。ACT_GE_General通用数据。比如ACT_GE_BYTEARRAY存流程文件的二进制内容ACT_GE_PROPERTY存引擎版本等属性信息任何引擎功能都可能用到所以叫通用。ACT_RE_Repository仓库数据。放的是流程部署记录、流程定义这类“不怎么变”的静态数据对应开发时常说的repositoryService。ACT_RU_Runtime运行时数据。流程启动后产生的执行实例、任务、变量、作业都在这里。流程结束后这些记录会被引擎自动清掉所以它是典型的“临时数据”。ACT_HI_History历史数据。流程从启动到结束的过程痕迹都会落到历史表里包括历史流程实例、历史任务、历史活动、历史变量。基本只增不删是做审计和流程回溯的主要数据源。ACT_ID_Identity身份数据。用户、用户组、用户和组之间的关系对应identityService。ACT_EVT_Event事件日志。记录引擎内部发生的各种事件主要用于调试和监控。为什么要把数据拆得这么碎因为这些数据生命周期差异太大了。ACT_RU_是高频增删ACT_HI_是只读归档ACT_RE_几乎不写如果混在几张表里数据库维护、备份、清理策略都会很难受。所以Flowable从一开始设计就把它们拆开了这不是为了炫技纯粹是工程需要。1.2 一次流程从部署到归档动过哪些表把一条完整流程拉通看一遍你就能理解这些表是怎么协作的。部署阶段调用repositoryService.createDeployment().addClasspathResource(xxx.bpmn20.xml).deploy()引擎会往ACT_RE_DEPLOYMENT插入一条部署记录同时把bpmn里解析出来的流程定义写进ACT_RE_PROCDEFbpmn的xml和流程图png的二进制内容存到ACT_GE_BYTEARRAY。启动阶段调用runtimeService.startProcessInstanceByKey引擎会在ACT_RU_EXECUTION创建根执行实例在ACT_RU_ACTINST写入当前停留活动节点如果需要的话如果流程里有定时器事件、信号事件还会写入对应的ACT_RU_TIMER_JOB、ACT_RU_EVENT_SUBSCR等表。任务流转走到用户任务ACT_RU_TASK会插入一条任务记录办理人、优先级、创建时间、截止时间都在这张表流程变量通过runtimeService.setVariable写入时会落到ACT_RU_VARIABLE。完成任务调用taskService.complete运行时任务表里的记录会被删除同时历史表ACT_HI_TASKINST、ACT_HI_ACTINST、ACT_HI_VARINST会写入对应的快照数据方便以后查“当时谁办了这件事”。流程结束整个流程实例走完后ACT_RU_EXECUTION里的执行记录清掉ACT_HI_PROCINST记录最终的开始时间、结束时间、耗时、结束原因。这里补充一个Spring Boot项目里很常见的点flowable-spring-boot-starter启动时会自动做表结构检查和版本校验如果数据库账号有DDL权限它会自动建表或升级如果生产环境DBA不给建表权限你就得手动执行官方对应版本的SQL脚本。这也是我为什么坚持要手头保留一份带中文注释的脚本交付、排障都比现场翻官方文档快得多。2. 主要表结构和字段注释逐个拆解2.1 静态仓库部署表和流程定义表先看部署表ACT_RE_DEPLOYMENT这是你每次部署新流程都会写入的第一张表。它的核心字段如下字段名类型注释ID_varchar(64)主键IDNAME_varchar(255)部署名称CATEGORY_varchar(255)分类KEY_varchar(255)部署KeyTENANT_ID_varchar(255)租户IDDEPLOY_TIME_timestamp(3)部署时间ENGINE_VERSION_varchar(255)流程引擎版本VERSION_int部署版本号PROJECT_RELEASE_VERSION_varchar(255)项目发布版本部署表本身不复杂但有两点值得注意一次部署可以同时打包多个bpmn文件所以ACT_RE_DEPLOYMENT的一条记录可能对应ACT_RE_PROCDEF里的多条流程定义KEY_和VERSION_是判断“这次部署是不是覆盖了老流程”的关键字段。如果你发现流程版本怎么升都不生效先来这张表排查部署记录是否真的插入成功了。接着是流程定义表ACT_RE_PROCDEF这是Flowable表里最常用的静态表之一核心字段如下字段名类型注释ID_varchar(64)主键IDREV_int版本号乐观锁CATEGORY_varchar(255)分类NAME_varchar(255)流程定义名称KEY_varchar(255)流程定义KeyVERSION_int流程定义版本DEPLOYMENT_ID_varchar(64)关联的部署IDRESOURCE_NAME_varchar(4000)bpmn文件路径DGRM_RESOURCE_NAME_varchar(4000)流程图资源名称DESCRIPTION_varchar(4000)描述HAS_START_FORM_KEY_bit是否有启动表单HAS_GRAPHICAL_NOTATION_bit是否有图形化信息SUSPENSION_STATE_int挂起状态1激活2挂起TENANT_ID_varchar(255)租户IDENGINE_VERSION_varchar(255)引擎版本RESOURCE_NAME_和DGRM_RESOURCE_NAME_在排障时特别有用。RESOURCE_NAME_是bpmn文件路径DGRM_RESOURCE_NAME_是流程图文件名称如果部署时只传了bpmn没生成流程图DGRM_RESOURCE_NAME_可能是空的。SUSPENSION_STATE_对应挂起/激活状态流程被人为挂起后在这里就能看到状态变化。VERSION_每次部署新版本都会递增同一个流程定义Key下引擎默认会使用最高版本这就是为什么你改了流程但老实例还在跑旧版本因为旧实例已经固化了流程定义ID。2.2 运行时核心执行实例、任务、变量ACT_RU_EXECUTION是运行时最核心的表它记录的是“流程当前执行到哪了”。核心字段如下字段名类型注释ID_varchar(64)主键ID执行实例IDREV_int乐观锁版本PROC_INST_ID_varchar(64)流程实例IDBUSINESS_KEY_varchar(255)业务主键PARENT_ID_varchar(64)父执行实例IDPROC_DEF_ID_varchar(64)流程定义IDSUPER_EXEC_varchar(64)上级执行实例IDROOT_PROC_INST_ID_varchar(64)根流程实例IDACT_ID_varchar(255)当前停留的活动节点IDIS_ACTIVE_bit是否激活IS_CONCURRENT_bit是否并发执行IS_SCOPE_bit是否为作用域执行实例IS_EVENT_SCOPE_bit是否为事件作用域SUSPENSION_STATE_int挂起状态TENANT_ID_varchar(255)租户IDNAME_varchar(255)执行实例名称START_TIME_datetime启动时间START_USER_ID_varchar(255)启动用户ID很多初学者容易把Execution和ProcessInstance搞混。简单理解ProcessInstance是顶层执行实例等于一条流程的“根”Execution是流程运转中的执行路径一个流程实例下可能挂着多个Execution。比如并行网关会分出多个分支每个分支就是一个Execution子流程被调用时父流程的Execution通过SUPER_EXEC_关联到子流程的Execution。ROOT_PROC_INST_ID_则是为了在多级嵌套流程里快速找到最顶层的那个流程实例。ACT_RU_TASK应该是日常查询最多的表了待办列表、任务处理都围绕它转。字段名类型注释ID_varchar(64)主键ID任务IDREV_int乐观锁版本EXECUTION_ID_varchar(64)执行实例IDPROC_INST_ID_varchar(64)流程实例IDPROC_DEF_ID_varchar(64)流程定义IDTASK_DEF_ID_varchar(64)任务定义IDNAME_varchar(255)任务名称PARENT_TASK_ID_varchar(64)父任务IDDESCRIPTION_varchar(4000)任务描述TASK_DEF_KEY_varchar(255)任务定义Key对应bpmn节点IDOWNER_varchar(255)任务创建人ASSIGNEE_varchar(255)当前办理人DELEGATION_varchar(64)委派状态PENDING表示存在委派PRIORITY_int优先级CREATE_TIME_datetime创建时间DUE_DATE_datetime截止时间CATEGORY_varchar(255)分类SUSPENSION_STATE_int挂起状态TENANT_ID_varchar(255)租户IDFORM_KEY_varchar(255)表单KeyCLAIM_TIME_datetime签收时间ASSIGNEE_和OWNER_的区别要分清OWNER_是创建任务的发起人ASSIGNEE_是当前要处理任务的人。DELEGATION_不为空时说明任务处于委派状态常见于把任务临时委派给别人处理。TASK_DEF_KEY_对应bpmn里用户节点的id比如“applyTask”这种代码里获取当前节点标识经常用到。还有一点必须记住ACT_RU_TASK里查不到已办任务任务完成就被删了要查历史去ACT_HI_TASKINST。ACT_RU_VARIABLE存的是流程运行中的变量参数传递就靠它。字段名类型注释ID_varchar(64)主键IDREV_int乐观锁版本TYPE_varchar(255)变量类型如string、integer、booleanNAME_varchar(255)变量名EXECUTION_ID_varchar(64)执行实例IDPROC_INST_ID_varchar(64)流程实例IDTASK_ID_varchar(64)任务IDSCOPE_ID_varchar(255)作用域IDSUB_SCOPE_ID_varchar(255)子作用域IDSCOPE_TYPE_varchar(255)作用域类型BYTEARRAY_ID_varchar(64)关联的二进制内容IDDOUBLE_doubledouble类型的变量值LONG_bigintlong类型变量值TEXT_varchar(4000)文本类型变量值TEXT2_varchar(4000)长文本变量值LAST_UPDATED_TIME_datetime最后更新时间Variable的值具体存在哪个字段取决于变量类型。基础类型直接对应LONG_、DOUBLE_、TEXT_字符串存TEXT_长文本可能存TEXT2_如果是序列化对象或自定义对象存BYTEARRAY_ID_实际数据在ACT_GE_BYTEARRAY里。这类变量字段在排查“变量为什么丢了”的时候很关键因为只要你查的是运行时变量表流程结束后记录就没了得去历史变量表找。2.3 历史归档流程实例、任务、活动、变量历史表是Flowable体系里最值钱的资产所有已经结束的流程状态都能在这里还原。ACT_HI_PROCINST是历史流程实例表相当于流程实例的“最终档案”。字段名类型注释ID_varchar(64)主键IDPROC_INST_ID_varchar(64)流程实例IDBUSINESS_KEY_varchar(255)业务主键PROC_DEF_ID_varchar(64)流程定义IDSTART_TIME_datetime开始时间END_TIME_datetime结束时间DURATION_bigint耗时单位毫秒START_USER_ID_varchar(255)发起人IDSTART_ACT_ID_varchar(255)开始节点IDEND_ACT_ID_varchar(255)结束节点IDSUPER_PROCESS_INSTANCE_ID_varchar(64)父流程实例IDDELETE_REASON_varchar(4000)删除原因TENANT_ID_varchar(255)租户IDNAME_varchar(255)流程实例名称END_TIME_为空说明流程还在运行DURATION_是结束时间减开始时间得到的毫秒数不用自己算。SUPER_PROCESS_INSTANCE_ID_用于子流程找回父流程做嵌套流程统计时经常用到。DELETE_REASON_能看出流程是被正常结束还是被人为删除的这个字段在审计场景里非常有用。ACT_HI_TASKINST是历史任务表结构和运行时任务表基本对应但多了任务维度的生命周期信息。字段名类型注释ID_varchar(64)主键IDTASK_DEF_ID_varchar(64)任务定义IDTASK_DEF_KEY_varchar(255)任务定义KeyPROC_INST_ID_varchar(64)流程实例IDEXECUTION_ID_varchar(64)执行实例IDNAME_varchar(255)任务名称PARENT_TASK_ID_varchar(64)父任务IDDESCRIPTION_varchar(4000)任务描述OWNER_varchar(255)任务创建人ASSIGNEE_varchar(255)办理人START_TIME_datetime任务开始时间CLAIM_TIME_datetime签收时间END_TIME_datetime任务结束时间DURATION_bigint任务耗时DELETE_REASON_varchar(4000)删除原因PRIORITY_int优先级DUE_DATE_datetime截止时间FORM_KEY_varchar(255)表单KeyCATEGORY_varchar(255)分类TENANT_ID_varchar(255)租户ID做“已办列表”和“待办统计”的报表基本上就是查这张表。注意START_TIME_是任务进入待办的时间CLAIM_TIME_是办理人签收的时间END_TIME_是任务完成时间。通过这三段时间差可以算出每个节点停留了多久做流程瓶颈分析很实用。ACT_HI_ACTINST是历史活动表记录流程实例执行过的每一个活动节点。字段名类型注释ID_varchar(64)主键IDPROC_DEF_ID_varchar(64)流程定义IDPROC_INST_ID_varchar(64)流程实例IDEXECUTION_ID_varchar(64)执行实例IDACT_ID_varchar(255)活动节点IDTASK_ID_varchar(64)关联的任务IDCALL_PROC_INST_ID_varchar(64)子流程实例IDACT_NAME_varchar(255)活动节点名称ACT_TYPE_varchar(255)活动类型如startEvent、userTaskASSIGNEE_varchar(255)办理人START_TIME_datetime节点开始时间END_TIME_datetime节点结束时间DURATION_bigint节点耗时TRANSACTION_ORDER_int事务顺序DELETE_REASON_varchar(4000)删除原因TENANT_ID_varchar(255)租户ID这张表是流程图高亮显示的数据基础。ACT_TYPE_告诉你节点是开始事件、用户任务、服务任务还是结束事件ACT_NAME_是节点显示名称。CALL_PROC_INST_ID_在调用子流程场景下可以关联到子流程的历史实例ID。排查“流程卡在哪个节点”查这张表最直接。ACT_HI_VARINST是历史变量表记录流程实例的变量快照。字段名类型注释ID_varchar(64)主键IDPROC_INST_ID_varchar(64)流程实例IDEXECUTION_ID_varchar(64)执行实例IDTASK_ID_varchar(64)任务IDNAME_varchar(255)变量名VAR_TYPE_varchar(100)变量类型REV_int乐观锁版本BYTEARRAY_ID_varchar(64)二进制内容IDDOUBLE_doubledouble类型值LONG_bigintlong类型值TEXT_varchar(4000)文本类型值TEXT2_varchar(4000)长文本值CREATE_TIME_datetime创建时间LAST_UPDATED_TIME_datetime最后更新时间为什么有了运行时变量表还要历史变量表因为审计要还原“当时这个变量的值是什么”。运行时表里的值会被覆盖历史表里保留了每次更新的痕迹虽然也只会保存最新版本或关键快照但已经能满足大多数追溯需求。3. 中文注释SQL脚本不同数据库怎么落地3.1 MySQL补注释的正确打开方式如果数据库是MySQL给已有表补注释主要用ALTER TABLE包括表级注释和字段注释。以部署表为例-- 表级注释 ALTER TABLE ACT_RE_DEPLOYMENT COMMENT 流程部署记录表; -- 字段级注释 ALTER TABLE ACT_RE_DEPLOYMENT MODIFY COLUMN ID_ varchar(64) NOT NULL COMMENT 主键ID, MODIFY COLUMN NAME_ varchar(255) DEFAULT NULL COMMENT 部署名称, MODIFY COLUMN CATEGORY_ varchar(255) DEFAULT NULL COMMENT 分类, MODIFY COLUMN KEY_ varchar(255) DEFAULT NULL COMMENT 部署Key, MODIFY COLUMN TENANT_ID_ varchar(255) DEFAULT COMMENT 租户ID, MODIFY COLUMN DEPLOY_TIME_ timestamp(3) NULL DEFAULT NULL COMMENT 部署时间, MODIFY COLUMN ENGINE_VERSION_ varchar(255) DEFAULT NULL COMMENT 流程引擎版本, MODIFY COLUMN VERSION_ int NOT NULL DEFAULT 1 COMMENT 部署版本号, MODIFY COLUMN PROJECT_RELEASE_VERSION_ varchar(255) DEFAULT NULL COMMENT 项目发布版本;这里有个非常容易踩的坑MODIFY COLUMN必须把字段的完整定义带上包括类型、是否允许为NULL、默认值。如果只写字段类型和COMMENT原来的默认值、精度、字符集都可能被覆盖掉严重时会影响引擎正常运行。我见过有人给DEPLOY_TIME_补注释时把timestamp(3)写成了timestamp结果时间精确到秒部分时间判断逻辑直接出问题。所以我的习惯是先执行SHOW CREATE TABLEACT_RE_DEPLOYMENT把原字段定义完整抄下来再在原定义基础上追加COMMENT。补完注释后用下面这条SQL验证注释是否生效SHOW FULL COLUMNS FROM ACT_RE_DEPLOYMENT;如果是要批量给多张表补注释不要直接在开发环境手敲建议把脚本存成.sql文件在测试库先跑一遍确认没有语法问题再上生产。生产环境数据量大时ALTER TABLE可能会锁表或耗时较长尽量安排在业务低峰期执行。3.2 达梦/Oracle风格的COMMENT ON写法有些项目用的是达梦数据库特别是兼容Oracle模式的环境语法风格和MySQL差别很大。MySQL用MODIFY COLUMN加COMMENT达梦/Oracle则用COMMENT ON语句独立修改注释不动字段定义反而更安全-- 表级注释 COMMENT ON TABLE ACT_RE_DEPLOYMENT IS 流程部署记录表; -- 字段级注释 COMMENT ON COLUMN ACT_RE_DEPLOYMENT.ID_ IS 主键ID; COMMENT ON COLUMN ACT_RE_DEPLOYMENT.NAME_ IS 部署名称; COMMENT ON COLUMN ACT_RE_DEPLOYMENT.CATEGORY_ IS 分类; COMMENT ON COLUMN ACT_RE_DEPLOYMENT.KEY_ IS 部署Key; COMMENT ON COLUMN ACT_RE_DEPLOYMENT.TENANT_ID_ IS 租户ID; COMMENT ON COLUMN ACT_RE_DEPLOYMENT.DEPLOY_TIME_ IS 部署时间; COMMENT ON COLUMN ACT_RE_DEPLOYMENT.ENGINE_VERSION_ IS 流程引擎版本; COMMENT ON COLUMN ACT_RE_DEPLOYMENT.VERSION_ IS 部署版本号; COMMENT ON COLUMN ACT_RE_DEPLOYMENT.PROJECT_RELEASE_VERSION_ IS 项目发布版本;这套语法在Oracle和PostgreSQL里也是通用的唯一要注意的是双引号里的表名和字段名大小写必须和实际定义完全一致。达梦在Oracle兼容模式下大小写敏感问题比较突出建议先执行下面的查询确认一下字段大小写SELECT COLUMN_NAME, DATA_TYPE, COMMENTS FROM ALL_COL_COMMENTS WHERE TABLE_NAME ACT_RE_DEPLOYMENT;提示不要在一份脚本里混用MySQL的COMMENT关键字和COMMENT ON COLUMN语法。PowerDesigner导入时脚本里一旦混了多种数据库方言解析器很容易报错或丢失注释。3.3 用脚本生成PowerDesigner的PDM很多团队喜欢用PowerDesigner管理表结构把Flowable的表结构导入生成PDM后出设计文档、做评审都方便。我的操作路径是把整理好的SQL脚本保存成.sql文件编码选UTF-8避免中文注释乱码。打开PowerDesignerFile - Reverse Engineer - Database。选择对应的DBMSMySQL脚本选MySQL达梦/Oracle风格的COMMENT ON脚本选Oracle或对应达梦模板。在导入方式里选Using script files加载刚才的SQL文件。导入完成后字段的Comment会被解析到PDM里。如果发现注释没有识别出来最常见的原因是脚本里混了其他数据库方言第二种是文件编码不对。还有一个很实用的小技巧PDM生成后在模型里让Name显示中文注释、Code保留字段名团队成员看模型图的时候一眼就知道这张表是干什么的不需要逐个字段对英文名猜含义。如果是从达梦表结构生成PDM我自己试过几种方式最省事的是先通过达梦的导出工具把表定义导出成Oracle或标准SQL脚本再用PowerDesigner的Oracle模板导入比直接用达梦专用驱动稳定很多。4. 别只抄注释索引和数据生命周期同样重要4.1 ACT_RU_表为什么不能无限堆积很多项目跑了一段时间后会发现ACT_RU_TASK、ACT_RU_EXECUTION表的数据量越来越大数据库越来越慢。这不一定是Flowable出了问题而是流程没正常走完运行时数据积压了。正常情况下一个流程实例结束后引擎会清理掉对应的ACT_RU_EXECUTION、ACT_RU_TASK、ACT_RU_VARIABLE记录。但如果流程卡在某个用户任务一直没人处理、某个SERVICE TASK抛异常导致流程实例挂住、或者代码里只创建了流程实例但没调completeTask这些运行表里的记录就会一直留着。排查思路很简单先查ACT_HI_PROCINST里END_TIME为空的记录有多少对比一下哪个流程定义下未完成实例最多再查ACT_RU_TASK看这些实例到底停在哪个节点上。开发环境可以直接清理生产环境要先处理业务能正常完成任务就走完流程实在无法继续的才用runtimeService.deleteProcessInstance删除。删除后ACT_RU_表的数据会清掉但ACT_HI_历史记录还在方便追溯。还有一点想提醒不要为了图省事直接执行DELETE FROM ACT_RU_TASK来“清理待办”。这样会导致引擎内存状态和数据库不一致流程实例后续根本无法继续流转后面的任务、变量全都会对不上排查起来比原来麻烦十倍。运行表自带的索引也不要随便动。官方建表脚本里自带的索引都是按引擎查询路径设计的比如ACT_IDX_HI_PRO_INST_END、ACT_IDX_RU_TASK_CREATE_TIME这类我见过有团队为了“优化”把历史表索引删掉结果流程查询接口直接慢到超时。如果要加索引建议针对自己的业务字段加而不是动引擎默认索引。4.2 历史表保留策略和清理顺序ACT_HI_*表只增不删时间长了磁盘占用非常可观。尤其ACT_HI_ACTINST几乎每个节点执行都会写记录数据量增长很快。比较稳妥的保留策略是按END_TIME清理已经结束且超过保留期的流程实例。比如业务规定历史数据保留6个月就写一个定时任务分页扫描ACT_HI_PROCINST中END_TIME小于当前时间减6个月的记录调用historyService.deleteHistoricProcessInstance(processInstanceId)删除。引擎会级联删除ACT_HI_TASKINST、ACT_HI_ACTINST、ACT_HI_VARINST等子表记录比自己手工删SQL安全得多。如果数据量特别大注意不要一次性把删除范围铺太宽每批处理几十到几百条然后停顿一下避免长时间占用数据库连接和行锁。Flowable自身也有HistoryCleanupManager相关的清理Job但默认行为在不同版本里有差异我建议还是自己在项目里用Spring定时任务控制逻辑清晰出了问题也好排查。这里特别提醒ACT_GE_PROPERTY和ACT_RE_PROCDEF两张表不要动。ACT_GE_PROPERTY存着引擎的schema版本删了或改了会让引擎认为数据库版本不匹配启动直接报错ACT_RE_PROCDEF是流程定义元数据你只是清理历史实例没必要也不应该碰这两张表。5. 常见数据库报错排查实录5.1 高频报错速查表报错现象可能原因处理思路启动报Table ACT_GE_PROPERTY doesnt exist数据库没有初始化Flowable表结构手动执行官方对应版本的create脚本或临时放开自动建表配置Unknown column PROJECT_RELEASE_VERSION_ in field list引擎版本和数据库脚本版本不一致到Flowable官方对应版本目录执行upgrade脚本或统一降级到一致版本no processes deployed with key xxxACT_RE_PROCDEF里没有对应流程定义记录确认部署是否成功查ACT_RE_DEPLOYMENT和ACT_RE_PROCDEF确认SUSPENSION_STATE_是否为1任务查询查不到已办数据查错表了ACT_RU_TASK只保存未完成任务已办任务改用ACT_HI_TASKINST查询删除历史数据报外键约束删除顺序不对子表数据还在先删ACT_HI_VARINST、ACT_HI_ACTINST、ACT_HI_TASKINST再删ACT_HI_PROCINST数据库类型无法识别报couldnt deduct database typeFlowable不认识当前数据库方言手动配置databaseType或升级到支持该数据库的Flowable版本5.2 我的排查习惯接到Flowable数据库相关的报错我一般不会盯着异常堆栈的最后一行反复看按下面几步走大多数问题都能定位。第一步先看ACT_GE_PROPERTY里的schema.version字段和项目里flowable的版本做对比。如果版本对不上大概率是升级流程没走完缺了升级脚本。版本不匹配是Flowable最常见的数据库报错来源没有之一。第二步打开debug日志重点看org.flowable.engine.impl.db这个包。Flowable执行DDL和DML的细节都会在这里打印能清楚看到它到底执行了哪些建表语句、是不是在启动阶段因为权限不足被拦下了。第三步判断是运行时表的问题还是历史表的问题。很多“任务消失”“数据没了”的报错其实是查的时候用了运行表但流程已经结束了运行表数据被引擎清掉这时候去ACT_HI_TASKINST肯定能找到记录。最后说一个我已经坚持很久的习惯每次升级Flowable版本先在测试库跑一遍初始化脚本确认没有报错然后把ACT_GE_PROPERTY里的版本号、主要表的中文注释脚本、表结构快照一起提交到项目的文档库里。这样后面任何人接手查表结构都不需要翻源码直接看这套注释脚本就行。注释脚本本身是一件一次整理、长期受益的事别嫌麻烦值得花半天时间好好做完。