一个goldendb引发的血案

前言

因为我所负责的系统需要做系统迁移，这次迁移从移动云上迁移到内部私有云，然后就悲催的吃上了国产化的螃蟹。首先服务器操作系统使用的是欧拉操作系统，然后就是kafka采用了自己封装了认证模块的，最后就是数据库从mysql改成了goldendb。迁移之前对方数据库小组和我说：“你放心，goldendb就是封装了mysql8.0，问题不大的”，但十几年的软件行业从业经历告诉我，不要信他们的鬼话。之前有一篇讲Maven工程如何引入非Maven工程的jar包，也是这个数据库给让我教的学费。虽然我只是负责协调和管理，主要还是开发在做的测试，但记录一下也方便遇到同样问题的人能够尽快解决。

环境：jdk8 \ goldendb 6.1.03 \ 驱动 5.1.46.28

遇到的问题

问题遇到了三个：

1、如何在maven工程中引入非maven工程的jar包，上一篇《pom如何引入非Maven工程的jar包》已经说过了；

2、使用sharding-jdbc连接goldendb报"where 1!=1 "异常；

3、使用的分页插件PageHelper报错；

经历的过程

这里主要是问题1和问题2花费时间较长，这里主要说说问题2.

我们使用的是微服务，总共大概六七个服务。在问题1解决后，其他的服务都能运行的起来，但是服务A启动的时候直接报如下异常：

check the manual that corresponds to your MySOL server version for the right syntax to use near '"table_name"' WHERE 1!=1 at line 1

尝试1

我的第一反应让开发检查sql文件中有没有where 1! = 1 或where 1 = 1这种语句，因为我认为可能是提供给我们的goldendb做了限制不允许使用这么这种写法。然后开发反馈我们的sql中只有where 1 = 1语句，并且注释掉了。

重新一运行，yes，tmd还是报错。

尝试2

为了排除干扰因素和方便沟通，我让开发自己写一个简答的demo，配置上sharding-jdbc在连接goldendb试试。因为开发反馈服务A与其他服务相比多了sharding-jdbc，所以我觉得尝试写个新的demo，确定问题在sharding-jdbc上，而不是其他因素导致的。

重新一运行，yes，grd还是报错。

尝试3

我开始怀疑他们给我们安装的goldendb与sharding-jdbc不兼容，但是当我们将这个demo给到数据库组的某位大佬让他跑一下程序时，他是这样说的：

而且他还出示了他在他那边运行的成功的证明：

尝试4

基于尝试3，我开始环境是数据库版本的问题，版本发出来后发现我们的是6.1.03，而能正常运行的是6.13.04（对方只报了一串数字61304，6.13.04是我猜的）。所以我怀疑新版做了sharding-jdbc的兼容，而我们的版本没有做。

于是，我希望数据库组能安装一下我们的版本，或者安装一下他们的版本在做一下测试，没有得到回应。因为这玩意是付费我们没有公司领导授权拿不到安装包，所以最后我没办法验证是不是他那个版本是支持sharding-jdbc的。

尝试5

经过多次在数据库服务器抓包查看执行日志，发现好几种尝试任然报异常“where 1!=1”。比如怀疑springboot版本的问题、sharding-jdbc的问题，但都被一一否决了。但是尝试中发现使用goldendb驱动连接本地mysql sharding-jdbc不报错，使用goldendb驱动连接goldendb就不行，那么已经排除了驱动的问题。

尝试6

数据库组中研发驱动的大佬坚持去看了sharding-jdbc源码，找到了问题所在。shardingjdbc如果url使用jdbc:goldendb，无法识别回填给MysqlDatabaseType这个参数，没有对应的databaseType，默认是SQL92DatabaseType。默认的配置就是给表名拼接，默认是用双引号，最终导致刚刚那个问题。需要将url中jdbc:goldendb改成jdbc:mysql可以规避。

总结

搞了整整3天才找到问题根源，完整的兼容sharding-jdbc的数据源参数配置如下：

driver-class-name: com.goldendb.jdbc.Driver
url: idbc:mysql://ip：port/unity burying point prod?useUnicode=...
username: username
password: password

同时问题3的分页插件问题，在配置里将数据库方言配置改成：

pagehelper.helperDialect=mysql

干了这么多年，其实很多时候都知道去看源码是最好的途径，他让你知道为什么出问题了。但是人的本能还是抱着一种侥幸心理，我在试试这种可能也许这个问题就解决了呢？这也许就是研发和开发的区别，也是大佬和码农的区别吧！

以上只是解决了，但是并不能保证这么修改会不会带来其他问题。要想确认是否会带来其他问题，还需要去看看数据库驱动和sharding-jdbc是否有通过url中的要素做判断的。有知道的大佬可以告诉我一下，有兴趣的大佬和自己研究一下。

另外，根据最终问题的原因，其实还有一个解决方案，就是修改sharding-jdbc关于MysqlDatabaseType类型识别的代码中加入对goldendb的判断，用修复后的sharding-jdbc。

本人水平一般能力有限，本文如有误之处还望指正，感谢！