5.6及以上版本推荐使用MySQL Connector/J 8.0
Connector/J 8.0 is a Type 4 pure Java JDBC 4.2 driver for the Java 8 platform. It provides compatibility with all the functionality of MySQL 5.6, 5.7, and 8.0. See MySQL Connector/J 8.0 Developer Guide for details.
MySQL Connector/J 8.0 is highly recommended for use with MySQL Server 8.0, 5.7, and 5.6. Please upgrade to MySQL Connector/J 8.0.
Table Summary of Connector/J Versions
MySQL Connector/J 8.0新特性
It supports MySQL 5.6, 5.7, and 8.0.
It supports the JDBC 4.2 specification.
It is a MySQL driver for the Java 8 platform. For Java 7 or earlier, use Connector/J 5.1 instead.
It supports the new X DevAPI, through which native support by MySQL 5.7 and 8.0 for JSON, NoSQL, document collection, and other features are provided to Java applications.
Driver/Datasource Class Name
The name of the class that implements java.sql.Driver in MySQL Connector/J is com.mysql.cj.jdbc.Driver.
Connection URL Syntax
generic format of the connection URL:
jdbc:mysql: is for ordinary and basic JDBC failover connections.最基本和普通的协议
jdbc:mysql:loadbalance: is for load-balancing JDBC connections.支持负载均衡的协议，可以连接多台主机，在多台主机件实现负载均衡
jdbc:mysql:replication: is for JDBC replication connections.支持主从复制的的协议
mysqlx: is for X DevAPI connections. 支持X DevAPI的协议
jdbc:mysql+srv: is for ordinary and basic failover JDBC connections that make use of DNS SRV records.
jdbc:mysql+srv:loadbalance: is for load-balancing JDBC connections that make use of DNS SRV records.
jdbc:mysql+srv:replication: is for replication JDBC connections that make use of DNS SRV records.
mysqlx+srv: is for X DevAPI connections that make use of DNS SRV records.
Always use the Connection.setCatalog() method to specify the desired database in JDBC applications, rather than the USE database statement.
Timeout for socket connect (in milliseconds), with 0 being no timeout. Only works on JDK-1.4 or newer. Defaults to '0'.
Timeout (in milliseconds) on network socket operations (0, the default means no timeout).
Maximum allowed packet size to send to server. If not set, the value of system variable 'max_allowed_packet' will be used to initialize this upon connecting. This value will not take effect if set larger than the value of 'max_allowed_packet'. Also, due to an internal dependency with the property "blobSendChunkSize", this setting has a minimum value of "8203" if "useServerPrepStmts" is set to "true". Default: 65535
Allow the use of ';' to delimit multiple queries during one statement (true/false). Default: false
Should the driver use multiqueries (irregardless of the setting of "allowMultiQueries") as well as rewriting of prepared statements for INSERT into multi-value inserts when executeBatch() is called? Notice that this has the potential for SQL injection if using plain java.sql.Statements and your code doesn't sanitize input correctly. Notice that for prepared statements, server-side prepared statements can not currently take advantage of this rewrite option, and that if you don't specify stream lengths when using PreparedStatement.set*Stream(), the driver won't be able to determine the optimum number of parameters per batch and you might receive an error from the driver that the resultant packet is too large. Statement.getGeneratedKeys() for these rewritten statements only works when the entire batch includes INSERT statements. Please be aware using rewriteBatchedStatements=true with INSERT .. ON DUPLICATE KEY UPDATE that for rewritten statement server returns only one value as sum of all affected (or found) rows in batch and it isn't possible to map it correctly to initial statements; in this case driver returns 0 as a result of each batch statement if total count was 0, and the Statement.SUCCESS_NO_INFO as a result of each batch statement if total count was > 0. Default: false
Using Character Sets and Unicode
WarningDo not issue the query SET NAMES with Connector/J, as the driver will not detect that the character set has been changed by the query, and will continue to use the character set configured when the connection was first set up.
When using connection pooling, always make sure that connections, and anything created by them (such as statements or result sets) are closed. This rule applies no matter what happens in your code (exceptions, flow-of-control, and so forth). When these objects are closed, they can be re-used; otherwise, they will be stranded, which means that the MySQL server resources they represent (such as buffers, locks, or sockets) are tied up for some time, or in the worst case can be tied up forever.
specify a validation query in your connection pool that starts with / ping /. Note that the syntax must be exactly as specified. This will cause the driver send a ping to the server and return a dummy lightweight result set.
版权声明: 本文为 InfoQ 作者【qihuajun】的原创文章。