Appearance
升级至1.5.0
重要
- 升级flowable至6.7.2。flowable在6.7.x中优化了分页逻辑,大量提升了查询速度。具体可查看flowable更新日志。
- 重构了待办/待签/已办/办结/我的请求列表的查询逻辑,大量提升了查询速度。
pom.xml(cloud请忽略)
修改flowable版本号为6.7.2

application.yaml(cloud请忽略)
yaml
#flowable配置
flowable:
activity-font-name: \u5B8B\u4F53
label-font-name: \u5B8B\u4F53
annotation-font-name: \u5B8B\u4F53
check-process-definitions: false
database-schema-update: true # 升级flowable 表自动更新
async-executor-activate: false # 定时任务
app:
enabled: false
cmmn:
enabled: false
idm:
enabled: false
dmn:
enabled: false
form:
enabled: false
content:
enabled: false
eventregistry:
enabled: false
custom-mybatis-x-m-l-mappers:
- org/springblade/plugin/workflow/process/mapper/WfProcessDefinition.xml
升级之后的查询速度
DANGER
群里有几个老哥对插件进行了测试,数据从10w开始列表卡顿。但在实际情况中当流程结束时,runtime中的数据会被删除,来保证进行中的流程查询速度不会变慢。下面有两个实际使用中的例子:
- 群主服务过的某雪糕销售商,全国业务员2000+,近半年所有流程数量在4000条左右。
- 群主所在集团6000+人,近半年内代办数量大约在5000条。
我不确定以上场景是否超过了群里几位老哥的实际场景,但积压流程超过10w条的情况基本不存在。
本测试基于,实际结果可能因硬件/软件/网络问题不同。
型号:MacBook Pro(14-inch, Late 2021)
CPU/GPU:M1 Max
内存:64GB
BladeX:2.9.0
Mysql:5.7
具体列表速度,以下每个列表数据均为738580条
- 待办列表 4.5s
- 待签列表 4.8s
- 我的请求 1.6s
- 我的已办 2s
- 流程运维 运维调度 0.7s
- 流程运维 所有流程 1.6s
速度慢的原因
- 待办与待签列表速度慢的原因: ACT_RU_IDENTITYLINK表中数据影响。
- ACT_RU_IDENTITYLINK表中的数据变多后也会影响到发起流程列表。因为模型配置的权限信息在此表中。
优化建议
- 数据库链接务必使用
内网
,flowable的service查询会多次访问数据库,每次时间约为0.5ms-1.5ms左右。若使用外网根据服务器带宽不同,时间会多几十倍导致列表查询变慢。 - 查询列表使用的service中不要使用.includeVariable、variableValueEqual等
变量
相关的方法。列表最好是展示基础信息的列表,不要想着展示变量里的业务信息,变量等业务信息请在详情里查看。 - 定时清理历史数据,application.yaml中flowable有history-cleaning配置。可按配置定时清除多少天前的历史数据。
- 以上还不解决速度慢的问题,请查看后端列表查询的sql输出,具体到哪一条sql速度慢。自行添加索引。
- 如果你觉得flowable写的sql有问题,可全局搜索flowable的xml,复制到你的项目中自行修改。具体操作可自行百度或者问deepseek、chatgpt。
- 别拿着1核2G的小霸王学习机谈优化,没什么可优化的。