mysqljdbc连接配置出错怎么办_浅析MySQLJDBC连接配置上的两个误区

原标题&＃xff1a;浅析MySQL JDBC连接配置上的两个误区

相信使用MySQL的同学都配置过它的JDBC驱动&＃xff0c;多数人会直接从哪里贴一段URL过来&＃xff0c;然后稍作修改就上去了&＃xff0c;对应的连接池配置也是一样的&＃xff0c;很少有人会去细想这每一个参数都是什么含义。今天我们就来聊两个比较常见的配置——是否要开启autoReconnect和是否缓存PreparedStatement。

误区一&＃xff1a;autoReconnect&＃61;true真的好用么&＃xff1f;

笔者看到过很多MySQL的URL里都是这样写的&＃xff0c;复制过来改改IP、端口和库名就能用了&＃xff1a;

从字面上看挺好的&＃xff0c;在连接断开后还会自动重连&＃xff0c;加之MySQL有8小时自动断开连接的特性&＃xff0c;在断开后连接会重连&＃xff0c;多好的功能呀。但是如果你去阅读一下MySQL Connect/J开发手册的相关章节&＃xff0c;就会看到官方是这么说明的&＃xff1a;

The use of this feature is not recommended, because it has side effects related to session state and data consistency when applications don&＃39;t handle SQLExceptions properly, and is only designed to be used when you are unable to configure your application to handle SQLExceptions resulting from dead and stale connections properly.

简单来说&＃xff0c;不推荐开启这个特性&＃xff0c;因为有副作用&＃xff0c;在没有正确处理SQLException时容易造成会话状态和数据一致性的问题。

一般的应用都会使用数据库连接池&＃xff0c;那我们的连接池是否正确地处理了抛出的SQLException呢&＃xff1f;抱着这个疑问&＃xff0c;我们来看看阿里的Druid连接池是怎么处理的。

首先&＃xff0c;通过设置合理的健康检查及连接存活时间能解决大部分问题&＃xff1b;其次&＃xff0c;它有针对特定异常的处理逻辑&＃xff0c;在MySqlExceptionSorter中会对特定返回码、异常类(比如com.mysql.jdbc.CommunicationsException和com.mysql.jdbc.exceptions.jdbc4.CommunicationsException)以及错误消息进行处理&＃xff0c;如果是致命错误就把连接抛弃。也就是说&＃xff0c;如果用了Druid&＃xff0c;不管是否设置了autoReconnect&＃xff0c;都能保证后续请求的正确处理。JBoss的连接池实现也有类似的特性。

误区二&＃xff1a;MySQL是否真的不用打开PSCache&＃xff1f;

一般在设置连接池时&＃xff0c;都会有类似下面的设置&＃xff1a;

很多文章上都说PSCache对使用游标的数据库有巨大的性能提升&＃xff0c;但MySQL不建议开启&＃xff0c;因为它不支持游标。所以很多人在用MySQL时&＃xff0c;都会将poolPreparedStatements设置为false&＃xff0c;就连Druid的文档上也是这么写的。

但事实真的是这样么&＃xff0c;MySQL使用PSCache真的对性能没有提升么&＃xff1f;

先来看看关于游标的问题&＃xff0c;其实大部分文章的表述不太准确&＃xff0c;现在的MySQL在存储过程里是支持游标的&＃xff0c;但其他地方的确不支持&＃xff0c;具体详见官方手册(MySQL supports cursors inside stored programs.)。但这并不是我们要讨论的关键。

3.1.0版本后的JDBC驱动里有一个参数是useServerPrepStmts&＃xff0c;如果服务器支持的话&＃xff0c;会开启服务端PreparedStatement&＃xff0c;默认是false。官方手册中有如下说明&＃xff1a;

Server-side Prepared Statements - Connector/J 3.1 will automatically detect and use server-side prepared statements when they are available (MySQL server version 4.1.0 and newer).

也就是说在MySQL 4.1.0版本后&＃xff0c;3.1.0以上的驱动会检测到支持服务端PreparedStatement&＃xff0c;并且启用该特性。根据MySQLTUTORIAL上的说明&＃xff0c;整个过程分为PREPARE、EXECUTE和DEALLOCATE PREPARE三步。MySQL JDBC驱动的Contributor Jess Balint在StackOverflow上做了一个详细的说明&＃xff0c;《High-Performance Java Persistence》的作者也专门撰写文章分析了两者的区别。

上述代码在使用客户端PreparedStatement时&＃xff0c;MySQL日志里看到的是&＃xff1a;

如果用的是服务端PreparedStatement&＃xff0c;看到的则是(实际每次执行只会传占位符的值&＃xff0c;语句是不传的)&＃xff1a;

在整个使用过程中&＃xff0c;Prepare只会做一次&＃xff0c;在这时服务端会对语句进行解析&＃xff0c;后续收到具体值时会优化执行计划。如果同一条语句每次都新建PreparedStatement&＃xff0c;那么每次都会多一回网络交互和语句解析&＃xff0c;这显然是可以优化的。

综上所述&＃xff0c;现在在使用MySQL时(如果版本比较新的话)&＃xff0c;出于性能考虑&＃xff0c;应该在数据库连接池上开启针对PreparedStatement的缓存。如果没有使用连接池&＃xff0c;或者所用的连接池不支持PSCache&＃xff0c;也可以在JDBC连接上设置cachePrepStmts&＃61;true。

事实上&＃xff0c;MySQL的JDBC驱动还有不少针对性能的优化&＃xff0c;比如设置useConfigs&＃61;maxPerformance(请酌情使用)&＃xff0c;相当于同时做了如下设置&＃xff1a;

各位同学&＃xff0c;是时候检视一下自己的系统是如何连接MySQL的了。

时代在发展&＃xff0c;有些以前适用的配置也许就不再合适了。返回搜狐&＃xff0c;查看更多

责任编辑&＃xff1a;