博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
浅析MySQL JDBC连接配置上的两个误区
阅读量:5865 次
发布时间:2019-06-19

本文共 3057 字,大约阅读时间需要 10 分钟。

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

\\

一、autoReconnect=true真的好用么?

\\

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

\\
jdbc:mysql://xxx.xxx.xxx.xxx:3306/xxx?autoReconnect=true\u0026amp;...
\\

从字面上看挺好的,在连接断开后还会自动重连,加之MySQL有8小时自动断开连接的特性,在断开后连接会重连,多好的功能呀。但是如果你去阅读一下,就会看到官方是这么说明的:

\\
\

The use of this feature is not recommended, because it has side effects related to session state and data consistency when applications don'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.

\
\\

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

\\

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

\\

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

\\

二、MySQL是否真的不用打开PSCache?

\\

一般在设置连接池时,都会有类似下面的设置:

\\
\u0026lt;property name=\"poolPreparedStatements\" value=\"true\" /\u0026gt;\\u0026lt;property name=\"maxPoolPreparedStatementPerConnectionSize\" value=\"20\" /\u0026gt;
\\

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

\\

但事实真的是这样么,MySQL使用PSCache真的对性能没有提升么?

\\

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

\\

3.1.0版本后的JDBC驱动里有一个参数是useServerPrepStmts,如果服务器支持的话,会开启服务端PreparedStatement,默认是false。中有如下说明:

\\
\

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版本后,3.1.0以上的驱动会检测到支持服务端PreparedStatement,并且启用该特性。根据MySQLTUTORIAL上的,整个过程分为PREPAREEXECUTEDEALLOCATE PREPARE三步。MySQL JDBC驱动的Contributor 在上做了一个详细的说明,《High-Performance Java Persistence》的作者也专门撰写分析了两者的区别。

\\
\ps=conn.prepareStatement(\"select ?\")\ps.setInt(1, 42)\ps.executeQuery()\ps.setInt(1, 43)\ps.executeQuery()\
\\

上述代码在使用客户端PreparedStatement时,MySQL日志里看到的是:

\\
255 Query  select 42\255 Query  select 43
\\

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

\\
\254 Prepare    select ?\254 Execute    select 42\254 Execute    select 43\
\\

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

\\

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

\\

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

\\
\cachePrepStmts=true\cacheCallableStmts=true\cacheServerConfiguration=true\useLocalSessionState=true\elideSetAutoCommits=true\alwaysSendSetIsolation=false\enableQueryTimeouts=false\
\\

各位同学,是时候检视一下自己的系统是如何连接MySQL的了,时代在发展,有些以前适用的配置也许就不再合适了。

转载地址:http://crynx.baihongyu.com/

你可能感兴趣的文章
Go语言大神亲述:历七劫方可成为程序员!
查看>>
精通CSS+DIV网页样式与布局--制作实用菜单
查看>>
jboss规则引擎KIE Drools 6.3.0 Final 教程(3)
查看>>
主页被改为毒霸/搜狗的解决办法
查看>>
程序员写代码时的各种内心戏 ……
查看>>
Spring Boot整合Thymeleaf完整Web案例
查看>>
Spark-rdd的持久化
查看>>
Percona Server 5.7 并行doublewrite 特性
查看>>
Spark-基础-Spark编译与部署--Hadoop编译安装
查看>>
Charles辅助调试接口
查看>>
云计算作为当前趋势 能带给你哪些好处?
查看>>
[译] 项目什么时候需要 React 框架呢?
查看>>
git使用小技巧,转
查看>>
django --fields.E304 错误解决方案
查看>>
阿里云ACA专业认证全新上线,随学随考加快人才培养速度
查看>>
陈孝良:为什么国内做不好智能音响?
查看>>
马云:阿里巴巴必须成为国家和世界创新的发动机
查看>>
hbase vs mongodb
查看>>
谈一谈CloudBlog的系统架构
查看>>
企业需为网络安全做哪些准备?
查看>>