Flowable版本冲突实战：从MySQL大小写问题到databaseSchemaUpdate配置解析

1. 问题初现：一个令人困惑的版本不匹配错误

那天下午，我正在为一个已经上线的项目搭建一套新的开发环境。这个项目使用了Flowable工作流引擎，一切都很顺利，直到我启动Spring Boot应用的那一刻。控制台突然抛出了一个刺眼的红色错误，直接让应用启动进程戛然而止。错误信息非常明确，但又让人摸不着头脑：version mismatch: library version is '6.6.0.0', db version is 5.99.0.0。后面还跟着一句提示，建议我去设置一个叫databaseSchemaUpdate的参数。

我当时的第一反应是：“数据库版本不对？” 我检查了数据库里的act_ge_property表，里面的VALUE_字段清清楚楚地写着6.6.0.0，和我的Flowable库版本完全一致。这就奇怪了，为什么Flowable引擎一口咬定我的数据库版本是5.99.0.0这个我从来没见过的版本号呢？这种感觉就像是你明明拿着身份证，但系统非说你的信息对不上，还给你报了个完全不存在的号码。

我按照网上大多数教程的建议，尝试手动修改act_ge_property表的数据，甚至怀疑是不是数据没同步过来，反复核对了好几遍。结果当然是徒劳的，错误依旧。这个5.99.0.0就像个幽灵版本，不知道从哪冒出来的。我开始意识到，这可能不是一个简单的“改个版本号”就能解决的问题，背后一定有更深层次的原因，很可能和数据库的环境差异有关。毕竟，生产环境是运行了很久的，而我这套新环境是刚用MySQL 8.0.23搭建的。

2. 深入虎穴：追踪源码，揭开“幽灵版本”的面纱

当常规的排查手段全部失效后，最可靠的办法就是去看源码到底是怎么执行的。我打开了IDE的调试模式，在Flowable启动报错的地方打了断点，准备跟着代码走一遍，看看这个5.99.0.0究竟是何方神圣。

错误抛出的位置在ProcessDbSchemaManager.schemaCheckVersion这个方法里。逻辑很清晰：引擎会获取当前库的版本（FlowableVersions.CURRENT_VERSION，也就是6.6.0.0），然后去数据库里获取存储的版本进行比对。如果不一致，就抛出我们看到的那个异常。那么，关键就在于数据库里的版本是怎么获取的。

我顺着调用栈往下找，来到了负责获取数据库版本的getSchemaVersion()方法。我发现，它并不是直接去查act_ge_property表。而是先调用一个getProperty("schema.version")的方法。这个方法会尝试执行一条SQL：SELECT VALUE_ FROM ACT_GE_PROPERTY WHERE NAME_ = 'schema.version'。请注意，这里的表名ACT_GE_PROPERTY是全大写的。

问题就出在这里！如果这条SQL执行后没有查到任何数据，getProperty方法就会返回null。那么，getSchemaVersion()方法就会执行一个备选