近期，在现场实施的过程中，碰到一个有趣的问题，是关于数据库关键词的配置问题，下面就跟大家介绍下具体情况。

问题是这样的，某已适配过的应用，在新的测试环境上执行安装的过程中，出现一个初始化过程的报错，报错信息如下 ：

应用日志报错SQL语句如下：
select rslaveenti0_.ID_SLAVE as ID_SLAVE1_243_,
rslaveenti0_.HOST_NAME as HOST_NAM2_243_,
rslaveenti0_.ISKAFKA as ISKAFKA3_243_,
rslaveenti0_.MASTER as MASTER4_243_,
rslaveenti0_."NAME" as NAME5_243_,
rslaveenti0_.NON_PROXY_HOSTS as NON_PROX6_243_,
rslaveenti0_.OFFLINEDEVELOPSERVER as OFFLINED7_243_,
rslaveenti0_."PASSWORD" as PASSWORD8_243_,
rslaveenti0_.PORT as PORT9_243_,
rslaveenti0_.PROXY_HOST_NAME as PROXY_H10_243_,
rslaveenti0_.PROXY_PORT as PROXY_P11_243_,
rslaveenti0_.REMOTEJVMPORT as REMOTEJ12_243_,
rslaveenti0_.USERNAME as USERNAM13_243_,
rslaveenti0_.WARN_FAIL as WARN_FA14_243_,
rslaveenti0_.WEB_APP_NAME as WEB_APP15_243_
from R_SLAVE rslaveenti0_
order by rslaveenti0_."NAME" asc;

但是，奇怪的是，拿着这个SQL到达梦的管理工具执行的时候，他确是正常执行的SQL语句，并无任何异常，连接的也是该套测试环境。理论上，达梦数据库的管理工具也是通过JDBC进行连接后进行的查询，与应用应该是一个原理才对，为啥应用那边报错了，管理工具确正常呢？

带着这个问题，首先进行了一些列的嫌疑对象列表排查：（1）驱动版本问题；（2）数据库dm.ini的参数问题；

于是乎，让应用将达梦数据库的驱动替换成与测试环境一致的版本，然后在对应用进行初始化部署测试，发现依然是一样的报错。那么，驱动的问题排除了。随后，对测试正常的库与该异常的测试库的dm.ini 参数进行对比，发现异常的环境中有配置了关键词参数“subscribe,SUBSCRIBE,MEMBER,member,PERCENT,percent,order,ORDER”，于是，将正常适配过的数据库参数也配置了这些关键词，然后重新进行测试。我的天，竟然也是一样的报错。那么，问题到底在哪里呢？

此时，排查突然陷入了僵局。我开始怀疑会不会是应用代码的问题。于是，我在自己的环境按该测试库的配置初始化了一个测试环境，按用户的建表语句创建了这张表。然后，将该SQL语句拿出来用JAVA简单的写了一个查询的测试类，使用同版本的达梦JDBC驱动，并将JDBC驱动日志打开，确认本地可以正常执行后，打包成JAR包（dmtest.jar），用于用户环境验证是否可以正常执行，如果可以正常执行，那可能就是应用哪里有问题；如果不行，那可以证明确实不是应用的问题，需要在另外排查。
部分代码如下：

整体代码打包如下：
dmtest.zip
dmtest.jar

准备好后，我将dmtest.jar上传到用户的测试环境下进行执行测试。结果让我出乎意料，竟然是一样的问题。目前基本可以确定，不是应用代码的问题了，是这个数据库环境有什么不一样的地方。通过JDBC驱动层的日志发现，报的也是语法分析错误，而且JDBC驱动日志获取的SQL再达梦客户端也能正常执行！那么，问题到底出在哪里呢？

正当我百思不得其解的时候，突然想到了一个至关重要的问题，这些都是在驱动层和代码中看到的SQL，那么，数据库中看到的SQL又是怎样的呢？带着这个疑问，我把测试环境的SQL全量日志打开，然后重新执行这个jar包，再生成的sql日志中，我也找到了这个报错的SQL语句，异常的部分，我用黑色标记出来了：
select rslaveenti0_.ID_SLAVE as ID_SLAVE1_243_,
rslaveenti0_.HOST_NAME as HOST_NAM2_243_,
rslaveenti0_.ISKAFKA as ISKAFKA3_243_,
rslaveenti0_.MASTER as MASTER4_243_,
rslaveenti0_."NAME" as NAME5_243_,
rslaveenti0_.NON_PROXY_HOSTS as NON_PROX6_243_,
rslaveenti0_.OFFLINEDEVELOPSERVER as OFFLINED7_243_,
rslaveenti0_."PASSWORD" as PASSWORD8_243_,
rslaveenti0_.PORT as PORT9_243_,
rslaveenti0_.PROXY_HOST_NAME as PROXY_H10_243_,
rslaveenti0_.PROXY_PORT as PROXY_P11_243_,
rslaveenti0_.REMOTEJVMPORT as REMOTEJ12_243_,
rslaveenti0_.USERNAME as USERNAM13_243_,
rslaveenti0_.WARN_FAIL as WARN_FA14_243_,
rslaveenti0_.WEB_APP_NAME as WEB_APP15_243_
from R_SLAVE rslaveenti0_
"order" by rslaveenti0_."NAME" asc;

奇怪的是，这个ORDER为什么到数据库执行的时候，多了一队上引号呢？明明代码中并没有对这个词加双引号，这到底是为什么呢？难道是驱动对这个词做了什么处理吗？带着这个疑问，我静静的思考了起来，这中间，到底是哪个部分的问题？我通过其他客户端连接到这台测试环境的时候，他是可以正常执行的，我把代码放到这台测试环境进行执行的时候，他就报错，而且在数据库按到的ORDER被加了双引号？那么为什么不放在本机的测试环境执行，他就正常呢？这中间，到底还有什么是跟数据库有关系的呢？
忽然，我好像找到这个就是问题的关键了！一个配置文件，dm_svc.conf ！为什么这么说呢，因为，每次客户端连接数据库的时候，驱动都会先去读下本地的这个配置文件。也就是说，可能是这个配置文件有配置了什么东西导致这个异常的产生？

于是，我查看了测试环境的这个配置文件，发现，果然这个配置文件有些内容。这里加了关键词，配置的是全局的KEYWORDS，里面包含了order关键词！罪魁祸首呼之欲出呀这是。（解释下，JDBC通过这个配置文件读取到关键词后，会对SQL中带的关键词加双引号。）

于是，我先把这两个关键词给删除后，再进行测试。

好家伙，总算是正常了，罪魁祸首就是这个全局关键词了。删掉order 关键词后，测试jar包执行正常了。

通过这次的折腾，总结一下：dm_svc.conf 配置文件，通过驱动链接数据库时，均会读取当前客户端下默认的配置参数，关键词这种，建议不要做全局配置，可以针对性的使用对应服务进行配置即可，可以避免项目中产生不必要的麻烦。