基于DWS进行客户业务调优时经常会识别到部分业务场景需调整数据库guc参数，如果全局调整参数可能会对其他业务场景产生影响，因此需要会话级别调整guc参数，连接DWS业务程序大多通过JDBC与DWS进行数据交互，因此我们可以在业务程序调用JDBC连接数据库时进行数据库参数设置，代码样例如下：import java.sql.CallableStatement;import java.sql.Connection;import java.sql.DriverManager;import java.sql.PreparedStatement;import java.sql.ResultSet;import java.sql.SQLException;import java.sql.Statement;public class paraset {  //创建数据库连接。  public static Connection GetConnection(String username, String passwd) {    String driver = "org.postgresql.Driver";    String sourceURL = "jdbc:postgresql://***.***.***.***:25308/postgres";    Connection conn = null;    try {      //加载数据库驱动。      Class.forName(driver).newInstance();    } catch (Exception e) {      e.printStackTrace();      return null;    }    try {      //创建数据库连接。      conn = DriverManager.getConnection(sourceURL, username, passwd);      System.out.println("Connection succeed!");    } catch (Exception e) {      e.printStackTrace();      return null;    }    return conn;  };  //执行guc 参数设置，并查看设置结果  public static void ParaSet(Connection conn) {    Statement stmt = null;    try {      stmt = conn.createStatement();      //set前查看下参数初始值      ResultSet rs = stmt.executeQuery("select name,setting from pg_settings where name ='enable_index_nestloop'");      while (rs.next()) {          System.out.println(rs.getString(1)+" "+rs.getString(2));          }      //设置参数为off      boolean rc = stmt.execute("set enable_index_nestloop=off;");      System.out.println(rc);      //设置完成后查看参数是否设置成功       rs = stmt.executeQuery("select name,setting from pg_settings where name ='enable_index_nestloop'");      while (rs.next()) {          System.out.println(rs.getString(1)+" "+rs.getString(2));          }          rs.close();      stmt.close();    } catch (SQLException e) {      if (stmt != null) {        try {          stmt.close();        } catch (SQLException e1) {          e1.printStackTrace();        }      }      e.printStackTrace();    }  }  /**   * 主程序，逐步调用各静态方法。   * @param args  */  public static void main(String[] args) {    //创建数据库连接。    Connection conn = GetConnection("user", "password");    //设置参数。    ParaSet(conn);    //关闭数据库连接。    try {      conn.close();    } catch (SQLException e) {      e.printStackTrace();    }  }}执行结果如下：

在之前的步骤之中只是加载了jar包，安装了驱动，第三步连接时这个配置文件zengine.ini怎么来的呢？

1 简介SQLite JDBC 是一个用于使用Java 访问和创建SQLite数据库文件的库。 2 编译环境准备2.1 安装Openjdk下载并安装到指定目录（如/opt/tools/installed）：wget  https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u191-b12/OpenJDK8U-jdk_aarch64_linux_hotspot_8u191b12.tar.gztar   -zxf OpenJDK8U-jdk_aarch64_linux_hotspot_8u191b12.tar.gzmv jdk8u191-b12   /opt/tools/installed/配置java环境变量，在/etc/profile文件末尾处增加下面的代码：JAVA_HOME=/opt/tools/installed/jdk8u191-b12PATH=$JAVA_HOME/bin:$PATHexport   JAVA_HOME PATH运行下面命令，使修改的环境变量生效：source   /etc/profile2.2 安装Maven下载并安装到指定目录（如/opt/tools/installed）：wget   https://archive.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gztar   -zxf apache-maven-3.5.4-bin.tar.gzmv   apache-maven-3.5.4 /opt/tools/installed/修改maven环境变量，在/etc/profile文件末尾增加下面高亮代码：JAVA_HOME=/opt/tools/installed/jdk8u191-b12MAVEN_HOME=/opt/tools/installed/apache-maven-3.5.4PATH=$MAVEN_HOME/bin:$JAVA_HOME/bin:$PATHexport   MAVEN_HOME   JAVA_HOME PATH运行下面的命令，是修改的环境变量生效：source   /etc/profile2.3 安装Gcc等依赖项挂载OS镜像：mount   YOUR_OS.iso /media -o loop修改/etc/yum.repos.d/Base.repo文件，配置yum本地源：[Local]name=CentOS-7.4   Localbaseurl=file:///media/enabled=1gpgcheck=0运行下面的命令，使yum源配置生效：yum   clean allyum   makecacheyum安装GCC等相关依赖：yum   install git gcc gcc-c++ make cmake libtool autoconf automake -y2.4 解决-fsigned-char问题1.使用command -v gcc命令寻找gcc所在路径（一般位于/usr/bin/gcc）2.更改gcc的名字（比如改成gcc-impl）3.在gcc所在目录执行vim gcc，并填入如下内容保存：#!   /bin/sh/usr/bin/gcc-impl   -fsigned-char “$@”4.执行chmod +x gcc给脚本添加执行权限5.使用与1-4步相似的方式给g++创建同名字的脚本文件3 组件编译安装下载sqlite-jdbc-3.8.11.2源码，并解压wget https://github.com/xerial/sqlite-jdbc/archive/3.8.11.2.zipunzip 3.8.11.2.zipcd sqlite-jdbc-3.8.11.2修改Makefile：执行编译：make 

    （1）数据库链接创建、释放频繁造成系统资源浪费从而影响系统性能，如果使用数据库链接池可解决此问题。解决：在SqlMapConfig.xml中配置数据链接池，使用连接池管理数据库链接。（2）Sql语句写在代码中造成代码不易维护，实际应用sql变化的可能较大，sql变动需要改变java代码。解决：将Sql语句配置在XXXXmapper.xml文件中与java代码分离。（3）向sql语句传参数麻烦，因为sql语句的where条件不一定，可能多也可能少，占位符需要和参数一一对应。解决：Mybatis自动将java对象映射至sql语句，通过statement中的parameterType定义输入参数的类型。（4）对结果集解析麻烦，sql变化导致解析代码变化，且解析前需要遍历，如果能将数据库记录封装成pojo对象解析比较方便。解决：Mybatis自动将sql执行结果映射至java对象，通过statement中的resultType定义输出结果的类型。

官网正在进行一系列的体验活动，了解更多详情请移步官网看看大大大福利~~各种配置太麻烦？ 轻轻的点击下图，试试一键式免费开通DDM实例MySQL驱动（ jdbc）通过Loadbalance方式连接DDM，在某些场景下连接切换时会陷入死循环，最终导致栈溢出。问题定位查看APP日志，定位异常原因。例如，从以下日志中分析出异常最终原因为栈溢出。Caused by: java.lang.StackOverflowErrorat java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:57)at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:795)at java.nio.charset.Charset.encode(Charset.java:843)at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:2362)at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:2344)at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:568)at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:626)at com.mysql.jdbc.Buffer.writeStringNoNull(Buffer.java:670)at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2636)分析溢出源。例如，从以下日志可以分析出，溢出原因为驱动内部陷入死循环。at com.mysql.jdbc.LoadBalancedConnectionProxy.pickNewConnection(LoadBalancedConnectionProxy.java:344)at com.mysql.jdbc.LoadBalancedAutoCommitInterceptor.postProcess(LoadBalancedAutoCommitInterceptor.java:104)at com.mysql.jdbc.MysqlIO.invokeStatementInterceptorsPost(MysqlIO.java:2885)at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2808)at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2483)at com.mysql.jdbc.ConnectionImpl.setReadOnlyInternal(ConnectionImpl.java:4961)at com.mysql.jdbc.ConnectionImpl.setReadOnly(ConnectionImpl.java:4954)at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:381)at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:366)at com.mysql.jdbc.LoadBalancedConnectionProxy.pickNewConnection(LoadBalancedConnectionProxy.java:344)查看使用的MySQL版本，为5.1.44。查看该版本源代码，发现获取连接时，LoadBalance会根据负载均衡策略更新连接，并将老连接的配置复制给新连接，在新连接AutoCommit为true，新连接部分参数和老连接不一致，loadBalanceAutoCommitStatementThreshold参数没有配置的场景下，会陷入死循环，更新连接函数调用同步参数函数，同步参数又调用更新连接，最终导致栈溢出。解决方法在连接DDM的URL添加loadBalanceAutoCommitStatementThreshold=5&retriesAllDown=10参数。//使用负载均衡的连接示例//jdbc:mysql:loadbalance://ip1:port1,ip2:port2..ipN:portN/{db_name}String url = "jdbc:mysql:loadbalance://192.168.0.200:5066,192.168.0.201:5066/db_5133?loadBalanceAutoCommitStatementThreshold=5&retriesAllDown=10";loadBalanceAutoCommitStatementThreshold：表示连接上执行多少个语句后会重新选择连接。假设loadBalanceAutoCommitStatementThreshold设为5，则当执行5个sql后（Queries或者updates等），将会重新选择连接。若为0表示“粘性连接，不重新选择连接”。关闭自动提交时（autocommit=false）会等待事务完成再考虑是否重新选择连接。retriesAllDown：当所有的连接地址都无法连接时，轮询重试的最大次数。重试次数达到阈值仍然无法获取有效连接，将会抛出SQLException。

