Flowable 6.7.2数据库建表SQL脚本详解：MySQL与Oracle实操指南

简介面向使用Flowable 6.7.2工作流引擎的Java开发人员这份压缩包提供了分别适配MySQL与Oracle两种主流数据库的初始化建表SQL脚本能够一键创建流程定义表、运行时表、历史表、变量表、事件表及辅助表等核心数据表帮助开发者快速完成引擎部署的数据库环境准备避免手动建表带来的遗漏与类型不兼容问题。包内共2个SQL文件按官方版本整理可直接导入对应数据库执行整体仅17KB轻量易用。已有1826人学习下载。深入查看脚本可理解Flowable对流程部署、实例运行、任务处理及历史归档的底层存储设计便于后续排查问题、做数据统计和二次功能扩展适合正在集成Flowable或准备做流程平台改造的技术人员。 拿到这个flowable-6.7.2数据库建表sql脚本mysqloracle.zip的时候多数人的第一反应是“终于不用让应用自动建表了”但真正打开压缩包后面对满屏的ACT_*开头的建表语句又容易卡在“先执行哪个文件”“为什么报外键错误”“Oracle 那边为什么老是缺表空间”这些细节上。这篇博文就围绕这套 6.7.2 的 MySQL 和 Oracle 脚本把建表原理、执行顺序、环境准备、常见坑一次讲清楚适合正在做 Java 后端、OA 项目、审批流模块或者刚把 Flowable 引入 Spring Boot 项目的同学参考。1. 拿到脚本包之前Flowable 6.7.2 为什么这么依赖数据库表Flowable 本身是一个工作流与 BPMN 流程引擎它的核心运行逻辑是从流程定义文件中解析节点然后按节点状态推进流程。所有流程实例、任务、变量、历史记录都要持久化到数据库里所以数据库表结构被设计成流程引擎的“地基”。6.7.2 这个版本在 6.x 系列里属于比较成熟稳定的迭代修复了不少历史版本里流程实例并发、历史数据清理方面的问题同时保留了良好的向后兼容性很多线上项目选型时会特意避开过新的版本专门锁定到 6.7.x。1.1 自动建表与手动建表的取舍Flowable 有两种建表方式一种是应用启动时自动检测并创建缺失的表另一种是预先手工执行 SQL 脚本完成表结构初始化。自动建表在开发环境很方便只要在配置里打开database-schema-update相关开关应用一启动引擎会检查ACT_GE_PROPERTY表中记录的 schema 版本发现对不上就自动执行建表或升级脚本。生产环境我一般不建议开自动建表原因有三个一是数据库账号通常没有 DDL 权限二是自动建表过程不可控三是出问题后难以回溯谁在什么时候改了表结构。手动执行脚本的方式等于把“地基施工”拿到应用部署之前单独做完流程引擎启动时只做版本校验速度更快也更容易纳入数据库版本管理工具统一维护。这个 zip 包的价值就在这里它把 6.7.2 在两个主流数据库上的完整表结构固化成了可重复执行的 SQL 脚本配合 Flyway、Liquibase 这类迁移工具可以做到表结构变更可控、可审计。1.2 脚本来源与包里通常有什么这套 6.7.2 的建表脚本实际来源于 Flowable 引擎发布包内部的org/flowable/db/create目录很多刚接触的人不知道这一点以为网上流传的脚本是第三方整理的其实它是引擎自带的资源。你可以从 Maven 仓库下载flowable-engine-6.7.2.jar解压后到对应目录里找到全部脚本也可以直接用网上打包好的 zip。压缩包里一般会按数据库类型分子目录常见结构类似这样flowable-6.7.2-database/ ├── mysql/ │ ├── flowable.mysql.create.engine.sql │ ├── flowable.mysql.create.history.sql │ ├── flowable.mysql.create.identitylink.sql │ ├── flowable.mysql.create.entitylink.sql │ ├── flowable.mysql.create.identity.sql │ ├── flowable.mysql.create.job.sql │ ├── flowable.mysql.create.form.sql │ ├── flowable.mysql.create.dmn.sql │ ├── flowable.mysql.create.app.sql │ ├── flowable.mysql.create.eventsubscription.sql │ ├── flowable.mysql.drop.*.sql │ └── flowable.mysql.upgrade.*.sql └── oracle/ ├── flowable.oracle.create.*.sql ├── flowable.oracle.drop.*.sql └── flowable.oracle.upgrade.*.sql执行顺序不是随意的需要先创建引擎基础表再建历史表、任务相关的表最后是表单、DMN、App、事件订阅等扩展模块的表。如果顺序反了很容易因为外键依赖找不到父表而报错。后面第 2、3 节我会把两个数据库的具体执行方法和顺序拆开讲。2. MySQL 环境从建库到表结构验证MySQL 是 Flowable 使用率最高的数据库网上绝大多数教程、Demo 案例也都是基于 MySQL 演示的。但正因为用的人多踩过的坑也五花八门主要集中在字符集、存储引擎、表名大小写、外键依赖这几个地方。2.1 建库、账号与字符集的三个关键选择先确定数据库版本。Flowable 6.7.2 对 MySQL 5.7 和 MySQL 8.0 都支持良好我实际使用下来5.7 和 8.0 在执行建表脚本上没什么差别但 8.0 默认字符集就是utf8mb4更省事。如果你还在用 MySQL 5.6建议先升级5.6 的优化器对复杂流程查询支持不理想跑历史流程实例查询时性能会明显吃力。建库时字符集建议直接用utf8mb4排序规则可以选utf8mb4_bin或utf8mb4_general_ci。很多人习惯用utf8但utf8在 MySQL 里最多存 3 字节流程变量里如果包含 emoji 或部分生僻字就会报Incorrect string value错误。流程引擎的表单数据五花八门谁也没法保证用户不会往备注里塞一个 emoji所以从一开始就建utf8mb4库最稳妥。CREATE DATABASE flowable DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER flowable% IDENTIFIED BY YourStrongPass; GRANT ALL PRIVILEGES ON flowable.* TO flowable%; FLUSH PRIVILEGES;给应用用的账号建议直接授权当前库的全部权限避免细粒度授权遗漏导致引擎启动时报权限不足。如果公司安全规范比较严至少要授予SELECT、INSERT、UPDATE、DELETE、CREATE、ALTER、INDEX、REFERENCES这几项。存储引擎方面表结构脚本里默认用的就是 InnoDB要保持默认不要改。Flowable 的流程实例、任务、变量都是事务性数据InnoDB 提供事务和行级锁MyISAM 不支持事务一旦流程推进中途崩掉数据一致性会出大问题。2.2 执行脚本的正确顺序与常用命令拿到 zip 里的 MySQL 脚本后推荐按下面的顺序执行。如果某个模块用不到比如不用 DMN 决策引擎可以跳过对应脚本但引擎核心脚本必须完整执行。我习惯的执行顺序是flowable.mysql.create.engine.sqlflowable.mysql.create.history.sqlflowable.mysql.create.identitylink.sqlflowable.mysql.create.entitylink.sqlflowable.mysql.create.identity.sqlflowable.mysql.create.job.sqlflowable.mysql.create.form.sqlflowable.mysql.create.dmn.sqlflowable.mysql.create.app.sqlflowable.mysql.create.eventsubscription.sql为什么建议先建engine和history因为这两类表是流程引擎最核心的运行时与历史数据载体后面建的表比如实体关联、事件订阅很多都依赖它们的外键关系。实际执行时可以直接用 MySQL 命令行重定向文件mysql -uflowable -p flowable flowable.mysql.create.engine.sql mysql -uflowable -p flowable flowable.mysql.create.history.sql也可以把多个脚本合并成一个文件一次性执行但前提是你已经确认过合并后的顺序没问题。用 Navicat 或 DataGrip 的话直接打开脚本文件选中全部执行就行。我建议一条一条执行某个步骤报错时能立刻定位到具体文件。2.3 建完怎么确认表清单与版本记录执行完成后先确认表数量。Flowable 6.7.2 在 MySQL 上的表总数大约是 70 张左右具体会因模块选择有浮动但引擎核心表不会少。用下面的 SQL 可以快速统计SELECT COUNT(*) FROM information_schema.tables WHERE table_schema flowable AND table_name LIKE ACT\_%;重点查看ACT_GE_PROPERTY表里面会存一行schema.version正常情况下值是6.7.2.0这表示引擎版本与表结构版本匹配。如果这里显示的值和实际引擎版本不一致启动时 Flowable 会直接抛出版本校验异常这是个非常典型的排查入口。另外还可以抽查核心表比如ACT_RU_EXECUTION、ACT_RU_TASK、ACT_HI_PROCINST是否建好。到了这一步MySQL 环境就算初始化完成了。接下来准备接入 Spring Boot 时把配置里的database-schema-update设为false引擎启动后只做版本校验不再自动改表线上行为完全可控。3. Oracle 环境表空间、CLOB 与执行细节Oracle 环境的建表脚本相比 MySQL 要麻烦不少主要原因是 Oracle 对用户、表空间、字符集、权限的管理模式更复杂而且 Flowable 的 Oracle 脚本里包含了大量VARCHAR2和CLOB字段不同版本对字段长度的处理逻辑也不同。很多第一次在 Oracle 上部署 Flowable 的同学卡在脚本执行之前的准备阶段就已经崩溃了。3.1 用户、表空间和权限的准备工作Oracle 里先建表空间再建用户然后把用户的默认表空间指过去。这个顺序不能乱。表空间大小建议根据业务量规划一般生产环境至少 10GB 起步开发环境 1GB 左右够用。创建语句类似CREATE TABLESPACE FLOWABLE_DAT DATAFILE /u01/app/oracle/oradata/ORCL/flowable01.dbf SIZE 1G AUTOEXTEND ON NEXT 100M MAXSIZE 10G;创建用户时注意如果是 Oracle 12c 及以上版本默认会有CDB和PDB的概念。如果是在可插拔数据库里建用户用户名需要带C##前缀除非你专门设置了COMMON_USER_PREFIX参数。Flowable 官方文档里的例子通常基于 11g没有这个前缀很多人在 12c/19c 上照抄文档报ORA-65096错误就是因为这个原因。建议先确认当前会话所在容器再决定用户名格式。CREATE USER flowable IDENTIFIED BY YourStrongPass DEFAULT TABLESPACE FLOWABLE_DAT QUOTA UNLIMITED ON FLOWABLE_DAT; GRANT CONNECT, RESOURCE TO flowable; GRANT CREATE TABLE, CREATE SEQUENCE, CREATE VIEW, CREATE PROCEDURE TO flowable;这里有个容易忽略的点RESOURCE角色默认包含UNLIMITED TABLESPACE权限但如果你是用QUOTA UNLIMITED ON FLOWABLE_DAT限定了单独表空间配额也要确保默认表空间配额足够大。执行过程中一旦出现ORA-01950: no privileges on tablespace基本就是配额没给够。3.2 执行脚本与避开 Oracle 特有坑Oracle 脚本同样分模块存放执行顺序和 MySQL 一致但执行方式不同。最省事的方式是用 SQL*Plussqlplus flowable/YourStrongPassORCL flowable.oracle.create.engine.sqlOracle 脚本里用到的CREATE TABLE IF NOT EXISTS类似语法和 MySQL 不同Oracle 不支持IF NOT EXISTSFlowable 官方脚本是靠BEGIN EXECUTE IMMEDIATE ... EXCEPTION WHEN OTHERS THEN NULL; END;这种匿名块来做存在性判断的所以千万别把脚本里的WHENEVER SQLERROR EXIT之类的控制语句去掉否则中途报错不会自动停止后面的脚本继续跑建表结果很难判断。Oracle 上最常见的坑有三个。第一个是VARCHAR2长度的字节与字符问题Oracle 中VARCHAR2(255)默认按字节算如果数据库字符集是AL32UTF8一个中文字符占 3 字节那么VARCHAR2(255)只能存约 85 个汉字。Flowable 脚本里涉及名称、备注的字段基本都是VARCHAR2如果大量中文流程定义名称被截断就会有问题。建议建库时统一字符集或者提前确认NLS_LENGTH_SEMANTICS是否为CHAR。第二个是CLOB字段问题。Flowable 的变量值、二进制内容、表单定义会存到 CLOB/BLOB 字段里Oracle 的CLOB操作相比 MySQL 的TEXT要麻烦一些特别是后续用 JDBC 写入大对象时如果使用框架不当会报ORA-01461: can bind a LONG value only for insert into a LONG column。这个通常是驱动的SetBigStringTryClob参数没配置好跟建表脚本本身无关但很多人误以为是表结构有问题容易排查方向跑偏。第三个是表空间使用率。Oracle 表空间如果没开自动扩展流程数据一涨就容易报ORA-01653: unable to extend table所以在执行建表脚本之前就要把自动扩展打开避免业务跑了一段时间后突然暴毙。3.3 建表结果验证与常见异常Oracle 里验证建表是否成功推荐查user_tables视图SELECT COUNT(*) FROM user_tables WHERE table_name LIKE ACT\_% ESCAPE \;这个查询结果会统计当前用户下所有ACT_开头的表。还应该查一下ACT_GE_PROPERTY的内容确认schema.version是6.7.2.0。如果统计数量和预期差很多先看脚本执行时是不是有错误被忽略了。可以在执行完所有脚本后重新逐条执行 create 脚本观察是否出现ORA-00955: name is already used by an existing object如果大量出现说明之前已经执行过一部分跳过即可。异常方面ORA-00942: table or view does not exist通常是因为脚本执行顺序不对或者当前用户没有权限读取其他用户下的表ORA-01536: space quota exceeded for tablespace就是配额问题ORA-02449: unique/primary keys in table referenced by foreign keys则是删除或重建表时外键没处理干净。这些都属于 Oracle 日常操作里会遇到的常见问题排查思路不复杂但实际案例里出现频率相当高。4. 建表之后从表格走向业务开发表结构虽然建好了但很多开发人员对ACT_*表的业务含义并不熟悉写 SQL 查询、做报表统计时经常摸不着头脑。这里花点时间把核心表梳理一下再聊聊和 Activiti 的区别以及 Spring Boot 整合时如何管理表结构这对后续业务开发非常关键。4.1 Flowable 6.7.2 核心表分类与速览Flowable 6.7.2 的表可以分成几个大类分类表名前缀典型表作用通用数据ACT_GE_ACT_GE_BYTEARRAY、ACT_GE_PROPERTY二进制内容、引擎版本属性流程定义ACT_RE_ACT_RE_DEPLOYMENT、ACT_RE_PROCDEF部署包、流程定义运行实例ACT_RU_ACT_RU_EXECUTION、ACT_RU_TASK、ACT_RU_VARIABLE当前运行中的流程、任务、变量历史数据ACT_HI_ACT_HI_PROCINST、ACT_HI_TASKINST、ACT_HI_ACTINST已结束或运行中的历史记录身份数据ACT_ID_ACT_ID_USER、ACT_ID_GROUP用户、组信息表单、DMN、AppACT_FO_、ACT_DMN_、ACT_APP_对应模块的业务数据扩展引擎使用业务开发中重点关心的是ACT_RU_TASK和ACT_HI_PROCINST。待办列表就是查ACT_RU_TASK根据当前审批人关联的候选人、办理人过滤历史流程列表就是查ACT_HI_PROCINST配合ACT_HI_ACTINST查看节点审批记录。很多同学会用 Flowable 的TaskQueryAPI 做查询但遇到多表关联、复杂统计报表时直接写 SQL 查这几张表效率往往更高。这里也顺便回答一个常见问题Flowable 能不能写 SQL答案是肯定的引擎本身也支持自定义 mapper但要注意不要在引擎事务里混用太复杂的原生 SQL避免事务锁表时间过长。4.2 和 Activiti 的区别老项目迁移时要注意什么Flowable 和 Activiti 的关系经常被拿来对比。简单说Flowable 是从 Activiti 5 的社区分支发展而来的后来 Activiti 进入了新的商业化路线两边的表结构、API 就逐渐分叉了。对于做过 Activiti 6 项目的团队来说迁移到 Flowable 6.7.2 有一个很直接的感受表结构前几个核心模块基本能对上但历史表、身份表和事件订阅部分的字段有明显差别。比如 Flowable 在ACT_HI_PROCINST里增加了不少业务状态相关字段ACT_ID_*身份模块也比 Activiti 更完善。如果老项目里直接写了大量针对 Activiti 表的 SQL 报表迁移时不能只换依赖还得同步改 SQL。另外Flowable 的社区活跃度、版本迭代速度、对 Spring Boot 的适配都更积极6.7.2 这个版本在大量项目中验证过稳定性和踩坑资料的丰富程度都更有优势。4.3 Spring Boot 整合 Flowable 时的表管理策略实际项目里Flowable 很少独立部署基本都是嵌在 Spring Boot 应用里。引入flowable-spring-boot-starter之后配置文件里有一个关键参数spring.flowable.database-schema-update可选值包括true、false、create-drop。开发环境图省事可以设true但生产环境建议设false配合手动执行的建表脚本把表结构变更完全收敛到数据库迁移流程里。spring: datasource: url: jdbc:mysql://localhost:3306/flowable?useUnicodetruecharacterEncodingutf8 username: flowable password: YourStrongPass flowable: database-schema-update: false async-executor-activate: falseasync-executor-activate如果不需要异步任务建议也关掉减少不必要的线程开销。启动后观察日志正常情况会出现Flowable 6.7.2.0 database schema update successful或version mismatch之类的提示。没有报错就说明表结构校验通过。另一个常见策略是把建表脚本纳入 Flyway 的迁移脚本体系这样应用部署时会自动执行迁移同时保证多个环境表结构一致我现在的项目就是这么做的。5. 实操心得与常见问题速查最后聊几个实际运维和开发中反复出现的问题这些话在官方文档里不一定写得很直白但都是实战里会卡住人的点。5.1 我踩过的三个坑第一个坑是 MySQL 大小写敏感问题。因为我曾经在 Linux 服务器上部署MySQL 的lower_case_table_names默认值是 0表名区分大小写。Flowable 脚本里表名全是大写但业务代码里手动写的 SQL 一旦用了小写就会报表不存在。后来我在my.cnf里设置了lower_case_table_names1但要注意这个参数修改后需要重启实例而且影响所有库。如果不想动全局配置就只能约定业务 SQL 一律使用大写表名。这个坑在开发环境 Mac 和 Windows 上不明显因为默认配置不同上线到 Linux 才暴露。第二个坑是 MySQL 8.0 的字符集排序规则。Flowable 引擎启动时会对字符串类型字段做排序如果排序规则不一致联表查询可能报Illegal mix of collations。建议全库统一一个排序规则别混用utf8mb4_general_ci和utf8mb4_unicode_ci按我之前测试统一用utf8mb4_bin或utf8mb4_general_ci都没有问题关键是全库一致。第三个坑是 Oracle 12c 里C##用户前缀导致的脚本问题。我不是没有在 PDB 里创建了不带前缀的用户结果脚本执行时报权限不足后来才意识到默认容器在 CDB 里需要ALTER SESSION SET CONTAINER pdbname;或者直接用 PDB 服务名连接再创建用户。这个坑最容易在“本地开发用 11g生产用 19c”的项目里爆发。5.2 常见问题速查表现象可能原因处理建议MySQL 执行脚本报外键错误建表顺序不对先执行业务核心模块 create再按依赖顺序执行检查是否有历史残留表中文乱码或 emoji 报错字符集不是 utf8mb4重建库、指定 utf8mb4检查连接串是否带 characterEncodingutf8启动报 schema version mismatch引擎版本和表结构版本不一致查ACT_GE_PROPERTY确认schema.version使用一致的 6.7.2Oracle 报 ORA-01950表空间配额不足给用户QUOTA UNLIMITED ON 表空间Oracle 报 ORA-6509612c 用户前缀问题确认当前容器使用C##前缀或切换到 PDB执行完脚本表数量为 0脚本执行时未选择正确 schemaMySQL 确认 use databaseOracle 确认当前用户权限与连接串异步任务不触发async-executor-activatefalse按需开启异步执行器并确认ACT_RU_JOB表有数据待办查询性能差缺少索引或 SQL 写法问题对ACT_RU_TASK的ASSIGNEE_、CREATE_TIME_等字段建索引根据我个人经验如果是第一次在生产环境部署 Flowable 6.7.2最建议的路径是先在一台干净的测试机上手动执行完整建表脚本把ACT_GE_PROPERTY的版本记录截个图存档然后启动 Spring Boot 应用做版本校验确认无报错后再把相同脚本应用到生产环境的数据库迁移流程里。这套流程跑通一次后面即使遇到环境差异也能快速定位问题。建表脚本本身不复杂真正的复杂度全在环境差异和版本匹配上提前把这两点控制住Flowable 落地就成功了一大半。本文还有配套的精品资源点击获取