简介面向Flowable工作流引擎的MySQL与Oracle数据库建表脚本包针对6.7.2版本量身定制解决部署时手工建表易缺漏、结构不统一的问题同时兼顾两种主流数据库的语法差异适合需要快速初始化流程引擎环境的Java开发人员及运维人员。压缩包仅17KB内含2个独立SQL脚本分别对应MySQL与Oracle脚本完整覆盖流程定义、运行时任务、历史实例、流程变量、事件订阅及通用二进制存储等核心表族并对Oracle特有数据类型与约束做了细致适配。已有1832人学习使用按自身连接信息调整库名和用户名后即可完成环境初始化部署门槛较低。借助这些脚本开发者既能快速搭建Flowable基础数据层也能通过清晰的表结构划分掌握流程部署、任务流转、历史归档与变量管理的内在机制为后续性能调优和业务定制提供直接依据。整个包结构精简利落便于直接纳入现有工程或交付文档。1. flowable 6.7.2 建表脚本先搞懂这包东西解决什么问题部署一个 flowable 6.7.2最容易被忽视的就是数据库层。引擎代码拿到手、配置文件写好、一启动就报 ACT_GE_PROPERTY 表不存在——这种翻车我在本地环境见过太多次。这个 zip 解决的就是这件事把 MySQL 和 Oracle 两套建表 SQL 一起给你省去从多个 JAR 包里逐个翻 DDL 文件的功夫也避开了不同模块脚本散落导致的漏建、乱序问题。它本质上是一份离线初始化的数据库 DDL 包。你要做的不是改代码而是根据目标数据库挑对应脚本在一个空库或新 schema 上完整执行一遍得到一套 flowable 认可的元数据表结构。之后引擎才能部署流程定义、启动流程实例、记录每个任务的审批轨迹。这个包适合刚接触 flowable、想快速入门的新手也适合手上有现成 MySQL 或 Oracle 实例、要把流程引擎接进业务系统的运维和后端开发。尤其值得关注的是 Oracle 环境源码包里的 DDL 分散在 flowable-engine、flowable-identitylink、flowable-job-service 等多个模块里手工合并比直接用整合好的 SQL 脚本更容易踩坑。下面我会按表结构逻辑、两库执行步骤、高频报错和最终验证四条线来讲。2. 这包脚本背后的表结构四类前缀表和两套方言的差异逻辑2.1 ACT_RE_、ACT_RU_、ACT_HI_、ACT_GE_flowable 的表是怎么分工的Flowable 6.x 的表名统一以 ACT_ 开头第二段前缀直接告诉你归属。ACT_ 来自 “ACTivity”沿用了 Activiti 时代的命名习惯到了 flowable 6.7.2 依然没有变。ACT_RE_ 是 Repository 仓库域存的是“定义类”数据。ACT_RE_DEPLOYMENT 记录一次部署动作ACT_RE_PROCDEF 存流程定义本身ACT_RE_MODEL 存模型。你在 flowable 模型设计器里画一张流程图并部署落库的首先就是这几张表。它们在整个生命周期里写入频率不高但查询频率不低因为引擎每次启动流程都要根据 processDefinitionKey 去 ACT_RE_PROCDEF 里找定义。ACT_RU_ 是 Runtime 运行时域也是引擎读写最频繁的一组。ACT_RU_EXECUTION 存流程实例和执行分支ACT_RU_TASK 存待办任务ACT_RU_VARIABLE 存流程变量ACT_RU_JOB 存定时作业。一个流程实例从创建到结束每一步流转都伴随这些表的增删改。性能问题通常也集中在这一域比如任务量大时 ACT_RU_TASK 的 CNT 查询慢。ACT_HI_ 是 History 历史域记录已经发生过的动作。流程实例结束、任务完成后数据从 ACT_RU_ 迁移到 ACT_HI_PROCINST、ACT_HI_TASKINST、ACT_HI_ACTINST、ACT_HI_DETAIL 等表。报表、审计、流程追踪查的都是这一域。ACT_GE_ 是 General 通用域包含 ACT_GE_PROPERTY 属性表和 ACT_GE_BYTEARRAY 二进制表。前者存引擎版本、ID 生成规则等全局属性后者存部署包里的 BPMN XML 原文件。很多人在排查部署问题时会忽略 ACT_GE_BYTEARRAY其实部署的内容都以二进制形式存在这里。除了这四类还有 ACT_ID_ 身份域、ACT_CMMN_ 案例管理、ACT_DMN_ 决策表、ACT_APP_ 应用定义等。具体建多少张表取决于你引入的模块如果只是跑标准审批流核心表就够用但如果启动的是带 DMN 决策的整合包ACT_DMN_* 这组也必须建齐。zip 里的脚本把哪几个域合并到了一起以实际文件为准我建议动手前先把脚本清单完整过一遍避免只挑“看着核心”的文件执行。2.2 MySQL 与 Oracle 两套脚本为什么不能互换从自增主键到 CLOB 的类型对照同一个 6.7.2 版本要同时支持 MySQL 和 Oracle脚本必然不是简单复制而是在类型系统和数据库特性上都做了适配。下表是我整理的两库差异要点对照着看会很清楚差异点MySQL 版脚本Oracle 版脚本主键生成AUTO_INCREMENT 自增列NUMBER 类型 SEQUENCE 序列 TRIGGER 触发器自动赋值字符串类型VARCHAR(n)VARCHAR2(n)大文本字段LONGTEXTCLOB日期时间DATETIME / TIMESTAMPTIMESTAMP / DATE布尔语义TINYINT(1) 的 0/1NUMBER(1) 的 0/1空串处理空串与 NULL 是两个值空串会被隐式转换为 NULL字符串大小写比较取决于 collation默认不敏感默认大小写敏感对象命名长度表名最长 64 字符12.1 及以前 30 字节12.2 起放宽注释写法ENGINEInnoDB AUTO_INCREMENT 等COMMENT ON TABLE / COLUMN第一行就足够解释为什么不能互换。MySQL 版建表会在列定义里直接写 AUTO_INCREMENTOracle 不认Oracle 版会多出一段 CREATE SEQUENCE、CREATE OR REPLACE TRIGGER 的语句MySQL 也不认。更隐蔽的是空串语义Oracle 里 INSERT 一个 进去读出来是 NULL如果业务代码里拿空串和 NULL 分别做判断同样的流程在两套库上行为会不一致。COMMENT ON 这组语句也是分水岭。Oracle 用 COMMENT ON TABLE 给表和列加注释建表脚本里通常会带MySQL 用的是 CREATE TABLE 内部的 COMMENT xxx。把 Oracle 脚本硬导进 MySQL跑不了几行就会在 COMMENT ON 附近报语法错误。反过来把 MySQL 脚本丢给 Oracle反引号、ENGINEInnoDB、CHARSET 这些 MySQL 方言会让 Oracle 报出各种无效字符错误。索引长度也是一个隐性差异。MySQL 5.7 的 InnoDB 在 utf8mb4 下单个索引键默认不能超过 767 字节一个 VARCHAR(255) 的 utf8mb4 列最坏占 1020 字节直接超限8.0 放宽到 3072。Oracle 的索引长度受 DB_BLOCK_SIZE 影响通常不会因为 VARCHAR(255) 建索引就失败。所以一份脚本能不能在两库通用绝不是把 CREATE TABLE 复制一遍就能解决必须逐条做类型映射和方言改写。2.3 版本与 schema 的强绑定ACT_GE_PROPERTY 里那行 version 决定你部署能不能起来建表脚本里只有一件事不能在事后补就是 ACT_GE_PROPERTY 中的 schema.version。flowable 引擎启动时会先读这张表拿里面的版本号和自己工程依赖的引擎版本做比较判断数据库结构是否匹配。如果库里根本没有 ACT_GE_PROPERTY或者表建了但里面没有 schema.version 这一行引擎日志里大概率会出现 Schema validation failed。表都在引擎却不认这是最气人的翻车现场。执行完脚本后第一件事就是查这一行SELECT NAME_, VALUE_ FROM ACT_GE_PROPERTY WHERE NAME_ schema.version;正常情况下它应该返回一行记录VALUE_ 是一个和 6.7.2 配套的版本标识具体是6.7.2.0还是别的写法以你拿到的这个包内脚本为准。注意不要手工去改这个值除非你明确知道自己在做什么——引擎启动时还会对关键表结构做校验光改版本号骗过检查没有意义。从其他旧版本升级的场景引擎可以靠 db-schema-update 配置自动执行增量 DDL但这份 zip 的目标场景是新建库手动初始化所以不要指望它自带全版本升级链。空库执行、版本号正确、表结构完整这三件事必须同时满足。3. 在 MySQL 8.0 上执行 flowable 6.7.2 建表脚本最稳的三个步骤3.1 第一步建库与字符集为什么我推荐 utf8mb4_binMySQL 8.0 默认字符集已经是 utf8mb4默认排序规则通常是 utf8mb4_0900_ai_ci。_ai_ci 的含义是不区分重音、不区分大小写这在做流程定义 key、变量名比较时会带来隐患。flowable 内部对流程 key、用户 ID 这类字符串的比较默认是大小写敏感的如果数据库排序规则不敏感同样的 key 在不同写法下可能被误判为同一个。我在新环境里建库只会用这一条配合 utf8mb4_bin 排序规则CREATE DATABASE IF NOT EXISTS flowable DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;参数说明utf8mb4 保证中文、Emoji 这类四字节字符能正常存入utf8mb4_bin 表示按二进制逐字节比较大小写敏感行为更接近 Oracle 的默认语义。如果你做完 MySQL 版之后还有向 Oracle 迁移的计划这一步能把后续的字符串比较差异压到最小。MySQL 5.7 也认 utf8mb4_bin所以换到 5.7 的老库同样适用。有些教程会建议用 utf8mb4_general_ci理由是排序快。对业务表这可能无所谓但对流程引擎这种大量用字符串做唯一键的系统我更愿意要确定性而不是那点性能差异。建完库后用 SHOW CREATE DATABASE flowable 确认一下排序规则避免工具默认设置覆盖了你写的内容。3.2 第二步用 mysql 命令行执行 sql 脚本source 与重定向的区别执行脚本有两种常见方式我日常用重定向比较多。命令如下mysql -u root -p --default-character-setutf8mb4 flowable /path/to/flowable.mysql.sql这条命令的逻辑是以 root 身份交互式输入密码让 mysql 客户端把 flowable 这个库作为默认数据库然后把文件内容作为 SQL 逐条发给服务端执行。--default-character-setutf8mb4 很关键它让客户端在解析文件时按 utf8mb4 解码避免脚本里的中文注释变成乱码导致解析位置偏移。另一种方式是进到 mysql 交互界面后用 sourceUSE flowable; SOURCE /path/to/flowable.mysql.sql;source 是 mysql 客户端的内部命令含义是“读取这个文件并执行”等价于把文件内容粘贴到当前会话。区别在于重定向方式适合脚本里自己写了 USE 语句或没有写的情况source 必须先手动切到目标库。脚本如果内部已经带了 USE flowable那重定向时命令行里写不写库名都行如果脚本没写命令行里的 flowable 就是兜底。执行过程中屏幕上会滚动大量 Query OK、Records: 1 之类的回显。看到 ERROR 不要继续往下等先按 CtrlC 中断。多数情况下错误来自字符集或 SQL 模式修完再重新执行更省时间。注意重复执行同一份脚本时如果脚本里没有 DROP TABLE第二次执行会在 CREATE TABLE 处报 Table already exists这不代表第一次失败。3.3 第三步导入后的 3 张必查表与一条版本 SQL脚本执行完我习惯用三个查询确认结果而不是直接启动引擎试运气。第一个是数表数量SELECT COUNT(*) AS tab_count FROM information_schema.tables WHERE table_schema flowable AND table_name LIKE ACT\_% ESCAPE \;注意 ESCAPE 写法LIKE 里下划线是通配符必须转义才能精确匹配 ACT_ 开头。返回数量应该和脚本里的 CREATE TABLE 数量一致如果少了说明执行过程中有建表语句被跳过。第二个查询回到 2.3 那句版本检查SELECT NAME_, VALUE_ FROM ACT_GE_PROPERTY WHERE NAME_ LIKE schema.%;这个查询会返回多行除了 schema.version还可能有 schema.history 等。只要有版本记录说明整份脚本的 DDL 和初始化 DML 都执行到位了。第三个查询看一张运行时表是否可写比如SELECT COUNT(*) FROM ACT_RU_EXECUTION;空表能查出来就行返回 0 也正常。这一步的目的是确认表能被正常读取避免前面建库权限配置错误导致只有表结构没有访问权限。三个查询全通过后再把引擎的数据库连接串指到这个库配置 database-schema-update 为 false 启动。4. 在 Oracle 19c 上执行同一份工程sqlplus、序列与触发器的特殊处理4.1 准备 Oracle 账号与表空间别让默认 USERS 表空间装下生产数据Oracle 环境动手前要先分清两个概念用户和表空间。表空间是物理存储的容器用户是 schema 的归属者。把 flowable 建在默认 USERS 表空间上也能跑但后续备份、迁移、扩容都会受限尤其是和其他业务表混在一个表空间时查空间占用都说不清楚哪些是流程引擎的。我一般会新建独立表空间和专用用户CREATE TABLESPACE FLOWABLE_DATA DATAFILE /u01/app/oracle/oradata/XEPDB1/flowable01.dbf SIZE 500M AUTOEXTEND ON NEXT 64M MAXSIZE 4G; CREATE USER flowable IDENTIFIED BY YourPassword DEFAULT TABLESPACE FLOWABLE_DATA QUOTA UNLIMITED ON FLOWABLE_DATA; GRANT CONNECT, RESOURCE TO flowable;参数说明DATAFILE 路径要根据你的 Oracle 实例实际目录结构改19c 的多租户架构下通常是 $ORACLE_BASE/oradata/ / 下。AUTOEXTEND ON 让文件在数据增长时自动扩展避免建到一半空间不足。QUOTA UNLIMITED 是用户在这个表空间上的配额限制不设置的话即使 DEFAULT TABLESPACE 指定了也可能因为配额为 0 而报 ORA-01950。GRANT RESOURCE 已经包含 CREATE TABLE、CREATE SEQUENCE、CREATE TRIGGER 等权限单独再给 CONNECT 保证能登录。对 Oracle 入门玩家来说最容易忽略的是密码两边的双引号。Oracle 12c 以后默认密码大小写敏感不加双引号会被统一成大写后续 JDBC 连接串里密码大小写不一致时会在登录阶段报 ORA-01017。建议整个项目统一一个密码规范避免各环境不齐。4.2 用 sqlplus 执行建表脚本ORA- 报错怎么读Oracle 下执行 SQL 文件最直接的工具是 sqlplus天生随数据库自带不需要额外装客户端sqlplus flowable/YourPassword//localhost:1521/XEPDB1 flowable.oracle.sql命令逻辑第一个参数段是 用户名/密码连接串//localhost:1521/XEPDB1 是 Oracle 的 Easy Connect 格式分别指主机、端口、PDB 服务名。flowable.oracle.sql 是让 sqlplus 启动后立即执行这个文件。这里有个和 MySQL 差异很大的行为sqlplus 执行脚本时遇到单条 SQL 报错默认不会终止整个脚本它会继续往下跑。所以执行完不能只看最后有没有报错就收工要把输出里所有 ORA- 开头的行都扫一遍。如果报错太多可以在脚本开头加一句 WHENEVER SQLERROR EXIT让第一条错误出现就退出适合第一次执行时快速暴露问题。执行完后查用户下的表数量SELECT COUNT(*) AS tab_count FROM user_tables WHERE table_name LIKE ACT!\_% ESCAPE !;user_tables 只统计当前用户拥有的表不需要指定 schema 名。表名按大写匹配flowable 官方脚本里的对象名默认就是大写直接查即可。如果扫到的数量比脚本里 CREATE TABLE 少几十张多半是执行中间有 ORA-00955 之类的错误被跳过了回看输出定位是必要的。4.3 Oracle 脚本里的序列与触发器逻辑导入后还要做什么检查Oracle 版建表脚本和 MySQL 版最大的差异不在 CREATE TABLE而在表后面的配套对象。由于 Oracle 没有列级自增主键 ID 的生成靠序列加触发器序列负责产出递增数字触发器负责在 INSERT 之前把序列值塞进主键列。导入完成后除了数表还要确认序列和触发器是不是完整、可用SELECT sequence_name FROM user_sequences ORDER BY sequence_name; SELECT object_name, status FROM user_objects WHERE object_type TRIGGER ORDER BY object_name;第一个查询列出当前用户下所有序列数量应该和脚本里 CREATE SEQUENCE 的条数一致。第二个查询看触发器状态正常情况下应该全是 VALID。如果出现 INVALID说明触发器编译失败常见原因是脚本里引用的表还没建好或者 PL/SQL 代码里有与目标 Oracle 版本不兼容的写法。触发器失效的直接后果是插入 ACT_RU_EXECUTION、ACT_HI_PROCINST 这类表时主键列拿不到序列值应用报“cannot insert NULL into (…ID)”。这个问题我之前在某次测试环境踩过表现是流程引擎一启动就报错翻日志发现 INSERT 失败最后定位到触发器状态重新编译后恢复正常。再检查一下当前用户默认表空间是否正确SELECT username, default_tablespace FROM dba_users WHERE username FLOWABLE;返回的 default_tablespace 应该是你建表时指定的 FLOWABLE_DATA而不是 USERS。如果不对说明用户创建时参数没生效后续所有表都会落在错误表空间再迁移就很麻烦。5. 执行失败排查六个高频报错从现象到解决5.1 MySQL 报 ERROR 1064 / 1071字符集乱码和索引超长现象是执行脚本时在 CREATE TABLE 阶段报 ERROR 1064 语法错误或者建表到一半报 ERROR 1071 Specified key was too long。这两个错误看起来都是脚本问题实际原因完全不同。1064 最常见的原因是客户端解析脚本文件时字符集不对脚本里的中文注释变成乱码乱码中碰巧出现特殊字符导致 SQL 解析中断。解决方法是回到执行命令把 --default-character-setutf8mb4 加上并确认文件本身是 UTF-8 编码。Windows 上从记事本另存为的带 BOM 文件也可能引发首行解析异常建议先用编辑器转成无 BOM 格式。1071 则是索引长度硬限制。MySQL 5.7 的 InnoDB 在 utf8mb4 下默认索引前缀上限 767 字节VARCHAR(255) 的列建普通索引会直接超限。解决思路有两个一是把目标库换成 MySQL 8.0单索引上限放宽到 3072二是如果必须用 5.7把这类列改成 VARCHAR(191) 或者用前缀索引。脚本如果来自官方 6.7.2 适配包通常已经考虑了这个问题报 1071 更多是脚本被二次修改过检查索引列长度即可。5.2 Oracle 报 ORA-00955重复执行与半截脚本造成脏库现象是同一用户下第二次执行建表脚本时大量出现 ORA-00955: name is already used by an existing object。原因很简单这份 Oracle 脚本通常只包含 CREATE 语句没有 DROP 语句不能在同一 schema 上重复执行。更麻烦的场景是第一次执行到一半失败留下几十张表第二次重跑时在已存在的表上报错。解决方法是把目标 schema 清干净再重来不要追求“跳过已存在的表继续跑”。清库可以手动按顺序 DROP 掉表、序列、触发器也可以用一条动态 SQL 生成清理语句BEGIN FOR r IN (SELECT table_name FROM user_tables) LOOP EXECUTE IMMEDIATE DROP TABLE || r.table_name || CASCADE CONSTRAINTS; END LOOP; END; /这段 PL/SQL 的逻辑是遍历当前用户下的所有表逐个 DROP 并级联删除外键约束。注意它不处理序列和触发器还需要单独清一遍。执行完再用 4.2 的计数查询确认表数量为 0再重新导入。5.3 Oracle 报 ORA-00972老库 30 字节的硬边界现象是导入到 Oracle 11g 或 12.1 时报 ORA-00972: identifier is too long。原因指向对象名超长11g/12.1 的标识符上限是 30 字节而 12.2 起才放宽到 128 字节。flowable 官方表名大多控制在 30 字符内但如果你拿到的是别人在 12.2 以上环境整理后二次生成的脚本索引名或约束名超长的可能性就很大。解决思路是分情况。如果目标库可以升级直接用 12.2 以上版本最省心。如果必须停在 11g不要试图手工缩短几十个索引名那等于把脚本重写一遍出错概率极高更可靠的做法是找与目标版本匹配的脚本或者从 JAR 包里提取原始 DDL 再按 11g 规范调整。这个错误我见过不止一次根源几乎都不是 flowable 本身而是脚本来源版本与数据库版本脱节。5.4 把两套脚本装反MySQL 实例吃 Oracle 脚本的三个特征错误现象是 MySQL 导入时报 ERROR 1064且错误位置总是出现在 CREATE SEQUENCE、COMMENT ON、CREATE OR REPLACE TRIGGER 附近的语句。这三个对象是 Oracle 脚本的典型标志MySQL 完全不认识。反过来也一样把 MySQL 脚本导进 Oracle会在反引号、ENGINEInnoDB、DEFAULT CHARSET 附近报 ORA-00911 invalid character。执行前确认文件身份是成本最低的防错手段head -n 20 flowable.oracle.sql看头部注释通常就能分辨。Oracle 版一般会写清适配的数据库版本和 sqlplus 执行方式MySQL 版会写清 ENGINE 和 CHARSET。文件命名里的 mysql、oracle 字段只是参考有时下载站会错配命名以内容为准。这个坑看起来很蠢实际在多人协作、网盘转存过几次之后非常常见。5.5 导入成功但 ACT_GE_PROPERTY 是空表现象是 DDL 执行全程无报错几十张表都在但第一个版本查询返回空结果。原因是脚本里除了建表语句还有一段 INSERT 初始化数据如果执行工具只跑了 DDL 部分或者脚本内部分段执行到 INSERT 前被中断就会出现“表全但数据缺”的怪状态。解决方法是找到脚本里对 ACT_GE_PROPERTY 的 INSERT 语句单独执行。不要自己去造一条版本记录因为版本号写法、是否还有别的初始化数据必须和脚本保持一致。翻文件搜索 “INSERT INTO ACT_GE_PROPERTY”把那条语句复制出来执行即可。执行后再用 2.3 的查询验证能查到 schema.version 就算补上了。5.6 引擎启动时 Schema validation failed库表齐了但版本对不上现象是表数量正确、ACT_GE_PROPERTY 也有记录但引擎启动日志仍然报 schema 校验失败。原因通常是版本错位zip 里的脚本是 6.7.2但你工程依赖的引擎实际是 6.7.3或者库里残留了其他版本的旧表。解决方法是统一版本而不是强行改表。检查 Maven 或 Gradle 里 flowable 相关依赖是否全部锁定到同一个版本尤其是 flowable-engine、flowable-spring-boot-starter 要一致。确认脚本版本与依赖版本一致后清库重建。这里不建议手工 UPDATE schema.version 来绕过校验引擎会在后续运行时执行与版本匹配的 SQL表结构差一列就会在更晚的时候暴露届时报错更难定位。6. 验证建表成果的最后一招用一条版本查询给引擎“验明正身”前面所有步骤做完最后我会做一次收尾验证不是启动引擎看日志就算结束而是用确定的查询结果说话。MySQL 和 Oracle 两套环境的验证 SQL 可以统一成同一个逻辑就是查属性表里的 schema 相关记录SELECT NAME_, VALUE_ FROM ACT_GE_PROPERTY WHERE NAME_ LIKE schema.%;预期的返回应该是多行其中包括 schema.version并且值和引擎 jar 包版本匹配。查完版本还不够我习惯再部署一个最简单的 BPMN 流程并启动一次然后看两张表的联动SELECT COUNT(*) FROM ACT_RU_EXECUTION; SELECT COUNT(*) FROM ACT_HI_PROCINST;ACT_RU_EXECUTION 里出现当前运行实例ACT_HI_PROCINST 里出现历史实例两者相加才能证明库真正被引擎接管了。只查表结构很容易漏掉权限、序列、触发器这类运行期才暴露的问题让引擎真实跑一个流程是最稳的验收。我个人的习惯是每次手动初始化完库会把脚本文件的 MD5 值、执行日期、执行人、数据库版本记在一份环境说明里。这样三个月后出问题翻记录就能确认这个库是用哪份脚本建的而不是对着一个黑匣子猜。如果后续要升级拿这份记录和下一次的脚本做 diff哪些表变了、哪些数据要迁移一目了然。这个习惯救过我很多次尤其是 Oracle 环境不同版本的 DDL 差异很难凭记忆判断。这套流程走下来新建库初始化、版本校验、真实流程跑通三关都过了flowable 6.7.2 的数据库侧才算真正交到项目手里。希望帮到你。本文还有配套的精品资源点击获取