1.1  问题背景公司是做电商系统的，整个系统搭建在华为云上。系统设计的时候，考虑到后续的用户和订单数量比较大，需要使用一些大数据库的组件。关系型数据库这块，考虑到后续数据量的快速增长，不是直接写入MySQL，而是使用了华为云的分布式数据库中间件（DDM）。DDM华为云连接：https://www.huaweicloud.com/product/ddm.html      使用了DDM之后，可以在业务不感知的情况下，直接增加MySQL读实例的个数，线性提升读性能。也支持中间件层面的分库分表，提供海量关系型数据库的操作。简直是为电商系统贴身定制的。DDM自身是以集群形式提供服务的，对业务开放的是多个连接IP地址。需要有一层负载均衡。如果使用传统的加LB的形式做负载均衡，会多一层中转，有性能损耗。所以，直接使用了MySQL-JDBC提供的客户端负载均衡能力。逻辑结构如下图所示：            业务通过MySQL-JDBC的Loadbalance能提访问多个DDM节点。MySQL-JDBC提供负载均衡能力。 1.2  问题说明使用MySQL客户端负载均衡力能，一直运行得好好，性能嗷嗷叫。可是前一阵子，无故出现了业务请求失败。我是负责电商订单模块的，涉及到真实的Money，这个问题吓了宝宝一身冷汗。。赶紧查看后台日志，发现是访问DDM出现了异常，二话不说直接提了工单给华为云DDM服务。[WARN] [2018-07-08 23:11:29] [MySqlValidConnectionChecker:isValidConnection()] [DubboServerHandler-172.31.0.146:8080-thread-64-txId=00000000657615aa] Unexpected error in ping java.lang.reflect.InvocationTargetException          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)          at java.lang.reflect.Method.invoke(Method.java:498)          at com.alibaba.druid.pool.vendor.MySqlValidConnectionChecker.isValidConnection(MySqlValidConnectionChecker.java:98)          at com.alibaba.druid.pool.DruidAbstractDataSource.testConnectionInternal(DruidAbstractDataSource.java:1252)          at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:981) 不得不说，华为云的服务还是很好的，不到半个小时就联系了我，还跟我一起排查问题。将我们业务的日志取下来，和DDM的支撑人员一起分析，发现报错如下：根本原因竟然是MySQL驱动的bug，导致StackOverflow本地栈溢出导致，真是误会了DDM服务，抱歉了。Caused by: java.lang.StackOverflowError          at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:2360)          at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:2344)          at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:568)          at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:626)          at com.mysql.jdbc.Buffer.writeStringNoNull(Buffer.java:670)          at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2636)          at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2483)          at com.mysql.jdbc.ConnectionImpl.setReadOnlyInternal(ConnectionImpl.java:4961)          at com.mysql.jdbc.ConnectionImpl.setReadOnly(ConnectionImpl.java:4954)          at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:381)          at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:366)          at com.mysql.jdbc.LoadBalancedConnectionProxy.pickNewConnection(LoadBalancedConnectionProxy.java:344)          at com.mysql.jdbc.LoadBalancedAutoCommitInterceptor.postProcess(LoadBalancedAutoCommitInterceptor.java:104)          at com.mysql.jdbc.MysqlIO.invokeStatementInterceptorsPost(MysqlIO.java:2885)          at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2808)          at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2483)          at com.mysql.jdbc.ConnectionImpl.setReadOnlyInternal(ConnectionImpl.java:4961)          at com.mysql.jdbc.ConnectionImpl.setReadOnly(ConnectionImpl.java:4954)          at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:381)          at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:366)          at com.mysql.jdbc.LoadBalancedConnectionProxy.pickNewConnection(LoadBalancedConnectionProxy.java:344)          at com.mysql.jdbc.LoadBalancedAutoCommitInterceptor.postProcess(LoadBalancedAutoCommitInterceptor.java:104)          at com.mysql.jdbc.MysqlIO.invokeStatementInterceptorsPost(MysqlIO.java:2885) 。。。 此处省略10000行。。从堆栈可以看出来，某个异常，触发了MySQL-JDBC的bug，导致循环调用，直至栈溢出。在华为DDM支撑人员的建议下，对驱动代码进行了反编译，从反编译的情况下，可以看到，的确是存在循环嵌套的可能。Loadbalance轮询连接 –>同步新老连接的状态 ->发送sql给服务端 -> Loadbalance轮询连接。相关代码如下：com/mysql/jdbc/LoadBalancedConnectionProxy.java的pickNewConnection()函数for (int hostsTried = 0, hostsToTry = this.hostList.size(); hostsTried < hostsToTry; hostsTried++) {    ConnectionImpl newConn = null;    try {        newConn = this.balancer.pickConnection(this, Collections.unmodifiableList(this.hostList), Collections.unmodifiableMap(this.liveConnections),                this.responseTimes.clone(), this.retriesAllDown);        if (this.currentConnection != null) {            if (pingBeforeReturn) {                if (pingTimeout == 0) {                    newConn.ping();                } else {                    newConn.pingInternal(true, pingTimeout);                }            }            syncSessionState(this.currentConnection, newConn);        }        this.currentConnection = newConn;        return;    } catch (SQLException e) {        if (shouldExceptionTriggerConnectionSwitch(e) && newConn != null) {            // connection error, close up shop on current connection            invalidateConnection(newConn);        }    }}syncSessionState()函数，在执行完SQL之后，又会调用postProcess()函数，如此嵌套循环就来了。if (!this.conn.getAutoCommit()) {     this.matchingAfterStatementCount = 0;     // auto-commit is enabled: } else {     if (this.proxy == null && this.conn.isProxySet()) {         MySQLConnection lcl_proxy = this.conn.getMultiHostSafeProxy();         while (lcl_proxy != null && !(lcl_proxy instanceof LoadBalancedMySQLConnection)) {             lcl_proxy = lcl_proxy.getMultiHostSafeProxy();         }         if (lcl_proxy != null) {             this.proxy = ((LoadBalancedMySQLConnection) lcl_proxy).getThisAsProxy();         }     }     if (this.proxy != null) {         // increment the match count if no regex specified, or if matches:         if (this.matchingAfterStatementRegex == null || sql.matches(this.matchingAfterStatementRegex)) {             this.matchingAfterStatementCount++;         }     }     // trigger rebalance if count exceeds threshold:     if (this.matchingAfterStatementCount >= this.matchingAfterStatementThreshold) {         this.matchingAfterStatementCount = 0;         try {             if (this.proxy != null) {                 this.proxy.pickNewConnection();             }         } catch (SQLException e) {             // eat this exception, the auto-commit statement completed, but we could not rebalance for some reason.  User may get exception when using             // connection next.         }     } }  这么明显的bug，不太相信MySQL会没有发现。当前我们使用的是5.1.44版本的驱动，查看了下最新的5.1.66的代码，发现的确是修复了这个问题的，代码如下：public ResultSetInternalMethods postProcess(String sql, Statement interceptedStatement, ResultSetInternalMethods originalResultSet, Connection connection,                                             int warningCount, boolean noIndexUsed, boolean noGoodIndexUsed, SQLException statementException) throws SQLException {     // Don't count SETs neither SHOWs. Those are mostly used internally and must not trigger a connection switch.     if (!this.countStatements || StringUtils.startsWithIgnoreCase(sql, "SET") || StringUtils.startsWithIgnoreCase(sql, "SHOW")) {         return originalResultSet;     }通过过滤掉SET和SHOW语句，避免了循环嵌套的发生。但是5.1.66又引入了新的bug，由于并不是每个调用postProcess的地方都有SQL，这里的代码会抛空指针异常。MySQL JDBC的开发者都不做测试的吗。。。 没办法，分析了下5.1.44的代码，发现通过适当的调整loadBalanceAutoCommitStatementThreshold这个参数的数值，也可以避免循环嵌套的发生。我们的环境改成了5，修改之后，平稳运行1周，没再出现过问题。 1.3  修改方案loadBalanceAutoCommitStatementThreshold修改成了5，但是引入的问题是，如果业务包含一些比较耗时的SQL，可能会DDM的负载不均衡。不过，目前看来还好，DDM性能比较强劲。 最后告诉大家一个小福利，华为云数据库年中钜惠活动正在火热进行中，分布式数据库中间件DDM等多款产品免费体验！点击：https://activity.huaweicloud.com/dcs_midyear/index.html?forum，发现更多精彩！欢迎扫码查看更多精彩：

1.1  问题背景公司是做电商系统的，整个系统搭建在华为云上。系统设计的时候，考虑到后续的用户和订单数量比较大，需要使用一些大数据库的组件。关系型数据库这块，考虑到后续数据量的快速增长，不是直接写入MySQL，而是使用了华为云的分布式数据库中间件（DDM）。DDM华为云连接：https://www.huaweicloud.com/product/ddm.html      使用了DDM之后，可以在业务不感知的情况下，直接增加MySQL读实例的个数，线性提升读性能。也支持中间件层面的分库分表，提供海量关系型数据库的操作。简直是为电商系统贴身定制的。DDM自身是以集群形式提供服务的，对业务开放的是多个连接IP地址。需要有一层负载均衡。如果使用传统的加LB的形式做负载均衡，会多一层中转，有性能损耗。所以，直接使用了MySQL-JDBC提供的客户端负载均衡能力。逻辑结构如下图所示：            业务通过MySQL-JDBC的Loadbalance能提访问多个DDM节点。MySQL-JDBC提供负载均衡能力。 1.2  问题说明使用MySQL客户端负载均衡力能，一直运行得好好，性能嗷嗷叫。可是前一阵子，无故出现了业务请求失败。我是负责电商订单模块的，涉及到真实的Money，这个问题吓了宝宝一身冷汗。。赶紧查看后台日志，发现是访问DDM出现了异常，二话不说直接提了工单给华为云DDM服务。[WARN] [2018-07-08 23:11:29] [MySqlValidConnectionChecker:isValidConnection()] [DubboServerHandler-172.31.0.146:8080-thread-64-txId=00000000657615aa] Unexpected error in ping java.lang.reflect.InvocationTargetException          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)          at java.lang.reflect.Method.invoke(Method.java:498)          at com.alibaba.druid.pool.vendor.MySqlValidConnectionChecker.isValidConnection(MySqlValidConnectionChecker.java:98)          at com.alibaba.druid.pool.DruidAbstractDataSource.testConnectionInternal(DruidAbstractDataSource.java:1252)          at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:981) 不得不说，华为云的服务还是很好的，不到半个小时就联系了我，还跟我一起排查问题。将我们业务的日志取下来，和DDM的支撑人员一起分析，发现报错如下：根本原因竟然是MySQL驱动的bug，导致StackOverflow本地栈溢出导致，真是误会了DDM服务，抱歉了。Caused by: java.lang.StackOverflowError          at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:2360)          at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:2344)          at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:568)          at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:626)          at com.mysql.jdbc.Buffer.writeStringNoNull(Buffer.java:670)          at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2636)          at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2483)          at com.mysql.jdbc.ConnectionImpl.setReadOnlyInternal(ConnectionImpl.java:4961)          at com.mysql.jdbc.ConnectionImpl.setReadOnly(ConnectionImpl.java:4954)          at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:381)          at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:366)          at com.mysql.jdbc.LoadBalancedConnectionProxy.pickNewConnection(LoadBalancedConnectionProxy.java:344)          at com.mysql.jdbc.LoadBalancedAutoCommitInterceptor.postProcess(LoadBalancedAutoCommitInterceptor.java:104)          at com.mysql.jdbc.MysqlIO.invokeStatementInterceptorsPost(MysqlIO.java:2885)          at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2808)          at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2483)          at com.mysql.jdbc.ConnectionImpl.setReadOnlyInternal(ConnectionImpl.java:4961)          at com.mysql.jdbc.ConnectionImpl.setReadOnly(ConnectionImpl.java:4954)          at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:381)          at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:366)          at com.mysql.jdbc.LoadBalancedConnectionProxy.pickNewConnection(LoadBalancedConnectionProxy.java:344)          at com.mysql.jdbc.LoadBalancedAutoCommitInterceptor.postProcess(LoadBalancedAutoCommitInterceptor.java:104)          at com.mysql.jdbc.MysqlIO.invokeStatementInterceptorsPost(MysqlIO.java:2885) 。。。 此处省略10000行。。从堆栈可以看出来，某个异常，触发了MySQL-JDBC的bug，导致循环调用，直至栈溢出。在华为DDM支撑人员的建议下，对驱动代码进行了反编译，从反编译的情况下，可以看到，的确是存在循环嵌套的可能。Loadbalance轮询连接 –>同步新老连接的状态 ->发送sql给服务端 -> Loadbalance轮询连接。相关代码如下：com/mysql/jdbc/LoadBalancedConnectionProxy.java的pickNewConnection()函数for (int hostsTried = 0, hostsToTry = this.hostList.size(); hostsTried < hostsToTry; hostsTried++) {    ConnectionImpl newConn = null;    try {        newConn = this.balancer.pickConnection(this, Collections.unmodifiableList(this.hostList), Collections.unmodifiableMap(this.liveConnections),                this.responseTimes.clone(), this.retriesAllDown);        if (this.currentConnection != null) {            if (pingBeforeReturn) {                if (pingTimeout == 0) {                    newConn.ping();                } else {                    newConn.pingInternal(true, pingTimeout);                }            }            syncSessionState(this.currentConnection, newConn);        }        this.currentConnection = newConn;        return;    } catch (SQLException e) {        if (shouldExceptionTriggerConnectionSwitch(e) && newConn != null) {            // connection error, close up shop on current connection            invalidateConnection(newConn);        }    }}syncSessionState()函数，在执行完SQL之后，又会调用postProcess()函数，如此嵌套循环就来了。if (!this.conn.getAutoCommit()) {     this.matchingAfterStatementCount = 0;     // auto-commit is enabled: } else {     if (this.proxy == null && this.conn.isProxySet()) {         MySQLConnection lcl_proxy = this.conn.getMultiHostSafeProxy();         while (lcl_proxy != null && !(lcl_proxy instanceof LoadBalancedMySQLConnection)) {             lcl_proxy = lcl_proxy.getMultiHostSafeProxy();         }         if (lcl_proxy != null) {             this.proxy = ((LoadBalancedMySQLConnection) lcl_proxy).getThisAsProxy();         }     }     if (this.proxy != null) {         // increment the match count if no regex specified, or if matches:         if (this.matchingAfterStatementRegex == null || sql.matches(this.matchingAfterStatementRegex)) {             this.matchingAfterStatementCount++;         }     }     // trigger rebalance if count exceeds threshold:     if (this.matchingAfterStatementCount >= this.matchingAfterStatementThreshold) {         this.matchingAfterStatementCount = 0;         try {             if (this.proxy != null) {                 this.proxy.pickNewConnection();             }         } catch (SQLException e) {             // eat this exception, the auto-commit statement completed, but we could not rebalance for some reason.  User may get exception when using             // connection next.         }     } }  这么明显的bug，不太相信MySQL会没有发现。当前我们使用的是5.1.44版本的驱动，查看了下最新的5.1.66的代码，发现的确是修复了这个问题的，代码如下：public ResultSetInternalMethods postProcess(String sql, Statement interceptedStatement, ResultSetInternalMethods originalResultSet, Connection connection,                                             int warningCount, boolean noIndexUsed, boolean noGoodIndexUsed, SQLException statementException) throws SQLException {     // Don't count SETs neither SHOWs. Those are mostly used internally and must not trigger a connection switch.     if (!this.countStatements || StringUtils.startsWithIgnoreCase(sql, "SET") || StringUtils.startsWithIgnoreCase(sql, "SHOW")) {         return originalResultSet;     }通过过滤掉SET和SHOW语句，避免了循环嵌套的发生。但是5.1.66又引入了新的bug，由于并不是每个调用postProcess的地方都有SQL，这里的代码会抛空指针异常。MySQL JDBC的开发者都不做测试的吗。。。 没办法，分析了下5.1.44的代码，发现通过适当的调整loadBalanceAutoCommitStatementThreshold这个参数的数值，也可以避免循环嵌套的发生。我们的环境改成了5，修改之后，平稳运行1周，没再出现过问题。 1.3  修改方案loadBalanceAutoCommitStatementThreshold修改成了5，但是引入的问题是，如果业务包含一些比较耗时的SQL，可能会DDM的负载不均衡。不过，目前看来还好，DDM性能比较强劲。 最后告诉大家一个小福利，华为云数据库年中钜惠活动正在火热进行中，分布式数据库中间件DDM等多款产品免费体验！点击：https://activity.huaweicloud.com/dcs_midyear/index.html?forum，发现更多精彩！欢迎扫码查看更多精彩：