26.3. MySQL Connector/J
- 26.3.1. 基本的JDBC概念
- 26.3.2. 安装 Connector/J
- 26.3.3. JDBC引用
- 26.3.4. 与J2EE和其他Java框架一起使用 Connector/J
- 26.3.5. 诊断 Connector/J方面的问题
- 26.3.6. Changelog
通过JDBC驱动，MySQL提供了与使用Java编程语言开发的客户端应用程序的连通性，该驱动称为MySQL Connector/J。
MySQL Connector/J是一种JDBC-3.0“类型4”驱动，这意味着它是一种纯Java程序，实施了3.0版JDBC规范，并能使用MySQL协议与MySQL服务器直接通信。
本文档是为初级JDBC开发人员准备和安排的。如果你已有了使用JDBC方面的经验，可直接从安装 Connector/J开始。
尽管JDBC本身很有用，但我们希望，如果你在阅读完本手册的前几节后尚未熟悉JDBC，除了最平常的问题外应避免全面使用“裸”JDBC，应考虑使用流行的架构，如Hibernate、Spring的JDBC模板或Ibatis SQL Maps等，使用它们来完成大多数重复性工作，以及在某些时侯需要用到JDBC的繁重任务。
本节不是作为完整的JDBC教程而设计的。如果需要了解使用JDBC方面的更多信息，或许会对下述在线教程感兴趣，与这里提供的信息相比，它们介绍的更为详细和更具深度。
·JDBC基础，Sun公司提供的教程，涵盖了JDBC的基本主题。。
·JDBC简明课程，Sun和JGuru提供了更深的教程。
26.3.1. 基本的JDBC概念
- 26.3.1.1. 使用DriverManager接口连接到MySQL
- 26.3.1.2. 使用语句以执行SQL
- 26.3.1.3. 使用CallableStatements以执行存储程序
- 26.3.1.4. 检索AUTO_INCREMENT列的值
26.3.1.1. 使用DriverManager接口连接到MySQL
在应用服务器外使用JDBC时，DriverManager类将用于管理连接的建立。需要告诉DriverManager应与哪个JDBC驱动建立连接。完成该任务的最简单方法是：在实施了java.sql.Driver接口的类上使用Class.forName()。对于MySQL Connector/J，该类的名称是com.mysql.jdbc.Driver。采用该方法，可使用外部配置文件来提供连接到数据库时将使用的驱动类名和驱动参数。
在下面的Java代码中，介绍了在应用程序的main()方法中注册MySQL Connector/J的方式：
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
// Notice, do not import com.mysql.jdbc.*
// or you will have problems!（注意，不要导入com.mysql.jdbc.*，否则// 将出现问题！）
public class LoadDriver { public static void main(String[] args) {try {// The newInstance() call is a work around for some
// broken Java implementations
Class.forName("com.mysql.jdbc.Driver").newInstance();} catch (Exception ex) {// handle the error
}
}
在DriverManager中注册了驱动后，通过调用DriverManager.getConnection()，能够获得与特殊数据库相连的连接实例。
示例26.1：从DriverManager获得连接
在本示例中，介绍了从DriverManager获得连接实例的方法。对于getConnection()方法，有一些不同的特性。关于如何使用它们的更多信息，请参阅与JDK一起提供的API文档。
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
... try { Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test?user=monty&password=greatsqldb");// Do something with the Connection
....
} catch (SQLException ex) {// handle any errors
System.out.println("SQLException: " + ex.getMessage()); System.out.println("SQLState: " + ex.getSQLState()); System.out.println("VendorError: " + ex.getErrorCode());}
一旦建立了连接，它可被用于创建语句和PreparedStatements，并检索关于数据库的元数据。在下面数节内，给出了进一步的解释。
26.3.1.2. 使用语句以执行SQL
使用语句，可执行基本的SQL查询，并通过下面介绍的ResultSet类检索结果。
要想创建语句实例，应通过前面介绍的DriverManager.getConnection()或DataSource.getConnection()方法之一，在检索的连接对象上调用createStatement()方法。
一旦拥有了语句实例，可以与希望使用的SQL一起通过调用executeQuery(String)方法执行SELECT查询。
要想更新数据库中的数据，可使用executeUpdate(String SQL)方法。该方法将返回受更新语句影响的行数。
如果你事先不清楚SQL语句是SELECT或UPDATE/INSERT，应使用execute(String SQL)方法。如果SQL查询是SELECT，本方法将返回“真”，如果SQL查询是UPDATE/INSERT/DELETE，本方法将返回“假”。如果是SELECT查询，能够通过调用getResultSet()方法检索结果。如果是UPDATE/INSERT/DELETE查询，能够通过在语句实例上调用getUpdateCount()检索受影响的行计数。
示例26.2：使用java.sql.Statement执行SELECT查询
// assume conn is an already created JDBC connectionStatement stmt = null;ResultSet rs = null;try { stmt = conn.createStatement(); rs = stmt.executeQuery("SELECT foo FROM bar"); // or alternatively, if you don't know ahead of time that // the query will be a SELECT... if (stmt.execute("SELECT foo FROM bar")) {rs = stmt.getResultSet(); } // Now do something with the ResultSet ....} finally { // it is a good idea to release // resources in a finally{} block // in reverse-order of their creation // if they are no-longer needed if (rs != null) {try { rs.close();} catch (SQLException sqlEx) { // ignore }rs = null; } if (stmt != null) {try { stmt.close();} catch (SQLException sqlEx) { // ignore }stmt = null; }}26.3.1.3. 使用CallableStatements以执行存储程序
从MySQL服务器5.0版开始，与Connector/J 3.1.1或更新版本一起使用时，可完全实现java.sql.CallableStatement接口，但getParameterMetaData()方法例外。
在MySQL参考手册的“存储程序和函数”一节中，介绍了MySQL存储程序的语法。
通过JDBC的CallableStatement接口，Connector/J指明了存储程序的功能。
在下面的示例中，给出了1个存储程序，它返回增量为1的inOutParam的值，并通过inputParam传递了作为ResultSet的字符串。
示例26.3. 存储程序示例
CREATE PROCEDURE demoSp(IN inputParam VARCHAR(255), INOUT inOutParam INT)
BEGIN
DECLARE z INT;
SET z = inOutParam + 1;
SET inOutParam = z;
SELECT inputParam;
SELECT CONCAT('zyxw', inputParam);END
要想与Connector/J一起使用demoSp，可采取下述步骤：
1. 使用Connection.prepareCall()准备可调用语句。
注意，必须使用JDBC转义语法，而且必须使用包含占位符的圆括号：
示例26.4.使用Connection.prepareCall()
导入java.sql.CallableStatement：
...
//
// Prepare a call to the stored procedure 'demoSp'
// with two parameters
//
// Notice the use of JDBC-escape syntax ({call ...})//
CallableStatement cStmt = conn.prepareCall("{call demoSp(?, ?)}");cStmt.setString(1, "abcdefg");
注释：
Connection.prepareCall()是一种开销很大的方法，原因在于驱动程序执行的支持输出参数的元数据检索。出于性能方面的原因，应在你的代码中再次使用CallableStatement实例，通过该方式，使对Connection.prepareCall()的不必要调用降至最低。
2. 注册输出参数（如果有的话）
为了检索输出参数的值（创建存储程序时指定为OUT或INOUT的参数），JDBC要求在CallableStatement接口中使用各种registerOutputParameter()方法来执行语句之前指定它们：
示例26.5.注册输出参数
导入java.sql.Types：
...
//
// Connector/J supports both named and indexed
// output parameters. You can register output
// parameters using either method, as well
// as retrieve output parameters using either
// method, regardless of what method was
// used to register them.
//
// The following examples show how to use
// the various methods of registering
// output parameters (you should of course
// use only one registration per parameter).
//
//
// Registers the second parameter as output
//
cStmt.registerOutParameter(2);
//
// Registers the second parameter as output, and
// uses the type 'INTEGER' for values returned from
// getObject()
//
cStmt.registerOutParameter(2, Types.INTEGER);
//
// Registers the named parameter 'inOutParam'
//
cStmt.registerOutParameter("inOutParam");//
// Registers the named parameter 'inOutParam', and
// uses the type 'INTEGER' for values returned from
// getObject()
//
cStmt.registerOutParameter("inOutParam", Types.INTEGER);...
3. 设置输入参数（如果有的话）
输入以及输入／输出参数是作为PreparedStatement对象而设置的。但是，CallableStatement也支持按名称设置参数：
示例26.6.设置CallableStatement输入参数
...
//
// Set a parameter by index
//
cStmt.setString(1, "abcdefg");
//
// Alternatively, set a parameter using
// the parameter name
//
cStmt.setString("inputParameter", "abcdefg");//
// Set the 'in/out' parameter using an index
//
cStmt.setInt(2, 1);
//
// Alternatively, set the 'in/out' parameter
// by name
//
cStmt.setInt("inOutParam", 1);...
4. 执行CallableStatement，并检索任何结果集或输出参数。
尽管CallableStatement支持调用任何语句执行方法（executeUpdate()，executeQuery()或execute()），最灵活的方法是调用execute()，这是因为，采用该方法，你无需事先知道存储程序是否将返回结果集：
示例26.7.检索结果和输出参数值
...
boolean hadResults = cStmt.execute();
//
// Process all returned result sets
//
while (hadResults) {ResultSet rs = cStmt.getResultSet();
// process result set
...
hadResults = cStmt.getMoreResults();
}
//
// Retrieve output parameters
//
// Connector/J supports both index-based and
// name-based retrieval
//
int outputValue = cStmt.getInt(1); // index-based
outputValue = cStmt.getInt("inOutParam"); // name-based...
26.3.1.4. 检索AUTO_INCREMENT列的值
在JDBC API 3.0版之前，没有从支持“自动增量”或ID列的数据库中检索关键值的标准方法。对于针对MySQL的早期JDBC驱动，总是不得不在语句接口上使用特定的MySQL方法，或在向拥有AUTO_INCREMENT关键字的表发出“INSERT后”发出“SELECT LAST_INSERT_ID()”。特殊的MySQL方法调用是不可移植的，而且对于发出“SELECT”以获取AUTO_INCREMENT关键字的值来说，需要对数据库执行另一往返操作，其效率不高。在下面的代码片段中，介绍了检索AUTO_INCREMENT值的三种不同方式。首先，介绍了JDBC-3.0新方法“getGeneratedKeys()”的使用方式，当你需要检索AUTO_INCREMENT关键字并访问JDBC-3.0，它是目前的首选方法。在第2个示例中，介绍了使用标准“SELECT LAST_INSERT_ID()”查询检索相同值的方法。在最后一个示例中，介绍了使用“insertRow()”方法时，用可更新结果集检索AUTO_INCREMENT值的方式。示例26.8. 使用Statement.getGeneratedKeys()检索AUTO_INCREMENT列的值
Statement stmt = null; ResultSet rs = null; try { // // Create a Statement instance that we can use for // 'normal' result sets assuming you have a // Connection 'conn' to a MySQL database already // available stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,java.sql.ResultSet.CONCUR_UPDATABLE); // // Issue the DDL queries for the table for this example // stmt.executeUpdate("DROP TABLE IF EXISTS autoIncTutorial"); stmt.executeUpdate( "CREATE TABLE autoIncTutorial (" + "priKey INT NOT NULL AUTO_INCREMENT, " + "dataField VARCHAR(64), PRIMARY KEY (priKey))"); // // Insert one row that will generate an AUTO INCREMENT // key in the 'priKey' field // stmt.executeUpdate( "INSERT INTO autoIncTutorial (dataField) " + "VALUES (NULL, Statement.RETURN_GENERATED_KEYS); // // Example of using Statement.getGeneratedKeys() // to retrieve the value of an auto-increment // value // int autoIncKeyFromApi = -1; rs = stmt.getGeneratedKeys(); if (rs.next()) {autoIncKeyFromApi = rs.getInt(1); } else {// throw an exception from here } rs.close(); rs = null; System.out.println("Key returned from getGeneratedKeys():"+ autoIncKeyFromApi);} finally { if (rs != null) {try { rs.close();} catch (SQLException ex) { // ignore} } if (stmt != null) {try { stmt.close();} catch (SQLException ex) { // ignore} }}示例26.9. 使用SELECT LAST_INSERT_ID()检索AUTO_INCREMENT列的值
Statement stmt = null; ResultSet rs = null; try { // // Create a Statement instance that we can use for // 'normal' result sets. stmt = conn.createStatement(); // // Issue the DDL queries for the table for this example // stmt.executeUpdate("DROP TABLE IF EXISTS autoIncTutorial"); stmt.executeUpdate( "CREATE TABLE autoIncTutorial (" + "priKey INT NOT NULL AUTO_INCREMENT, " + "dataField VARCHAR(64), PRIMARY KEY (priKey))"); // // Insert one row that will generate an AUTO INCREMENT // key in the 'priKey' field // stmt.executeUpdate( "INSERT INTO autoIncTutorial (dataField) " + "VALUES (NULL, assuming you have a Connection 'conn' to // a MySQL database already available // stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,java.sql.ResultSet.CONCUR_UPDATABLE); // // Issue the DDL queries for the table for this example // stmt.executeUpdate("DROP TABLE IF EXISTS autoIncTutorial"); stmt.executeUpdate( "CREATE TABLE autoIncTutorial (" + "priKey INT NOT NULL AUTO_INCREMENT, " + "dataField VARCHAR(64), PRIMARY KEY (priKey))"); // // Example of retrieving an AUTO INCREMENT key // from an updatable result set // rs = stmt.executeQuery("SELECT priKey, dataField " + "FROM autoIncTutorial"); rs.moveToInsertRow(); rs.updateString("dataField", "AUTO INCREMENT here?"); rs.insertRow(); // // the driver adds rows at the end // rs.last(); // // We should now be on the row we just inserted // int autoIncKeyFromRS = rs.getInt("priKey"); rs.close(); rs = null; System.out.println("Key returned for inserted row: "+ autoIncKeyFromRS);} finally { if (rs != null) {try { rs.close();} catch (SQLException ex) { // ignore} } if (stmt != null) {try { stmt.close();} catch (SQLException ex) { // ignore} }} 运行上面的示例代码时，将获得下述输出：从getGeneratedKeys():返回的键， 从“SELECT LAST_INSERT_ID():”返回1个键， 从插入的行返回1个键。请注意，有些时候，使用“SELECT LAST_INSERT_ID()”查询十分复杂，原因在于函数值与连接相关。因此，如果在相同连接上存在其他查询，函数值将被覆盖。另一方面，“getGeneratedKeys()”方法是由语句实例确定的，因此，即使在相同连接上存在其他查询也能使用它，但在相同语句实例上存在其他查询时则不能使用。26.3.2. 安装 Connector/J
- 26.3.2.1. 所需的软件版本
- 26.3.2.2. 升级旧版本
26.3.2.1. 所需的软件版本
- 26.3.2.1.1. 支持的Java版本
- 26.3.2.1.2. MySQL服务器版本指南
- 26.3.2.1.3. 安装驱动程序并配置CLASSPATH
26.3.2.1.1. 支持的Java版本
MySQL Connector/J支持Java-2 JVMs，包括JDK-1.2.x、JDK-1.3.x、JDK-1.4.x和JDK-1.5.x，并需要JDK-1.4.x或更新的版本进行编译（而不是运行）。MySQL Connector/J不支持JDK-1.1.x或JDK-1.0.x。由于实现了java.sql.Savepoint，Connector/J 3.1.0和更新版本不会运行在早于1.4版的JDK上，除非关闭了类验证器（-Xverify:none），这是因为，类验证器将试图加载用于java.sql.Savepoint的类定义，除非使用了savepoint功能，否则驱动程序不会访问类验证器。
早于1.4.x版的JVM上，不能使用Connector/J 3.1.0或更高版本提供的新缓冲功能，这是因为该功能依赖在JDK-1.4.0中首次提供的java.util.LinkedHashMap。
26.3.2.1.2. MySQL服务器版本指南
MySQL Connector/J支持所有著名的MySQL服务器版本。某些特性（外键，可更新结果集）需要更新的MySQL版本才能工作。与MySQL服务器4.1版或更高版本建立连接时，最好使用MySQL Connector/J 3.1版，这是因为它全面支持较新版本的服务器提供的特性，包括Unicode字符、视图、存储程序和服务器端预处理语句。
尽管3.0版Connector/J能够与MySQL服务器4.1或更高版本建立连接，但由于实现了Unicode字符和新的鉴定机制，将无法更新Connector/J 3.0以支持当前和未来服务器版本中提供的新特性。
26.3.2.1.3. 安装驱动程序并配置CLASSPATH
MySQL Connector/J是以.zip或.tar.gz形式分发的，其中包含源码、类文件、以及仅为“二进制”.jar的类文件（名为mysql-connector-java-[version]-bin.jar），从Connector/J 3.1.8开始，驱动程序的“调试版”位于名为“mysql-connector-java-[version]-bin-g.jar”的文件中。从Connector/J 3.1.9开始，我们不再单独提供.class文件，仅在与驱动程序一起提供的JAR文件中提供它们。
不应使用驱动程序的“调试版”，除非是在向MySQL AB通报问题或缺陷时需要用到它，这是因为“调试版”不是为生产环境下的运行而设计的，如果使用它，会对性能造成负面影响。二进制代码的调试取决于Aspect/J运行时库，该库位于与Connector/J分发版一起提供的src/lib/aspectjrt.jar文件中。
需要使用恰当的GUI或命令行使用工具来解开分发文件（例如，用于.zip文件的WinZip，以及用于.tar.gz文件的“tar”）。由于在分发版中可能存在长文件名，我们采用了GNU tar档案格式。需要使用GNU tar（或能理解GNU tar档案格式的其他应用程序）来解开分发版的.tar.gz文件。
一旦解包了分发版档案文件，可以将mysql-connector-java-[version]-bin.jar放在你的类路径中，或是在你的CLASSPATH环境变量中添加它的完整路径，或是在启动JVM（Java虚拟机）时用命令行开关“-cp”直接指定它，通过该方式安装驱动。
如果你打算用JDBC DriverManager来使用驱动，可使用“com.mysql.jdbc.Driver”，将其用作实施了“java.sql.Driver”类。
示例26.11. 设置Unix环境下的CLASSPATH
在Unix环境下，下述命令用于“csh”：
$ setenv CLASSPATH /path/to/mysql-connector-java-[version]-bin.jar:$CLASSPATH
可以将上述命令添加到恰当的、用于登录shell的启动文件中，从而使得所有的Java应用程序均能使用MySQL Connector/J。
如果希望与诸如Tomcat或Jboss等应用服务器一起使用MySQL Connector/J，应仔细阅读供应商提供的文档，以了解如何配置第三方类库的更多信息，这是因为大多数应用服务器均会忽略CLASSPATH环境变量。在“与J2EE和其他Java框架一起使用 Connector/J”一节中，给出了针对一些J2EE应用服务器的配置示例，但是，对于特定的应用服务器，JDBC连接池配置信息的权威信息源是该应用服务器的文档。
如果你准备开发小服务程序和／或JSP，而且你的应用服务器是J2EE兼容的，可以将驱动的.jar文件放到webapp的WEB-INF/lib子目录下，在J2EE Web应用程序中，这是第三方类库的标准位置。
如果你的J2EE应用服务器支持或要求，也可以使用com.mysql.jdbc.jdbc2.optional可选软件包中的MysqlDataSource或MysqlConnectionPoolDataSource类。多种MysqlDataSource类均支持下述参数（通过标准的“Set”存取器）：
·user
·password
·serverName（参见前面关于故障切换主机的章节）
·databaseName
·port
26.3.2.2. 升级旧版本
- 26.3.2.2.1. 从MySQL Connector/J 3.0升级到3.1
- 26.3.2.2.2. 升级到MySQL服务器4.1版或更新版本时的JDBC事宜
在本节中，介绍了打算从Connector/J的一个版本升级到另一版本（或考虑到JDBC的功能，升级到MySQL服务器的新版本）的用户应了解的信息。
26.3.2.2.1. 从MySQL Connector/J 3.0升级到3.1
设计Connector/J 3.1时，尽量使它能向后兼容Connector/J 3.0。大的变化被单独作为MySQL-4.1和更新版中的新功能，包括Unicode字符集、服务器端预处理语句、由服务器返回的错误信息中的SQLState代码、以及各种性能增强特性（可通过配置属性启用或禁止）。
·Unicode字符集：关于MySQL新特性的更多信息，请参见下一节，以及服务器手册中的“字符集”一节。如果有些事项配置不当，通常会显示错误，同时给出错误消息，如“非法校对组合”。
·服务器端预处理语句：Connector/J 3.1将自动检测服务器端预处理语句，并在可用时自动使用它们（MySQL服务器4.1.0版或更新）。
从3.1.7版开始，驱动程序能通过各种Connection.prepareStatement()变体扫描SQL，以判断它是否是能够在服务器端支持的语句类型，如果不被服务器端支持，会将其作为客户端的模拟预处理语句进行处理。也可以通过在JDBC URL中传递“emulateUnsupportedPstmts=false”禁止该特性。
如果应用程序遇到与服务器端预处理语句有关的问题，可将其回复为旧的客户端模拟预处理语句代码，在早于4.1.0版的MySQL服务器中仍使用该代码，连接属性如下：
useServerPrepStmts=false
·具有全0组分的Datetimes（0000-00-00 ...）：在Java中，无法可靠地表示这些值。从结果集读取它们时，Connector/J 3.0.x总是会将其转换为NULL。
默认情况下，遇到这类值时，Connector/J 3.1将抛出异常，这是因为，根据JDBC和SQL标准，这是最正确的行为方式。可以使用“zeroDateTimeBehavior”配置属性改变该行为。允许的值包括：“exception”，（默认值），用代码为“S1009”的SQLState抛出SQLException；“convertToNull”，返回NULL而不是数据；以及“round”，对日期进行舍入处理，使之成为最接近的值，即“0001-01-01”。
从Connector/J 3.1.7开始，能够使用“noDatetimeStringSync=true”（默认值为“假”），将ResultSet.getString()与该行为分离开，从而能够以字符串的形式提取未被改变的全0值。请注意，这也会阻止使用任何时区转换功能，因此，驱动程序将禁止同时启用noDatetimeStringSync和useTimezone。
·新SQLState代码：Connector/J 3.1采用MySQL返回的SQL:1999 SQLState代码（如果支持的话），它不同于Connector/J 3.0使用的“传统”X/Open状态码。如果连接到了版本低于MySQL-4.1.0（能够将SQLStates作为错误代码组成部分返回的最早版本）的MySQL服务器，驱动程序将使用内置的映射功能。你也可以使用下述配置选项，采用旧的映射。
useSqlStateCodes=false
·在BLOB列上调用ResultSet.getString()将返回代表它的字节[]数组的地址，而不是BLOB的字符串形式。BLOB没有字符集，因此，在不造成数据丢失或损坏的情况下，不能将它们转换为java.lang.Strings。
要想以BLOB方式将字符串保存在MySQL中，可使用一种TEXT类型，驱动程序会将其当作java.sql.Clob对待。
·从Connector/J 3.1.8开始，驱动的“调试版”（在名为“mysql-connector-java-[version]-bin-g.jar”的文件中与正常的“二进制”jar文件“名为mysql-connector-java-[version]-bin.jar”一起提供。
从Connector/J 3.1.9开始，我们不再单独提供.class文件，仅在与驱动程序一起提供的JAR文件中提供它们。
不应使用驱动程序的“调试版”，除非是在向MySQL AB通报问题或缺陷时需要用到它，这是因为“调试版”不是为生产环境下的运行而设计的，如果使用它，会对性能造成负面影响。二进制代码的调试取决于Aspect/J运行时库，该库位于与Connector/J分发版一起提供的src/lib/aspectjrt.jar文件中。
26.3.2.2.2. 升级到MySQL服务器4.1版或更新版本时的JDBC事宜
·使用UTF-8字符编码：在4.1版MySQL服务器之前，服务器不支持UTF-8字符编码，但JDBC驱动能使用它，从而允许在服务器上的latin1中保存多个字符集。
从MySQL-4.1版开始，该功能被放弃。如果你有依赖该功能的应用程序，而且无法升级它们以使用MySQL服务器4.1版或更高版本中支持的正是Unicode字符集，应在连接URL中增加下述属性：
useOldUTF8Behavior=true
·服务器端预处理语句：Connector/J 3.1将自动检测服务器端预处理语句，并在可用时自动使用它们（MySQL服务器4.1.0版或更新）。如果应用程序遇到与服务器端预处理语句有关的问题，可将其回复为旧的客户端模拟预处理语句代码，在早于4.1.0版的MySQL服务器中仍使用该代码，连接属性如下：
useServerPrepStmts=false
26.3.3. JDBC引用
- 26.3.3.1. Driver/Datasource类名，URL语法，以及Connector/J的配置属性
- 26.3.3.2. JDBC API实施说明
- 26.3.3.3. Java，JDBC和MySQL类型
- 26.3.3.4. 使用字符集和Unicode
- 26.3.3.5. 使用SSL进行安全连接
- 26.3.3.6. 使用主／从复制和ReplicationConnection
26.3.3.1. Driver/Datasource类名，URL语法，以及Connector/J的配置属性
在MySQL Connector/J中实现了java.sql.Driver的类名是“com.mysql.jdbc.Driver”。“org.gjt.mm.mysql.Driver”类名任是可用的，以保持与MM.MySQL的向后兼容性。注册驱动程序，或配置软件以使用MySQL Connector/J时，应使用该类名。用于MySQL Connector/J的JDBC URL格式如下，方括号“[, ]”的项为可选项：
jdbc:mysql://[host][,failoverhost...][:port]/[database][?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...
如果未指定主机名，默认为“127.0.0.1”。如果未指定端口，默认为“3306”，它是MySQL服务器的默认端口号。
jdbc:mysql://[host:port],[host:port].../[database][?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...
如果未指定数据库，将使用无“当前”数据库进行连接。在这种情况下，需要在连接实例上调用“setCatalog()”方法，或在SQL中使用数据库名指定完整的表名（即“SELECT dbname.tablename.colname FROM dbname.tablename...”）。不指定连接时使用的数据库，该选项通常仅在创建用于处理多个数据库的工具时才有用，例如GUI数据库管理器。
MySQL Connector/J支持故障切换功能。这样，就允许驱动程序切换至“从”主机上，并仍能执行只读查询。仅当连接处于autoCommit(true)状态时，才会出现故障切换，这是因为当事务正在进行时，无法可靠地保证故障切换。在事务/连接结束后，大多数应用服务器和连接池均会将autoCommit设置为“真”。
故障切换功能具有下述行为方式：
如果URL属性“autoReconnect”为“假”：故障切换仅会在连接初始化过程中出现，当驱动程序判断第1台主机再次可用时，将返回。
如果URL属性“autoReconnect”为“真”：当驱动程序判断连接失败时（在任意查询之前），将出现故障切换，而且当驱动程序判断第1台主机再次可用时（发出queriesBeforeRetryMaster查询之后），将返回第1台主机。
在任何一种情况下，当你连接到经过故障切换的服务器时，会将连接设置为只读状态，因此，对于会更改数据的查询来说，将抛出异常（MySQL服务器不会处理该查询）。
配置属性定义了Connector/J与MySQL服务器进行连接的方式。除非作了其他说明，否则可以为DataSource对象或Connection对象设置属性。
可采用下述方式的一种设置Configuration（配置）属性：
·在java.sql.DataSource的MySQL实施实例上使用set*()方法（它是使用java.sql.DataSource实施实例时的首选方法）：
o com.mysql.jdbc.jdbc2.optional.MysqlDataSource
o com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource
·作为传递给DriverManager.getConnection()或Driver.connect()的java.util.Properties实例中的键/值对。
·作为URL中的JDBC URL参数，以传递给java.sql.DriverManager.getConnection()、java.sql.Driver.connect()、或javax.sql.DataSource的setURL()方法的MySQL实施实例。
注释：
如果你用来配置JDBC URL的方法是基于XML的，需要使用XML字符“&”来隔开配置参数，“&”是XML的保留字符。
在下面的表各中，列出了这些属性：
表26.1. 连接属性
属性名 | 定义 | 要求？ | 默认值 | 版本 |
Connection/Authentication（连接／鉴定） | ||||
user | 连接的用户 | No | 全部 | |
password | 连接时使用的密码。 | No | 全部 | |
socketFactory | 驱动程序用于创建与服务器套接字连接的类的名称。该类必须实现了接口“com.mysql.jdbc.SocketFactory”，并有公共无参量构造函数。 | No | com.mysql.jdbc.StandardSocketFactory | 3.0.3 |
connectTimeout | 套接字连接的超时（单位为毫秒），0表示无超时。仅对JDK-1.4或更新版本有效。默认值为“0”。 | No | 0 | 3.0.1 |
socketTimeout | 网络套接字连接的超时（默认值0表示无超时）。 | No | 0 | 3.0.1 |
useConfigs | 在解析URL属性或应用用户指定的属性之前，加载由逗号“,”分隔的配置属性列表。在文档的“配置”部分中解释了这些配置。 | No | 3.1.5 | |
interactiveClient | 设置CLIENT_INTERACTIVE标志，根据INTERACTIVE_TIMEOUT而不是WAIT_TIMEOUT向MySQL通报超时连接。 | No | false | 3.1.0 |
propertiesTransform | com.mysql.jdbc.ConnectionPropertiesTransform的1个实施实例，在尝试连接之前，驱动程序将使用它来更改传递给驱动的URL属性。 | No | 3.1.4 | |
useCompression | 与服务器进行通信时采用zlib压缩（真／假）？ 默认值为“假”。 | No | false | 3.0.17 |
High Availability and Clustering（高可用性和簇集） | ||||
autoReconnect | 驱动程序是否应尝试再次建立失效的和／或死连接？ 如果允许，对于在失效或死连接上发出的查询（属于当前事务），驱动程序将抛出异常，但在新事务的连接上发出下一个查询时，将尝试再连接。不推荐使用该特性，这是因为，当应用程序不能恰当处理SQLExceptions时，它会造成与会话状态和数据一致性有关的副作用，设计它的目的仅用于下述情况，即，当你无法配置应用程序来恰当处理因死连接和／或无效连接导致的SQLExceptions时。作为可选方式，可将MySQL服务器变量“wait_timeout”设置为较高的值，而不是默认的8小时。 | No | false | 1.1 |
autoReconnectForPools | 使用适合于连接池的再连接策略（默认值为“假”）。 | No | false | 3.1.3 |
failOverReadOnly | 在autoReconnect模式下出现故障切换时，是否应将连接设置为“只读”？ | No | true | 3.0.12 |
reconnectAtTxEnd | 如果将autoReconnect设置为“真”，在每次事务结束后驱动程序是否应尝试再连接？ | No | false | 3.0.10 |
roundRobinLoadBalance | 启用了autoReconnect而且failoverReadonly为“假”时，是否应按照循环方式挑选要连接的主机？ | No | false | 3.1.2 |
queriesBeforeRetryMaster | 出现故障切换（使用多主机故障切换）并返回主机之前发出的查询数。无论首先满足了哪个条件，“queriesBeforeRetryMaster”或“secondsBeforeRetryMaster”，均会再次与主机进行连接。默认值为“50”。 | No | 50 | 3.0.2 |
secondsBeforeRetryMaster | 出现故障切换后，在尝试再次连接到主服务器之前，驱动程序应等待的时间？ 无论首先满足了哪个条件，“queriesBeforeRetryMaster”或“secondsBeforeRetryMaster”，均会再次与主机进行连接。单位为秒，默认值为30。 | No | 30 | 3.0.2 |
enableDeprecatedAutoreconnect | 自3.2版开始，自动再连接功能受到冷落，在3.3版中将删除该功能。将该属性设置为“真”可禁止检查配置的特性。 | No | false | 3.2.1 |
Security（安全） | ||||
allowMultiQueries | 在一条语句中，允许使用“;”来分隔多条查询（真／假，默认值为“假”）。 | No | false | 3.1.1 |
useSSL | 与服务器进行通信时使用SSL（真／假），默认值为“假”。 | No | false | 3.0.2 |
requireSSL | 要求SSL连接，useSSL=true？ 默认值为“假”。 | No | false | 3.1.0 |
allowUrlInLocalInfile | 驱动程序在是“LOAD DATA LOCAL INFILE”语句中否允许URL？ | No | false | 3.1.4 |
paranoid | 采取措施，防止在错误信息中泄漏敏感信息，并可可能时清除保存敏感数据的数据结构？ 默认值为“假”。 | No | false | 3.0.1 |
Performance Extensions（性能扩展） | ||||
metadataCacheSize | 如果将cacheResultSetMetaData设置为“真”，对cacheResultSetMetadata的查询次数（默认值为50）。 | No | 50 | 3.1.1 |
prepStmtCacheSize | 如果允许预处理语句缓冲功能，应缓冲处理多少条预处理语句？ | No | 25 | 3.0.10 |
prepStmtCacheSqlLimit | 如果允许预处理语句缓冲功能，驱动程序将执行解析缓冲处理的最大SQL是什么？ | No | 256 | 3.0.10 |
maintainTimeStats | 驱动程序是否应维持各种内部定时器，以允许空闲时间计算，以及与服务器的连接失败时允许提供更详细的错误消息？ 将该属性设置为“假”，对于每次查询，至少能减少两次对System.getCurrentTimeMillis()的调用。 | No | true | 3.1.9 |
blobSendChunkSize | 组块，当通过ServerPreparedStatements发送BLOB/CLOB时使用。 | No | 1048576 | 3.1.9 |
cacheCallableStmts | 驱动程序是否应对CallableStatements的解析过程执行缓冲处理。 | No | false | 3.1.2 |
cachePrepStmts | 驱动程序是否应对客户端预处理语句的PreparedStatements的解析过程执行缓冲处理，是否应检查服务器端预处理语句的适用性以及服务器端预处理语句本身？ | No | false | 3.0.10 |
cacheResultSetMetadata | 驱动程序是否应对用于Statements和PreparedStatements的ResultSetMetaData执行缓冲处理？ 要求 JDK-1.4+，真／假，默认为“假”。 | No | false | 3.1.1 |
cacheServerConfiguration | 驱动程序是否应根据每条URL对“HOW VARIABLES”和“SHOW COLLATION”的结果执行缓冲处理？ | No | false | 3.1.5 |
dontTrackOpenResources | JDBC规范要求驱动程序自动跟踪和关闭资源，但是，如果你的应用程序不能明确调用作用在语句或结果集上的close()，可能会导致内存泄漏。将该属性设置为“真”，可放宽该限制，对于某些应用程序，会提供更高的内存效率。 | No | false | 3.1.7 |
dynamicCalendars | 需要时，驱动程序是否应检索默认日历，或根据连接／会话对其进行缓冲处理？ | No | false | 3.1.5 |
elideSetAutoCommits | 如果使用MySQL-4.1或更高版本，当服务器的状态与Connection.setAutoCommit(boolean)请求的状态不匹配时，驱动程序是否仅应发出“set autocommit=n”查询？ | No | false | 3.1.3 |
holdResultsOpenOverStatementClose | 驱动程序是否应按照JDBC规范的要求关闭Statement.close()上的结果集？ | No | false | 3.1.7 |
locatorFetchBufferSize | 如果将“emulateLocators”配置为“真”，当获取关于getBinaryInputStream的BLOB数据时，缓冲区的大小应是多少？ | No | 1048576 | 3.2.1 |
useFastIntParsing | 是否使用内部“String->Integer”转换子程序来避免创建过多对象？ | No | true | 3.1.4 |
useLocalSessionState | 驱动程序是否应引用autocommit的内部值，以及由Connection.setAutoCommit()和Connection.setTransactionIsolation()设置的事务隔离，而不是查询数据库？ | No | false | 3.1.7 |
useNewIO | 驱动程序是否应将java.nio.* interfaces用于网络通信（真／假），默认为“假”。 | No | false | 3.1.0 |
useReadAheadInput | 从服务器读取数据时，是否使用较新的、优化的非成组缓冲输入流？ | No | true | 3.1.5 |
Debuging/Profiling（调试/仿形） | ||||
logger | 实现了com.mysql.jdbc.log.Log的类的名称，com.mysql.jdbc.log.Log用于记录消息（默认为“com.mysql.jdbc.log.StandardLogger”，它会将日志记录到STDERR）。 | No | com.mysql.jdbc.log.StandardLogger | 3.1.1 |
profileSQL | 跟踪查询以及它们对已配制记录器的执行/获取次数（真／假），默认为“假”。 | No | false | 3.1.0 |
reportMetricsIntervalMillis | 如果允许“gatherPerfMetrics”，记录它们的频率是多少（单位毫秒）？ | No | 30000 | 3.1.2 |
maxQuerySizeToLog | 调试或仿形时，控制将记录的查询的最大长度／大小。 | No | 2048 | 3.1.3 |
packetDebugBufferSize | 当“enablePacketDebug”为“真”时，需要保留的最大信息包数目。 | No | 20 | 3.1.3 |
slowQueryThresholdMillis | 如果允许“logSlowQueries”，在将查询记录为“慢”之前的查询时间是多少（毫秒）？ | No | 2000 | 3.1.2 |
useUsageAdvisor | 驱动程序是否应发出“使用情况”警告，就DBC和MySQL Connector/J的恰当和高效使用给出建议（真／假，默认为“假”）？ | No | false | 3.1.1 |
autoGenerateTestcaseScript | 驱动程序是否应将正在执行的SQL（包括服务器端预处理语句）转储到STDERR？ | No | false | 3.1.9 |
dumpQueriesOnException | 驱动程序是否应将发送至服务器的查询内容转储到SQLExceptions中？ | No | false | 3.1.3 |
enablePacketDebug | 允许时，将保留“packetDebugBufferSize”信息包的环形缓冲区，并当在驱动程序代码的关键区域抛出异常时进行转储。 | No | false | 3.1.3 |
explainSlowQueries | 如果允许了“logSlowQueries”，驱动程序是否应在服务器上自动发出“EXPLAIN”，并以WARN级别将结果发送给配置好的日志？ | No | false | 3.1.2 |
logSlowQueries | 是否要记录时间长于“slowQueryThresholdMillis”的查询？ | No | false | 3.1.2 |
traceProtocol | 是否应记录跟踪级网络协议？ | No | false | 3.1.2 |
Miscellaneous（其他） | ||||
useUnicode | 处理字符串时，驱动程序是否应使用Unicode字符编码？ 仅应在驱动程序无法确定字符集映射，或你正在强制驱动程序使用MySQL不是固有支持的字符集时（如UTF-8）才应使用。真／假，默认为“真”。 | No | false | 1.1g |
characterEncoding | 如果“useUnicode”被设置为“真”，处理字符串时，驱动程序应使用什么字符编码？ 默认为“autodetect”。 | No | 1.1g | |
characterSetResults | 字符集，用于通知服务器以何种字符集返回结果。 | No | 3.0.13 | |
connectionCollation | 如果设置了它，将通知服务器通过“set collation_connection”使用该校对。 | No | 3.0.13 | |
sessionVariables | 以逗号隔开的“名称／值”对列表，当驱动程序建立了连接后，以“SET SESSION ...”的方式将其发送给服务器。 | No | 3.1.8 | |
allowNanAndInf | 驱动程序是否应在PreparedStatement.setDouble()中允许NaN或+/- INF值？ | No | false | 3.1.5 |
autoDeserialize | 驱动程序是否应自动检测并串并转换保存在BLOB字段中的对象？ | No | false | 3.1.5 |
capitalizeTypeNames | 是否将DatabaseMetaData中的类型名转换为大写？ 通常仅在使用WebObjects时有用，真／假。默认为“假”。 | No | false | 2.0.7 |
clobberStreamingResults | 这会使“流式”结果集被自动关闭，如果在所有数据尚未从服务器中读取完之前，执行了另一查询，正在从服务器流出的任何未完成数据均将丢失。 | No | false | 3.0.9 |
continueBatchOnError | 如果一条语句失败，驱动程序是否应继续处理批命令？ JDBC规范允许任何一种方式（默认为“真”）。 | No | true | 3.0.3 |
createDatabaseIfNotExist | 如果不存在，创建URL中给定的数据库。假定用户具有创建数据库的权限。 | No | false | 3.1.9 |
emptyStringsConvertToZero | 驱动程序是否应允许从空字符串字段到数值“0”的转换？ | No | true | 3.1.8 |
emulateLocators | N/A | No | false | 3.1.0 |
emulateUnsupportedPstmts | 驱动程序是否应检测不被服务器支持的预处理语句，并用客户端模拟版替换它们？ | No | true | 3.1.7 |
ignoreNonTxTables | 是否忽略关于回退的非事务表？ 默认值为“假”。 | No | false | 3.0.9 |
jdbcCompliantTruncation | 连接到支持告警的服务器时（MySQL 4.1.0和更高版本），当按照JDBC的要求截短数据时，驱动程序是否应抛出java.sql.DataTruncation异常？ | No | true | 3.1.2 |
maxRows | 返回的最大行数（0，默认值表示返回所有行）。 | No | -1 | all versions |
noDatetimeStringSync | 不保证ResultSet.getDatetimeType().toString().equals(ResultSet.getString()。 | No | false | 3.1.7 |
nullCatalogMeansCurrent | 当DatabaseMetadataMethods请求“目录”参数时，值“Null”是否意味着使用当前目录？ 它不兼容JDBC，但符合驱动程序早期版本的传统行为。 | No | true | 3.1.8 |
nullNamePatternMatchesAll | 接受*pattern参数的DatabaseMetaData方法是否应将null按对待“％”的相同方式处理（不兼容JDBC，但驱动程序的早期版本能接受与规范的这类偏离）。 | No | true | 3.1.8 |
pedantic | 严格遵守JDBC规范。 | No | false | 3.0.0 |
relaxAutoCommit | 如果驱动程序所连接的MySQL服务器的版本不支持事务，仍允许调用commit()、rollback()和setAutoCommit()？真／假，默认为“假”。 | No | false | 2.0.13 |
retainStatementAfterResultSetClose | 调用ResultSet.close()后，驱动程序是否应将语句引用保存在结果集中？ 在JDBC-4.0后，与JDBC不兼容。 | No | false | 3.1.11 |
rollbackOnPooledClose | 当连接池中的逻辑连接关闭时，驱动程序是否应发出rollback()？ | No | true | 3.0.15 |
runningCTS13 | 允许在Sun与JDBC兼容的testsuite 1.3版中处理缺陷。 | No | false | 3.1.7 |
serverTimezone | 覆盖时区的检测/映射。当服务器的时区为映射到Java时区时使用。 | No | 3.0.2 | |
strictFloatingPoint | 仅在兼容性测试的早期版本中使用。 | No | false | 3.0.0 |
strictUpdates | 驱动程序是否应对可更新结果集进行严格检查（选择所有的主键）？真／假，默认为“真”。 | No | true | 3.0.4 |
tinyInt1isBit | 驱动程序是否应将数据类型TINYINT(1)当作BIT类型对待？创建表时，服务器会执行BIT -> TINYINT(1)操作。 | No | true | 3.0.16 |
transformedBitIsBoolean | 如果驱动程序将TINYINT(1)转换为不同的类型，为了与MySQL-5.0兼容，驱动程序是否应使用BOOLEAN取代BIT？这是因为MySQL-5.0具有BIT类型。 | No | false | 3.1.9 |
ultraDevHack | 由于UltraDev已损坏，并为所有语句发出了prepareCall()，需要时，是否要为prepareCall()创建PreparedStatements? 真／假，默认值为“假”。 | No | false | 2.0.3 |
useHostsInPrivileges | 在DatabaseMetaData.getColumn/TablePrivileges()中为用户添加“@hostname”。真／假，默认为“真”。 | No | true | 3.0.2 |
useOldUTF8Behavior | 与4.0和更早版本的服务器进行通信时，使用UTF-8。 | No | false | 3.1.6 |
useOnlyServerErrorMessages | 对服务器返回的错误消息，不事先设定“标准的”SQLState错误消息。 | No | true | 3.0.15 |
useServerPrepStmts | 如果服务器支持，是否使用服务器端预处理语句？ 默认值为“真”。 | No | true | 3.1.0 |
useSqlStateCodes | 使用SQL标准状态码取代“传统的”X/Open/SQL状态码，真／假，默认为“真”。 | No | true | 3.1.3 |
useStreamLengthsInPrepStmts | 是否采用PreparedStatement/ResultSet.setXXXStream()方法调用中的流长度参数？真／假，默认为“真”。 | No | true | 3.0.2 |
useTimezone | 是否在客户端和服务器时区间转换时间／日期类型（真／假，默认为“假”）？ | No | false | 3.0.2 |
useUnbufferedInput | 不使用BufferedInputStream来从服务器读取数据。 | No | true | 3.0.11 |
yearIsDateType | JDBC驱动程序是否应将MySQL类型“YEAR”当作java.sql.Date或SHORT对待？ | No | true | 3.1.9 |
zeroDateTimeBehavior | 当驱动程序遇到全由0组成的DATETIME值时，应出现什么？MySQL使用它来表示无效日期。有效值是“exception”、“round”和“convertToNull”。 | No | exception | 3.1.4 |
通过“socketFactory”属性，使用NamedPipeSocketFactory，在Windows NT/2000/XP平台上，通过命名管道，Connector/J也支持对MySQL的访问。如果不使用namedPipePath属性，将使用\\.\pipe\MySQL的默认值。如果使用NamedPipeSocketFactory，将忽略JDBC url中的主机名和端口号。
在URL中添加下述属性可启用NamedPipeSocketFactory：
socketFactory=com.mysql.jdbc.NamedPipeSocketFactory
命名管道仅能当连接到位于相同物理机器上的MySQL时才能正常工作，该机器上应使用了JDBC驱动程序。在简单的性能测试中，命名管道的访问速度比标准的TCP/IP访问块30～50％。
使用com.mysql.jdbc.NamedPipeSocketFactory或com.mysql.jdbc.StandardSocketFactory中的示例代码，可创建你自己的套接字代理。
26.3.3.2. JDBC API实施说明
MySQL Connector/J通过了Sun JDBC兼容测试套件公共版中的所有测试。但是，在很多场合下，对于应如何实施特定的功能，JDBC规范并未给出明确的规定，或者说，该规范允许有一定的实施范围。在本节中，就特定实施方案将如何影响MySQL Connector/J的使用方式，给出了接口层面上的详细介绍。
·Blob
Blob实施不允许“原地”调整（它们是“副本”，正如DatabaseMetaData.locatorsUpdateCopies()方法所指明的那样）。因此，应使用对应的PreparedStatement.setBlob()或ResultSet.updateBlob()（对于可更新结果集）方法，将变化保存到数据库中。
自Connector/J version 3.1.0开始，通过在JDBC URL中添加属性“emulateLocators=true”，能够使用定位器模拟Blob。随后，必须使用带有列值的列别名，在你编写的用于检索Blob的SELECT中，将列值设为Blob列的世纪名称。SELECT还必须仅引用1个表，该表必须有1个主键，而且SELECT必须涵盖构成主键的所有列。随后，驱动程序将延期加载实际的Blob数据，直至检索了Blob并在其上调用了检索方法为止（getInputStream(), getBytes(),等）。
·CallableStatement
自Connector/J 3.1.1开始，当通过CallableStatement接口连接到MySQL 5.0或更高版本时，可支持存储程序。目前，不支持CallableStatement的getParameterMetaData()方法。
·Clob
Clob实施不允许“原地”调整（它们是“副本”，正如DatabaseMetaData.locatorsUpdateCopies()方法所指明的那样）。因此，应使用PreparedStatement.setClob()方法将变更保存到数据库中。JDBC API没有ResultSet.updateClob()方法。
·Connection
与MM.MySQL的早期版本不同，“isClosed()”不会对服务器即行Ping操作以确定服务器是否有效。按照JDBC规范，如果在连接上调用了“closed()”，它仅返回“真”。如果需要确定连接是否依然有效，应发出简单查询，如“SELECT 1”。如果连接不再有效，驱动程序将抛出异常。
·DatabaseMetaData
对于外键信息（getImported/ExportedKeys()和getCrossReference()），仅在“InnoDB”类性的表中可用。但是，驱动程序会使用“SHOW CREATE TABLE”来检索该信息，因此，当其他表类型支持外键时，驱动程序也能支持它们。
·Driver
·PreparedStatement
PreparedStatements是由驱动程序实现的，这是应为MySQL未提供预处理语句功能。出于该原因，驱动程序不实施getParameterMetaData()或getMetaData()，这是因为，它要求驱动程序在客户端上具有完整的SQL语法分析程序。
从3.1.0版MySQL Connector/J开始，当服务器支持时，将使用服务器端预处理语句和“二进制编码”的结果集。
使用带有“large”参数（这类参数是通过setBinaryStream()、setAsciiStream()、setUnicodeStream()、setBlob()或setClob()设置的）的服务器端预处理语句时应谨慎。如果打算再次执行已将任何“large”参数更改为非“large”参数的语句，需要调用clearParameters()，并再次设置所有参数。其原因如下：
o 设置了参数时，驱动程序会将“large”数据“out-of-band”发送给服务器端的预处理语句（执行预处理语句之前）。
o 一旦完成，将关闭用于读取客户端上数据的流（根据JDBC规范），而且不能再次读取流。
o 如果参数从“large”变为非“large”，驱动程序必须复位预处理语句的服务器端状态，以便允许已更改的参数区带以前的“large”值。这将删除已发送给服务器的所有“large”数据，因而需要通过setBinaryStream()、setAsciiStream()、setUnicodeStream()、setBlob()或setClob()方法再次发送数据。
因而，如果你打算将参数类型更改为非“large”类型，必须调用clearParameters()，并在重新执行预处理语句之前再次设置预处理语句的所有参数。
·ResultSet
在默认情况下，ResultSets（结果集）是可完全检索的，并被保存在内存中。对于大多数情况，这是最有效的操作方式，而且还应归因于更容易实施的MySQL网络协议设计。如果你正在处理具有大量行或大数据的ResultSets，而且无法在JVM内为所需内存分配大量空间，可以通知驱动程序以“流”方式返回结果，一次一行。
要想允许该功能，需要以下述方式创建1个语句实例：
stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,
java.sql.ResultSet.CONCUR_READ_ONLY);
stmt.setFetchSize(Integer.MIN_VALUE);
正向、只读结果集，以及Integer.MIN_VALUE的组合用于指示驱动程序以“流”方式按行处理结果集。此后，对于该语句创建的结果集，将按行检索。
对于该方式，有一些需注意的事项。能够在连接上发出任何其他查询之前，应读取结果集中的所有行（或关闭结果集），否则将抛出异常。
能够释放这些锁定语句（无论它们是MyISAM表级锁定，还是某些其他存储引擎如InnoDB中的行级锁定）的最早时刻是完成语句时。
如果语句在事务的范围内，当事务完成后将释放锁定（它意味着语句需首先完成）。与大多数其他数据库一样，在读取了语句上所有的未决结果集或关闭了语句的活动结果集之前，语句不会结束。
因此，如果正在使用“流式”结果，如果希望保持对特定表的同时访问，而这些表被生成结果集的语句所引用，就应尽快地处理“流式”结果。
·ResultSetMetaData
仅当使用MySQL服务器4.0或更高版本时，“isAutoIncrement()”方法才能正确工作。
·Statement
使用版本低于3.2.1的JDBC驱动程序，而且所连接的服务器版本低于5.0.3时，除了像前面介绍的那样切换结果集外，“setFetchSize()”方法不起作用。
MySQL不支持SQL光标，而且JDBC驱动程序也不能模拟它们，因此“setCursorName()”没有效果。
26.3.3.3. Java，JDBC和MySQL类型
MySQL Connector/J在处理MySQL数据类型和Java数据类型的转换处理方面十分灵活。
尽管可能会出现舍入、溢出或精度损失，当在通常情况下，能够将任何MySQL数据类型转换为java.lang.String，并能将任何数值类型转换为Java数值类型。
从Connector/J 3.1.0开始，按照JDBC规范的要求，JDBC驱动程序将发出警告或抛出DataTruncation异常，除非通过使用“jdbcCompliantTruncation”属性并将其设为“假”，对连接进行相应配置取消了前述要求。
在下面的表格中，列出能可靠工作的转换：
表26.2. 转换表
下述MySQL数据类型 | 总能转换为下述Java类型 |
CHAR, VARCHAR, BLOB, TEXT, ENUM, and SET | java.lang.String, java.io.InputStream, java.io.Reader, java.sql.Blob, java.sql.Clob |
FLOAT, REAL, DOUBLE PRECISION, NUMERIC, DECIMAL, TINYINT, SMALLINT, MEDIUMINT, INTEGER, BIGINT | java.lang.String, java.lang.Short, java.lang.Integer, java.lang.Long, java.lang.Double, java.math.BigDecimal 注释：与希望转换的MySQL数据类型相比，如果选择了精度较低的Java数值类型，可能会出现舍入、溢出或精度损失。 |
DATE, TIME, DATETIME, TIMESTAMP | java.lang.String, java.sql.Date, java.sql.Timestamp |
在MySQL类型和Java类型之间，ResultSet.getObject()方法采用了下述类型转换方式，在可能的情况下遵从JDBC规范：
表26.3. 用于ResultSet.getObject()的MySQL类型和Java类型
MySQL类型名称 | 以Java类返回 |
BIT(1) (new in MySQL-5.0) | java.lang.Boolean |
BIT( > 1) (new in MySQL-5.0) | byte[] |
TINYINT | java.lang.Boolean，如果将配置属性“tinyInt1isBit”设为“真”（默认值），并将存储大小设为“1”；或java.lang.Integer，如果不是的话。 |
BOOL , BOOLEAN | 请参见上面的TINYINT，它们目前是TINYINT(1)的别名。 |
SMALLINT[(M)] [UNSIGNED] | java.lang.Integer（无论是否为UNSIGNED） |
MEDIUMINT[(M)] [UNSIGNED] | java.lang.Integer（无论是否为UNSIGNED） |
INT,INTEGER[(M)] [UNSIGNED] | java.lang.Integer，如果是UNSIGNED，java.lang.Long |
BIGINT[(M)] [UNSIGNED] | java.lang.Long，如果是UNSIGNED，java.math.BigInteger |
FLOAT[(M,D)] | java.lang.Float |
DOUBLE[(M,B)] | java.lang.Double |
DECIMAL[(M[,D])] | java.math.BigDecimal |
DATE | java.sql.Date |
DATETIME | java.sql.Timestamp |
TIMESTAMP[(M)] | java.sql.Timestamp |
TIME | java.sql.Time |
YEAR[(2|4)] | java.sql.Date（日期设为2月1日晚上2点） |
CHAR(M) | java.lang.String（除非列的字符集是BINARY），然后返回字节[] |
VARCHAR(M) [BINARY] | java.lang.String（除非列的字符集是BINARY），然后返回字节[] |
BINARY(M) | byte[] |
VARBINARY(M) | byte[] |
TINYBLOB | byte[] |
TINYTEXT | java.lang.String |
BLOB | byte[] |
TEXT | java.lang.String |
MEDIUMBLOB | byte[] |
MEDIUMTEXT | java.lang.String |
LONGBLOB | byte[] |
LONGTEXT | java.lang.String |
ENUM('value1','value2',...) | java.lang.String |
SET('value1','value2',...) | java.lang.String |
26.3.3.4. 使用字符集和Unicode
对于从JDBC驱动程序发往服务器的所有字符串，均将自动地从固有放热Java Unicode形式转换为客户端字符编码，包括通过Statement.execute()、Statement.executeUpdate()和Statement.executeQuery()发出的所有查询，以及除了用setBytes()、setBinaryStream()、setAsiiStream()、setUnicodeStream()和setBlob()排除的参试之外的所有PreparedStatement和CallableStatement参数。
在MySQL服务器4.1之前，Connector/J支持每连接单一字符编码，能够从服务器配置自动检测到它，也能由用户通过使用useUnicode和characterEncoding属性配置它。
从MySQL服务器4.1版起，Connector/J支持客户端和服务器之间的但以字符编码，以及针对结果集中从服务器返回至客户端的数据的任意数目字符编码。
连接时将自动检测客户端和服务器之间的字符编码。对于由驱动程序使用的编码来说，它是在服务器上通过使用配置变量“character_set”（低于4.1.0的服务器版本）和“character_set_server”（4.1.0和更高的服务器版本）指定的。更多信息，请参见MySQL服务器手册中的服务器字符集和校对一节。
要想覆盖客户端上的自动检测编码功能，可在用于连接到服务器的URL中使用“characterEncoding”属性。
在客户端上指定字符编码时，应使用Java风格名称。在下面的表格中，列出了用于MySQL字符集的Java风格名称：
表26.4. MySQL对Java编码名称的翻译
| MySQL字符集名称 | Java风格字符编码名称 |
|---|---|
| usa7 | US-ASCII |
| big5 | Big5 |
| gbk | GBK |
| sjis | SJIS |
| gb2312 | EUC_CN |
| ujis | EUC_JP |
| euc_kr | EUC_KR |
| latin1 | ISO8859_1 |
| latin1_de | ISO8859_1 |
| german1 | ISO8859_1 |
| danish | ISO8859_1 |
| latin2 | ISO8859_2 |
| czech | ISO8859_2 |
| hungarian | ISO8859_2 |
| croat | ISO8859_2 |
| greek | ISO8859_7 |
| hebrew | ISO8859_8 |
| latin5 | ISO8859_9 |
| latvian | ISO8859_13 |
| latvian1 | ISO8859_13 |
| estonia | ISO8859_13 |
| dos | Cp437 |
| pclatin2 | Cp852 |
| cp866 | Cp866 |
| koi8_ru | KOI8_R |
| tis620 | TIS620 |
| win1250 | Cp1250 |
| win1250ch | Cp1250 |
| win1251 | Cp1251 |
| cp1251 | Cp1251 |
| win1251ukr | Cp1251 |
| cp1257 | Cp1257 |
| macroman | MacRoman |
| macce | MacCentralEurope |
| utf8 | UTF-8 |
| ucs2 | UnicodeBig |
警告
不要用Connector/J发出查询“set names”，这是因为驱动程序不会检测已变化的字符集，而是会继续使用在初始连接设置中检测到的字符集。
为了允许从客户端发出的多个字符集，应使用“UTF-8”编码，方式是，将utf8配置为默认的服务器字符集，或通过“characterEncoding”属性配置JDBC驱动程序以使用“UTF-8”。
26.3.3.5. 使用SSL进行安全连接
MySQL Connector/J中的SSL能够对JDBC驱动程序和服务器之间传输的所有数据进行加密（除了初始握手数据）。启用SSL会导致性能损失，体现在查询时间将增加35～50％，具体情况取决于查询的大小以及返回的数据量。要想使SSL支持能够工作，必须满足下述要求：
·包含JSSE（Java安全套接字扩展）的JDK，如JDK-1.4.1或更高版本。SSL目前不能与能够为其添加JSSE的JDK一起工作，如JDK-1.2.x或JDK-1.3.x，原因在于下述JSSE缺陷：http://developer.java.sun.com/developer/bugParade/bugs/4273544.html
·支持SSL并已编译和配置了该功能的MySQL服务器，如MySQL-4.0.4和更高版本，请参见：http://www.mysql.com/doc/en/Secure_connections.html
·客户端证书（在本节稍后介绍）。
首先，需要将MySQL服务器CA证书导入到Java truststore。在MySQL源码分发版的“SSL”子目录下给出了1个示例MySQL服务器CA证书。SSL将使用它来确定是否与安全MySQL服务器进行通信。
要想使用Java的“keytool”在当前目录下创建truststore，并导入服务器的CA证书（“cacert.pem”），可采取下述方式（假定“keytool”位于路径中。它位于JDK或JRE的“bin”子目录下）：
shell> keytool -import -alias mysqlServerCACert -file cacert.pem -keystore truststore
Keytool将给出下述响应信息：
Enter keystore password: *********
Owner: EMAILADDRESS=walrus@example.com, CN=Walrus, O=MySQL AB, L=Orenburg, ST=Some
-State, C=RU
Issuer: EMAILADDRESS=walrus@example.com, CN=Walrus, O=MySQL AB, L=Orenburg, ST=Som
e-State, C=RU
Serial number: 0
Valid from: Fri Aug 02 16:55:53 CDT 2002 until: Sat Aug 02 16:55:53 CDT 2003
Certificate fingerprints:
MD5: 61:91:A0:F2:03:07:61:7A:81:38:66:DA:19:C4:8D:AB
SHA1: 25:77:41:05:D5:AD:99:8C:14:8C:CA:68:9C:2F:B8:89:C3:34:4D:6C
Trust this certificate? [no]: yes
Certificate was added to keystore
随后，需要生成客户端证书，以便MySQL服务器知道它正与安全客户端进行通信：
shell> keytool -genkey -keyalg rsa -alias mysqlClientCertificate -keystore keystore
Keytool将给出下述提示信息，并在当目录下创建名为“keystore”的密钥存储器。
你应使用与具体情况相适应的新作出响应：
Enter keystore password: *********
What is your first and last name?
[Unknown]: Matthews
What is the name of your organizational unit?
[Unknown]: Software Development
What is the name of your organization?
[Unknown]: MySQL AB
What is the name of your City or Locality?
[Unknown]: Flossmoor
What is the name of your State or Province?
[Unknown]: IL
What is the two-letter country code for this unit?
[Unknown]: US
Is <CN=Matthews, OU=Software Development, O=MySQL AB,
L=Flossmoor, ST=IL, C=US> correct?
[no]: y
输入<mysqlClientCertificate>的密码
如果与keystore的密码相同，按回车）：
最后，要想使JSSE能够使用你生成的keystore和truststore，启动JVM时，需要设置下述系统属性，用你所创建的keystore文件完整路径替换“path_to_keystore_file”，用你所创建的truststore文件完整路径替换“path_to_truststore_file”，并为每个属性使用恰当的密码值。
-Djavax.net.ssl.keyStore=path_to_keystore_file
-Djavax.net.ssl.keyStorePassword=*********
-Djavax.net.ssl.trustStore=path_to_truststore_file
-Djavax.net.ssl.trustStorePassword=*********
此外，还需要在用于MySQL Connector/J的连接参数中将“useSSL”设置为“真”，方法是，在URL中添加“useSSL=true”，或在准备传递给DriverManager.getConnection()的java.util.Properties实例中将“useSSL”设置为“真”。
你可以打开JSSE调试功能能够，测试SSL是否工作（详情如下），并查找下述关键事件：
...
*** ClientHello, v3.1
RandomCookie: GMT: 1018531834 bytes = { 199, 148, 180, 215, 74, 12, 54, 244, 0, 168, 55, 103, 215, 64, 16, 138, 225, 190, 132, 153, 2, 217, 219, 239, 202, 19, 121, 78 } Session ID: {} Cipher Suites: { 0, 5, 0, 4, 0, 9, 0, 10, 0, 18, 0, 19, 0, 3, 0, 17 } Compression Methods: { 0 }***
[write] MD5 and SHA1 hashes: len = 59
0000: 01 00 00 37 03 01 3D B6 90 FA C7 94 B4 D7 4A 0C ...7..=.......J.
0010: 36 F4 00 A8 37 67 D7 40 10 8A E1 BE 84 99 02 D9 6...7g.@........
0020: DB EF CA 13 79 4E 00 00 10 00 05 00 04 00 09 00 ....yN..........
0030: 0A 00 12 00 13 00 03 00 11 01 00 ...........
main, WRITE: SSL v3.1 Handshake, length = 59
main, READ: SSL v3.1 Handshake, length = 74
*** ServerHello, v3.1
RandomCookie: GMT: 1018577560 bytes = { 116, 50, 4, 103, 25, 100, 58, 202, 79, 185, 178, 100, 215, 66, 254, 21, 83, 187, 190, 42, 170, 3, 132, 110, 82, 148, 160, 92 } Session ID: {163, 227, 84, 53, 81, 127, 252, 254, 178, 179, 68, 63, 182, 158, 30, 11, 150, 79, 170, 76, 255, 92, 15, 226, 24, 17, 177, 219, 158, 177, 187, 143} Cipher Suite: { 0, 5 }Compression Method: 0
***
%% Created: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
** SSL_RSA_WITH_RC4_128_SHA
[read] MD5 and SHA1 hashes: len = 74
0000: 02 00 00 46 03 01 3D B6 43 98 74 32 04 67 19 64 ...F..=.C.t2.g.d
0010: 3A CA 4F B9 B2 64 D7 42 FE 15 53 BB BE 2A AA 03 :.O..d.B..S..*..
0020: 84 6E 52 94 A0 5C 20 A3 E3 54 35 51 7F FC FE B2 .nR..\ ..T5Q....
0030: B3 44 3F B6 9E 1E 0B 96 4F AA 4C FF 5C 0F E2 18 .D?.....O.L.\...
0040: 11 B1 DB 9E B1 BB 8F 00 05 00 ..........
main, READ: SSL v3.1 Handshake, length = 1712
...
设置了下述系统属性时，JSSE可提供调试功能（为STDOUT）：-Djavax.net.debug=all。它用于设定要使用的keystores和truststores，以及在SSL握手和证书交换过程中将出现什么。当你尝试进行SSL连接时，如果打算确定不能工作的部分，该设置十分有用。
26.3.3.6. 使用主／从复制和ReplicationConnection
从Connector/J 3.1.7开始，我们提供了1个驱动程序变体，它能自动发出读／写主服务器的查询，或根据Connection.getReadOnly()的状态对从主机进行故障切换或循环负载平衡设置。
应用程序发出信号，通过调用Connection.setReadOnly(true)指明事务为只读的，该具有“复制意识”的连接将使用从连接之一，从连接是采用了循环方案的负载平衡per-vm（给定连接与从连接密切相关，除非在服务中删除了从连接）。如果你有1项写事务，或1项对时间敏感的读事务（记住，在MySQL中，复制是以异步方式进行的），请调用Connection.setReadOnly(false)，将连接设置为非只读的，驱动程序会确保进一步的调用均将被发送到主MySQL服务器。驱动程序负责传播autocommit的当前状态，隔离级别，以及用于完成该负载平衡功能的所有连接之间的目录。
要想启用该该功能，在配置应用服务器的连接池时，或为独立应用程序创建JDBC驱动实例时，请使用“com.mysql.jdbc.ReplicationDriver”类。由于它能接受与标准MySQL JDBC驱动相同的URL格式，ReplicationDriver目前不能与基于java.sql.DriverManager的连接一起使用，除非它是用DriverManager注册的唯一MySQL JDBC驱动程序。
下面给出了一个简短的简单示例，介绍了如何在独立应用程序中使用ReplicationDriver的方法。
import java.sql.Connection;
import java.sql.ResultSet;
import java.util.Properties;
import com.mysql.jdbc.ReplicationDriver;
public class ReplicationDriverDemo { public static void main(String[] args) throws Exception {ReplicationDriver driver = new ReplicationDriver();
Properties props = new Properties();
// We want this for failover on the slaves
props.put("autoReconnect", "true");// We want to load balance between the slaves
props.put("roundRobinLoadBalance", "true");props.put("user", "foo");props.put("password", "bar");//
// Looks like a normal MySQL JDBC url, with a comma-separated list
// of hosts, the first being the 'master', the rest being any number
// of slaves that the driver will load balance against
//
Connection conn =
driver.connect("jdbc:mysql://master,slave1,slave2,slave3/test",props);
//
// Perform read/write work on the master
// by setting the read-only flag to "false"
//
conn.setReadOnly(false);
conn.setAutoCommit(false);
conn.createStatement().executeUpdate("UPDATE some_table ....");conn.commit();
//
// Now, do a query from a slave, the driver automatically picks one
// from the list
//
conn.setReadOnly(true);
ResultSet rs = conn.createStatement().executeQuery("SELECT a,b,c FROM some_other_table");.......
}
}
26.3.4. 与J2EE和其他Java框架一起使用 Connector/J
- 26.3.4.1. 一般J2EE概念
- 26.3.4.2. 与Tomcat一起使用Connector/J
- 26.3.4.3. 与JBoss一起使用Connector/J
26.3.4.1. 一般J2EE概念
- 26.3.4.1.1. 理解连接池
26.3.4.1.1. 理解连接池
连接池是创建和管理多个连接的一种技术，这些连接可被需要使用它们的任何线程使用。连接池技术基于下述事实：对于大多数应用程序，当它们正在处理通常需要数毫秒完成的事务时，仅需要能够访问JDBC连接的1个线程。未处理事务时，连接处于闲置状态。使用连接池，允许其他线程使用闲置连接来执行有用的任务。事实上，当某一线程需要用JDBC在MySQL或其他数据库上执行操作时，需要用到由连接池提供的连接。使用连接完成线程后，线程会将连接返回给连接池，以便该连接能够被其他需要使用连接的线程使用。
从连接池“借出”连接时，该连接仅供请求它的线程使用。从编程观点看，其效果等同于每次需要JDBC连接时调用DriverManager.getConnection()，但是，采用连接池技术，可通过使用新的或已有的连接结束线程。
连接池技术能显著增加Java应用程序的性能，同时还能降低资源使用率。连接池技术的主要优点包括：
·缩短了连接创建时间
与其他数据库相比，MySQL提供了快速的连接设置功能，连接时间通常不是问题，但创建新的JDBC连接仍会导致联网操作和一定的IDBC驱动开销，如果这类连接是“循环”使用的，使用该方式，可避免这类不利因素。
·简化的编程模型
使用连接池技术时，每个单独线程能够像创建了自己的JDBC连接那样进行操作，从而允许使用直接的JDBC编程技术。
·受控的资源使用
如果不使用连接池技术，而是在每次需要时为线程创建新的连接，那么应用程序的资源使用将十分浪费，而且在负载较重的情况下会导致无法预期的结果。
注意，与MySQL的每个连接均会在客户端和服务器端造成一定的开销（每寸、CPU、关联转换等）。每个连接均会对应用程序和MySQL服务器的可用资源带来一定的限制。无论连接是否执行任何有用的任务，仍将使用这些资源中的相当一部分。
连接池能够使性能最大化，同时还能将资源利用控制在一定的水平之下，如果超过该水平，应用程序将崩溃而不仅仅是变慢。
幸运的是，Sun公司通过JDBC-2.0“可选”接口，完成了JDBC中连接池概念的标准化实施，所有主要应用服务器均实施了能够与MySQL Connector/J一起良好工作的这类API。
通常，你可以在应用服务器的配置文件中配置连接池，并通过Java命名和目录接口（JNDI）访问它。在下面的代码中，介绍了在J2E应用服务器上运行的应用程序中使用连接池的方法：
示例26.12. 与J2EE应用服务器一起使用连接池
import java.sql.Connection;import java.sql.SQLException;import java.sql.Statement;import javax.naming.InitialContext;import javax.sql.DataSource;public class MyServletJspOrEjb { public void doSomething() throws Exception {/* * Create a JNDI Initial context to be able to * lookup the DataSource * * In production-level code, this should be cached as * an instance or static variable, as it can * be quite expensive to create a JNDI context. * * Note: This code only works when you are using servlets * or EJBs in a J2EE application server. If you are * using connection pooling in standalone Java code, you * will have to create/configure datasources using whatever * mechanisms your particular connection pooling library * provides. */InitialContext ctx = new InitialContext(); /* * Lookup the DataSource, which will be backed by a pool * that the application server provides. DataSource instances * are also a good candidate for caching as an instance * variable, as JNDI lookups can be expensive as well. */DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/MySQLDB");/* * The following code is what would actually be in your * Servlet, JSP or EJB 'service' method...where you need * to work with a JDBC connection. */Connection conn = null;Statement stmt = null;try { conn = ds.getConnection(); /* * Now, use normal JDBC programming to work with * MySQL, making sure to close each resource when you're * finished with it, which allows the connection pool * resources to be recovered as quickly as possible */ stmt = conn.createStatement(); stmt.execute("SOME SQL QUERY"); stmt.close(); stmt = null; conn.close(); conn = null;} finally { /* * close any jdbc instances here that weren't * explicitly closed during normal code path, so * that we don't 'leak' resources... */ if (stmt != null) {try { stmt.close();} catch (sqlexception sqlex) { // ignore -- as we can't do anything about it here}stmt = null; } if (conn != null) {try { conn.close();} catch (sqlexception sqlex) { // ignore -- as we can't do anything about it here}conn = null; }} }}如上例所示，获得JNDI InitialContext并查找到数据库后，其余代码与过去在JDBC编程中使用的类似。
使用连接池时需要牢记的最重要事项是，无论在代码中出现了什么（异常、控制流等），连接以及由连接创建的任何部分（语句、结果集等）均应被关闭，以便能再次使用它们。如不然，它们将纠缠在一起，在最好的情况下，意味着它们所代表的MySQL服务器资源（缓冲区、锁定、套接字等）可能会捆绑一段时间，在最坏的情况下，可能会导致永久捆绑。
连接池的最佳大小是什么？
与所有其他配置经验规则一样，回答是“它取决于具体情况”。尽管最佳大小取决与预期的负载和平均的数据库事务时间，最佳的连接池大小小于你的预期。例如，如果使用的是Sun公司的Java Petstore Blueprint应用程序，对于包含15～20个连接的连接池，使用MySQL和Tomcat，在可接受的相应时间下，可服务于中等程度的负载（600个并发用户）。
要想确定用于应用程序的连接池大小，应使用诸如Apache Jmeter或The Grinder等工具创建负载测试脚本，并对应用程序进行负载测试。
确定出发点的一种简单方法是，将连接池的最大连接数配置为“无限”，运行负载测试，并测量最大的并发连接数。随后，应进行反向操作，确定出使应用程序具有最佳性能的连接池的最小和最大值。
26.3.4.2. 与Tomcat一起使用Connector/J
下述内容基于关于Tomcat-5.x的指示说明，http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-datasource-examples-howto.html，在编写本文档时它是最新的。
首先安装与Connector/J in $CATALINA_HOME/common/lib一起提供的.jar文件，以便它能用于已安装的所有应用程序。
其次，在定义Web应用程序的Context（场景）内，通过为$CATALINA_HOME/conf/server.xml增加声明资源，配置JNDI DataSource：
<Context ....> ... <Resource name="jdbc/MySQLDB" auth="Container" type="javax.sql.DataSource"/> <!-- The name you used above, must match _exactly_ here! The connection pool will be bound into JNDI with the name "java:/comp/env/jdbc/MySQLDB" --> <ResourceParams name="jdbc/MySQLDB"> <parameter> <name>factory</name> <value>org.apache.commons.dbcp.BasicDataSourceFactory</value> </parameter> <!-- Don't set this any higher than max_connections on your MySQL server, usually this should be a 10 or a few 10's of connections, not hundreds or thousands --> <parameter> <name>maxActive</name> <value>10</value> </parameter> <!-- You don't want to many idle connections hanging around if you can avoid it, only enough to soak up a spike in the load --> <parameter> <name>maxIdle</name> <value>5</value> </parameter> <!-- Don't use autoReconnect=true, it's going away eventually and it's a crutch for older connection pools that couldn't test connections. You need to decide if your application is supposed to deal with SQLExceptions (hint, it should), and how much of a performance penalty you're willing to pay to ensure 'freshness' of the connection --> <parameter> <name>validationQuery</name> <value>SELECT 1</value> </parameter> <!-- The most conservative approach is to test connectionsbefore they're given to your application. For most applicationsthis is okay, the query used above is very small and takesno real server resources to process, other than the time usedto traverse the network.If you have a high-load application you'll need to rely onsomething else. --> <parameter> <name>testOnBorrow</name> <value>true</value> </parameter> <!-- Otherwise, or in addition to testOnBorrow, you can testwhile connections are sitting idle --> <parameter> <name>testWhileIdle</name> <value>true</value> </parameter> <!-- You have to set this value, otherwise even though you've asked connections to be tested while idle, the idle evicter thread will never run --> <parameter> <name>timeBetweenEvictionRunsMillis</name> <value>10000</value> </parameter> <!-- Don't allow connections to hang out idle too long, never longer than what wait_timeout is set to on the server...A few minutes or even fraction of a minute is sometimes okay here, it depends on your application and how much spikey load it will see --> <parameter> <name>minEvictableIdleTimeMillis</name> <value>60000</value> </parameter> <!-- Username and password used when connecting to MySQL --> <parameter> <name>username</name> <value>someuser</value> </parameter> <parameter> <name>password</name> <value>somepass</value> </parameter> <!-- Class name for the Connector/J driver --> <parameter> <name>driverClassName</name> <value>com.mysql.jdbc.Driver</value> </parameter> <!-- The JDBC connection url for connecting to MySQL, notice that if you want to pass any other MySQL-specific parameters you should pass them here in the URL, setting them using the parameter tags above will have no effect, you will also need to use & to separate parameter values as the ampersand is a reserved character in XML --> <parameter> <name>url</name> <value>jdbc:mysql://localhost:3306/test</value> </parameter> </ResourceParams></Context>
一般而言，应遵循关于相应Tomcat版本的安装说明，这是因为，在Tomcat中配置数据源的方式会随时变化，很不幸，如果在XML文件中使用了错误的语法，很可能会以异常结束，如下所示：
Error: java.sql.SQLException: Cannot load JDBC driver class 'null ' SQLstate: null
26.3.4.3. 与JBoss一起使用Connector/J
下述说明适用于JBoss-4.x。要想使应用服务器能够使用JDBC驱动类，请将与Connector/J一起提供的.jar文件拷贝到用于服务器配置的lib目录下（通常称为“默认”）。随后，在相同的配置目录下，在名为“deploy”的子目录下，创建以“-ds.xml”结尾的数据源配置文件，用于通知Jboss将该文件当作JDBC数据源。该文件应包含下述内容：
<datasources> <local-tx-datasource><!-- This connection pool will be bound into JNDI with the name "java:/MySQLDB" --><jndi-name>MySQLDB</jndi-name><connection-url>jdbc:mysql://localhost:3306/dbname</connection-url><driver-class>com.mysql.jdbc.Driver</driver-class><user-name>user</user-name><password>pass</password><min-pool-size>5</min-pool-size><!-- Don't set this any higher than max_connections on your MySQL server, usually this should be a 10 or a few 10's of connections, not hundreds or thousands --><max-pool-size>20</max-pool-size><!-- Don't allow connections to hang out idle too long, never longer than what wait_timeout is set to on the server...A few minutes is usually okay here, it depends on your application and how much spikey load it will see --><idle-timeout-minutes>5</idle-timeout-minutes><!-- If you're using Connector/J 3.1.8 or newer, you can use our implementation of these to increase the robustness of the connection pool. --><exception-sorter-class-name>com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter</exception-sorter-class-name><valid-connection-checker-class-name>com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker</valid-connection-checker-class-name> </local-tx-datasource></datasources>
26.3.5. 诊断 Connector/J方面的问题
- 26.3.5.1. 常见问题和解决方案
- 26.3.5.2. 如何通报缺陷和问题
26.3.5.1. 常见问题和解决方案
对于MySQL Connector/J用户，会遇到一些常见的共同问题。在本节中，介绍了它们的症状和相应的解决方法。 关于更进一步的信息，请参见“支持”一节。
27.3.5.1.1:
问题：
当我尝试用MySQL Connector/J连接到数据库时，遇到下述异常：
SQLException: Server configuration denies access to data source
SQLState: 08001
VendorError: 0
出现了什么问题？ 使用MySQL命令行客户端时，连接良好。
回答：
MySQL Connector/J必须使用TCP/IP套接字来连接MySQL，原因在于Java不支持Unix Domain套接字。因此，当MySQL Connector/J连接到MySQL时，MySQL服务器的安全管理器将使用其授权表判断是否允许连接。必须添加授权才能允许该操作。下面给出了一个执行该操作的示例（但并非最安全的）。
从mysql命令行客户端以能够授权的用户身份登录，并发出下述命令：
GRANT ALL PRIVILEGES ON [dbname].* to
'[user]'@'[hostname]' identified by
'[password]'
用你的数据库名称替换[dbname]，用用户名替换[user]，用MySQL Connector/J将连接的主机替换[hostname]，并用打算使用的密码替换[password]。注意，对于从本地主机进行连接的主机名部分，RedHat Linux将失败。在这种情况下，对于[hostname]值，需要使用“localhost.localdomain”。随后，发出FLUSH PRIVILEGES命令。
注释：
除非添加了“--host”标志，并为主机使用了不同于“localhost”的其他设置，否则将无法使用mysql命令行客户端测试连通性。如果使用了特殊的主机名“localhost”，mysql命令行客户端将使用Unix域套接字。如果正在测试与“localhost”的连通性，请使用“127.0.0.1”作为主机名。
警告
如果你不了解“GRANT”命令是干什么的，或不了解该命令的工作方式，在尝试更改权限之前，请阅读MySQL手册中的 一般安全事宜以及MySQL访问权限体系一节。
如果在MySQL中不恰当地更改了权限和许可，可能会使服务器不会具有最佳的安全性能。
27.3.5.1.2:
问题：
我的应用程序抛出SQLException“无恰当的驱动程序”。为什么会出现该情况？
回答：
出现了两种情况之一。或是1驱动程序未位于你的CLASSPATH中（请参见前面的“安装部分”），或是URL格式不正确（请参见用MySQL Connector/J开发应用程序）。
27.3.5.1.3:
问题：
当我试图在Java程序或应用程序中使用MySQL Connector/J时，遇到类似下面的异常：
SQLException: 无法连接到host:3306上的MySQL服务器。
在你尝试连接的机器／端口上是否有正在运行的MySQL服务器？
(java.security.AccessControlException)
SQLState: 08S01
VendorError: 0
回答：
或许是因为你正在运行Applet，你的MySQL服务器是采用“--skip-networking”选项集安装的；或许是因为MySQL服务器位于防火墙之后。
Applet仅能使网络连接返回运行Web服务器的机器，该Web服务器提供了用于Applet的.class文件。这意味着，要想使其工作，MySQL必须运行在相同的机器上（或必须使某类端口重定向）。这还意味着，你无法通过你的本地文件系统来测试Java程序，你必须将它们放在Web服务器上。
MySQL Connector/J仅能使用TCP/IP与MySQL进行通信，这是因为Java不支持Unix域套接字。如果MySQL是用“--skip-networking”标志启动的，或采用了防火墙，TCP/IP与MySQL的通信可能会受到影响。
如果MySQL是用“--skip-networking”选项集启动的（例如MySQL服务器的Debian Linux包即用于该目的），需要在文件/etc/mysql/my.cnf或/etc/my.cnf中将其注释掉。当然，my.cnf文件也可能位于MySQl服务器的“data”目录下或其他地方（取决于系统中MySQL的编译方式）。MySQL AB创建的二进制文件总会在查找/etc/my.cnf和[datadir]/my.cnf。如果为MySQL服务器部署了防火墙，需要对防火墙进行配置，允许从运行Java代码的主机在MySQL监听的端口上（默认为3306）建立与 MySQL服务器的TCP/IP连接。
27.3.5.1.4:
问题：
I我的小服务程序／应用程序白天工作良好，但在晚上却停止工作。
回答：
不工作时间超过8小时后，MySQL关闭了连接。你或许需要使用能处理失效连接的连接池，或使用“autoReconnect”参数（请参见用MySQL Connector/J开发应用程序）。
此外，你应在应用程序中俘获 SQLException并处理它们，而不是在应用程序退出前一直传播它们，这是1个好的编程习惯。在查询处理过程中遇到网络连通性方面的问题时，MySQL Connector/J会将SQLState（参见APIDOCS中的java.sql.SQLException.getSQLState()）设置为“08S01”。随后，应用程序代码将尝试再次连接到MySQL。
在下面的示例（simplistic）中，给出了能够处理这类异常的代码：
示例26.13. 重试逻辑的事务示例
public void doBusinessOp() throws SQLException {Connection conn = null;Statement stmt = null;ResultSet rs = null;//// How many times do you want to retry the transaction// (or at least _getting_ a connection)?//int retryCount = 5;boolean transactionCompleted = false;do { try {conn = getConnection(); // assume getting this from a// javax.sql.DataSource, or the// java.sql.DriverManagerconn.setAutoCommit(false);//// Okay, at this point, the 'retry-ability' of the// transaction really depends on your application logic,// whether or not you're using autocommit (in this case// not), and whether you're using transacational storage// engines//// For this example, we'll assume that it's _not_ safe// to retry the entire transaction, so we set retry count// to 0 at this point//// If you were using exclusively transaction-safe tables,// or your application could recover from a connection going// bad in the middle of an operation, then you would not// touch 'retryCount' here, and just let the loop repeat// until retryCount == 0.//retryCount = 0;stmt = conn.createStatement();String query = "SELECT foo FROM bar ORDER BY baz";rs = stmt.executeQuery(query);while (rs.next()) {}rs.close();rs = null;stmt.close();stmt = null;conn.commit();conn.close();conn = null;transactionCompleted = true; } catch (SQLException sqlEx) {//// The two SQL states that are 'retry-able' are 08S01// for a communications error, and 41000 for deadlock.//// Only retry if the error was due to a stale connection,// communications problem or deadlock//String sqlState = sqlEx.getSQLState();if ("08S01".equals(sqlState) || "41000".equals(sqlState)) { retryCount--;} else { retryCount = 0;} } finally {if (rs != null) { try {rs.close(); } catch (SQLException sqlEx) {// You'd probably want to log this . . . }}if (stmt != null) { try {stmt.close(); } catch (SQLException sqlEx) {// You'd probably want to log this as well . . . }}if (conn != null) { try {//// If we got here, and conn is not null, the// transaction should be rolled back, as not// all work has been donetry { conn.rollback();} finally { conn.close();} } catch (SQLException sqlEx) {//// If we got an exception here, something// pretty serious is going on, so we better// pass it up the stack, rather than just// logging it. . .throw sqlEx; }} }} while (!transactionCompleted && (retryCount > 0)); }27.3.5.1.5:
问题：
我正尝试使用JDBC-2.0可更新结果集，但遇到异常，说我的结果集不可更新。
回答：
由于MySQL没有行ID，MySQL Connector/J仅能更新来自查询且位于有至少一个主键的表上的结果集，查询必须选择所有的主键，而且查询即能作用在1个表上（即不存在联合）。在JDBC规范中给出了这方面的介绍。
26.3.5.2. 如何通报缺陷和问题
通报缺陷的正常地址是http://bugs.mysql.com/，它也是我方缺陷数据库的地址。这是1个公共数据库，任何人都能浏览它并进行相应的搜索。如果你已登录到系统，也应能输入新的报告。如果发现MySQL中存在敏感的安全缺陷，请发送电子邮件至security@mysql.com。
编写良好的缺陷报告需要耐心，但在第1时间正确地完成它不仅能节省我们的时间，也能节省你自己的时间。良好的缺陷报告应包含对缺陷的完整测试情况，以便我们你能够在下个版本中更正该缺陷。
本节介绍的内容用于帮助你正确地编写报告，从避免将你的时间浪费在对我们帮助不大或没有帮助的事上，
如果有1份可重复的缺陷报告，请将其提交到缺陷数据库，http://bugs.mysql.com/。
对于任何我们能再现的缺陷，在下一个MySQL版本中修正它的机会很大。
要想通报其他问题，请使用MySQL邮件列表。
请注意，我们可能会对包含过多信息的消息作出响应，但不太会对包含过少信息的消息作出回应。人们常会省略掉一些事实，因为他们认为自己知道了故障的原因，并想当然地认为这类细节无关紧要。
良好的原则是：如果你对陈述某事犹豫不定，请陈述之。如果我们要求你提供初始报告中缺少的信息，在报告中编写多行信息源比等候回复要快，麻烦也更小。
在缺陷报告，最常犯的错误包括：（a）未包含所使用Connector/J或MySQL的版本号，以及（b）未完全描述安装了Connector/J的平台（包括JVM版本，平台类型，以及所安装MySQL本身的版本号）。
这是高度相关的信息，如果没有它，99％的缺陷报告无用。我们遇到这类问题，“为何它对我没用”？ 随后，我们发现在该MySQL版本中，所请求的特性尚未实施，或在较新的MySQL版本中已更正了报告中描述的缺陷。
有些时候，错误与平台相关，在这类情况下，如果不知道操作系统和平台的版本号，我们几乎不可能更正任何问题。
如果可能，你应创建1份可重复的、不含任何第三方类的独立测试案例。
为了是该进程流线化，我们与Connector/J一起提供了用于测试的基本类，名为com.mysql.jdbc.util.BaseBugReport。要想使用该类为Connector/J创建1个测试案例，你应应创建自己的从com.mysql.jdbc.util.BaseBugReport继承的类，并覆盖方法setUp()、tearDown()和runTest()。
在setUp()方法中，创建用于创建表的代码，并用演示缺陷所需的数据填充表。
在runTest ()方法中，使用在“setUp”方法中创建的表和数据，创建用于演示缺陷的代码。
在tearDown()方法中，撤销在setUp()方法中创建的任何表。
对于上述三种方法中的任何一种，应使用getConnection ()各种变体中的一种创建与MySQL的JDBC连接。
·getConnection()：提供了与在getUrl()中指定的JDBC URL的连接。如果连接已存在，返回该连接，否则将创建新的连接。
·getNewConnection()：如果需要为缺陷报告获得新的连接（即包含1个以上的连接），应使用它。
·getConnection(String url)：使用给定的URL返回连接。
·getConnection(String url, Properties props)：使用给定的URL和属性返回连接。
如果需要使用不同于“jdbc:mysql:///test”的JDBC URL，还应覆盖方法getUrl()。
在演示你所预计行为的测试案例中（相对于你观察到的世纪行为，这是你填充错误报告的最可能原因），使用assertTrue(boolean expression)和assertTrue(String failureMessage, boolean expression)方法创建必须满足的条件。
最后，创建用于创建测试案例实例的main ()方法，并调用run方法：
public static void main(String[] args) throws Exception {new MyBugReport().run();
}
完成了测试案例并证实它能演示你所通报的缺陷后，请将该案例与缺陷报告一起上传到http://bugs.mysql.com/。
26.3.6. Changelog
# Changelog
# $Id: CHANGES,v 1.38.4.206 2005/05/12 15:25:54 mmatthews Exp $
05-17-05：版本3.2.1-alpha
- 现已不再重视Autoreconnect功能（即autoReconnect=true）。
如果尝试并使用它将抛出异常，使用“enableDeprecatedAutoreconnect=true”可继续使用autoReconnect。但是，在Connector/J 3.3中将删除该项特性，请参见手册中关于不需要使用autoReconnect的相应解决方案。
- 现在，驱动程序将检查是否设置了服务器变量“init_connect”，如果设置了该变量，将检查autocommit（自动提交）设置，并应用它。
- 如果连接的服务器版本在5.0.x以上，而且Statement.setFetchSize( > 0)，驱动程序将尝试使用服务器预处理语句，并使用结果集“cursors”获取语句。
- ServerPreparedStatements现在能正确地将BLOB/CLOB数据以“流方式”发送至服务器。你可以使用属性“blobSendChunkSize”配置程序块大小的阈值（默认值为1MB）。
- 支持sql模式NO_BACKSLASH_ESCAPES以及非服务器端预处理语句。
12-23-04：版本3.2.0-alpha
-更正了DatabaseMetaData.supportsCatalogIn*()错误的返回值。
-使用ServerPreparedStatements以及MySQL 5.0或更高版本时，支持基于“cursor”的结果集。结果集需为“仅正向”结果集，并需启用针对该项特性的非零获取大小。
- 重新分解了预处理语句的where逻辑，服务器端预处理语句保持有效。
10-07-05：版本3.1.11-stable
- 更正了BUG#11629：当字符编码是“utf8”时控制台上的伪“!”。
-更正了为丢失“;”（用于“plain”语句）的测试案例生成的语句。
- 更正了BUG#11663：为服务器端预处理语句生成的不正确的testcase脚本。
-更正了因修补BUG#11552而导致的回归，对于BUG#11552，当整数处于正号类型的范围内时，对于无符号整数，该缺陷将导致驱动程序返回错误值。
-将源代码移到了svn repo。
-更正了BUG#11797：转义标志不考虑用于转义用途的层套式单引号。
-使用服务器端预处理语句时，不识别GEOMETRY类型。
-更正了BUG#11879：ReplicationConnection不会切换至从连接，抛出“目录不能为空”异常。
-更正了BUG#12218，主连接和具有复制连接的从连接之间共享的属性。
- 更正了BUG#10630。如果语句已关闭，Statement.getWarnings()无法与NPE一起工作。
-需要时，在PreparedStatement.ParseInfo()中，即能从SQL获取char[]。
-更正了BUG#12104，服务器端预处理语句不能处理Geometry类型。
-更正了BUG#11614，使用多字节字符编码时，StringUtils.getBytes()不工作，在“_characters_”中指定了长度。
-更正了BUG#11798，Pstmt.setObject(...., Types.BOOLEAN)抛出异常。
-更正了BUG#11976，maxPerformance.properties拼错“elideSetAutoCommits”。
-更正了BUG#11575，对于在Window平台上的服务器，DBMD.storesLower/Mixed/UpperIdentifiers()通报不正确的值。
-更正了BUG#11190，在ResultSet.moveToCurrentRow()之前调用了ResultSet.moveToInsertRow()时，ResultSet.moveToCurrentRow()不起作用。
-更正了BUG#11115，使用服务器端预处理语句和.setBytes()时，VARBINARY数据发生崩溃。
-更正了BUG#12229，服务器端预处理语句挂起explainSlowQueries。
-更正了BUG#11498，转义处理器不考虑用双引号分隔的字符串。
-对于服务器端预处理语句，增加了对更改流参数的限制。只要在执行前设置了“_all_”流参数，可不必调用.clearParameters()。（由于客户端／服务器协议的限制，预处理语句不能复位服务器端的“_individual_ stream”数据）。
-修改了Field类，*Buffer和MysqlIO，能够识别大于Integer.MAX_VALUE的字段长度。
-更新了DBMD.supportsCorrelatedQueries()，当版本高于4.1时返回“真”，更新了supportsGroupByUnrelated()使之返回“真”，并更新了getResultSetHoldability()使之返回HOLD_CURSORS_OVER_COMMIT。
-更正了BUG#12541，DatabaseMetaData.getIndexInfo()中的catalog（目录）参量处理，它也意味着对DatabaseMetaData中下述方法的更改：
- getBestRowIdentifier()
- getColumns()
- getCrossReference()
- getExportedKeys()
- getImportedKeys()
- getIndexInfo()
- getPrimaryKeys()
- getProcedures() (and thus indirectly getProcedureColumns())
- getTables()
上述所有方法中的“catalog”参量现具有下述行为特征：
-如果指定为Null，表示不会使用catalog来过滤结果（因此将搜索所有数据库），除非在JDBC URL属性中设置了“nullCatalogMeansCurrent=true”。
-指定为“”表示当前catalog，尽管它不是十分兼容JDBC规范，但它是为传统用户保留的。
-指定catalog，使之按API文档中阐明的方式工作。
-使得jdbc2.optional软件包中的“封装”连接能够使用Connection.clientPrepare()（使用ConnectionPoolDataSource实例创建连接）。
-为客户端增加了Connection.isMasterConnection()，以确定多主机主／从连接是否连接至列表中的第1个主机。
-更正了BUG#12753，URL属性用于“=”的标志会导致“sessionVariables=....”无法正确地参数化。
-更正了BUG#11781，当DatabaseMetaData方法使用该信息时，所引用的外键信息不能被正确解析。
-考虑到流缓冲区大小和信息包报头，“sendBlobChunkSize”属性现在与“max_allowed_packet”密切结合在一起，当max_allowed_packet的大小类似于默认的“sendBlobChunkSize”时（为1MB），能避免PacketTooBigExceptions。
-CallableStatement.clearParameters()现能清除与INOUT/OUTPUT参数和INPUT参数相关的属性。
-更正了BUG#12417，Connection.prepareCall()是区分大小写的数据库名称（在Windows系统上）。
-更正了BUG#12752，对于版本高于4.0.x的服务器，Cp1251不正确地映射至win1251。
-更正了BUG#12970，使用DatabaseMetaData.getColumns()时，java.sql.Types.OTHER返回BINARY和VARBINARY列。
-引用参数约束列表前，ServerPreparedStatement.getBinding()现在将检查语句是否已关闭，以避免抛出NullPointerException。
-更正了BUG#13277，无论何时，当调用需要连接引用的方法时，来自Statement.getGeneratedKeys()的ResultSetMetaData将导致NullPointerExceptions的抛出。
-自5.0起，Field类ResultSetMetaData.getColumnClassName()和ResultSet.getObject(int)的反向移植出现了变化，更正了VARCHAR BINARY/VARBINARY和相关类型有关的行为。
-更正了NullPointerException，当参数为NULL时，在很多DatabaseMetaDataMethods中将“catalog”参数转换为byte[]时出现的异常（对于结果集）。（根据JDBC规范，从技术角度上不允许“null”，但从历史观点上，我们允许使用它）。
-从5.0起，VAR[BINARY|CHAR] [BINARY]类型检测的反向移植。
-即使无法打开本地文件，也能读取MysqlIO.sendFileToServer()中响应，否则，下一个发出的查询将失败，这是因为，它正在读取对发送至服务器的空LOAD DATA INFILE信息包的响应。
-避开了BUG#13374，已关闭结果集上的ResultSet.getStatement()返回NULL（按照JDBC 4.0规范，但不具有向后兼容性）。将连接属性“retainStatementAfterResultSetClose”设为“真”，以便能够在通过.getStatement()关闭了结果集后检索结果集的语句（默认为“假”以便与JDBC兼容，并降低使用JDBC的代码名泄漏语句实例的机会）。
-更正了BUG#13453，URL配置参数不允许在它们的值中使用“&”或“=”。现在JDBC驱动程序能够对配置参数进行相应地解析，就像它们是使用application/x-www-form-urlencoded格式（在java.net.URLDecoder中指定，http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLDecoder.html）进行编码那样。
如果在配置属性中出现字符“%”，现在必须用“%25”表示，它是使用“application/x-www-form-urlencoded”编码使“%”的已编码形式。
-配置属性“sessionVariables”现在允许你指定以“@”符号开始的变量。
-更正了BUG#13043，为低于4.1.0版的服务器允许了“gatherPerfMetrics”时，如果查询未使用任何表，结果集的构造函数将抛出NullPointerException。
06-23-05：版本3.1.10-stable
-更正了因无指定数据库而导致的MysqlIO.changeDatabaseTo()中的异常。
-首次实现了用于PreparedStatement.getParameterMetadata()的ParameterMetadata。仅能与CallableStatements一起完全发挥作用，这是因为当前的服务器端预处理语句会将所有参数返回为VARCHAR类型。
06-22-05：版本3.1.9-stable
-彻底检查了字符集配置，现在所有相关项均能位于属性文件中。
-如果在用于Windows-31J的服务器上可用，驱动程序能正确使用CP932，以及CP932和MS932 java编码名称，否则将求助于仅为近似的SJIS。目前，仅在MySQL-5.0.3和更高版本上（以及MySQL-4.1.12/13，取决于何时反向移植字符集），才能可靠地支持任何CP932变体。
-更正了BUG#9064，com.mysql.jdbc.PreparedStatement.ParseInfo对toCharArray()的不必要调用。
-更正了Bug#10144，如果serverPrepare()失败，ServerPreparedStatement中的内存泄漏。
-将清单文件实际写入正确位置，以便其终止于二进制jar文件。
-增加了“createDatabaseIfNotExist”属性（默认为“假”），该属性会使驱动程序请求服务器创建在URL中指定的数据库（如果该数据库不存在的话）。必须拥有恰当的数据库创建权限才能执行该任务。
-更正了BUG#10156，对于ResultSet.getInt()，无符号SMALLINT被当作带符号类型，更正了所有的UNSIGNED整数和服务器端预处理语句，以及用于UNSIGNED TINYINT的ResultSet.getObject()。
-更正了BUG#10155，解析客户端预处理语句时不能识别双引号。
-使得enableStreamingResults()在com.mysql.jdbc.jdbc2.optional.StatementWrapper上可见。
-使得ServerPreparedStatement.asSql()能正确工作，自动解释功能可以与服务器端预处理语句一起工作。
-使得兼容JDBC2的软件包成为公共包，以便允许访问厂家扩展。
-整理了剖析工具事件的记录功能，移动了代码以将剖析工具事件转储为com.mysql.jdbc.log.LogUtils的字符串，以便第三方能够使用它。
- DatabaseMetaData.supportsMultipleOpenResults()现在返回“真”。DBMD刚刚丢失某一内容时，驱动程序在一段时间内支持它。
-更正了BUG#10310，驱动程序不支持用来调用存储程序的{?=CALL(...)}。其中包括，为DatabaseMetaData.getProcedures()和getProcedureColumns()增加了函数检索支持。-更正了BUG#10485，用ResultSet.getString()检索YEAR(2)时抛出SQLException。现在，驱动程序总是将YEAR类型当作java.sql.Dates对待，并为getString()返回正确值。
另外，可以将“yearIsDateType”连接属性设置为“假”，并将值作为SHORT进行处理。
-当“tinyInt1isBit=true”时（默认），使用新的配置属性“transformedBitIsBoolean”（默认为“假”），对于TINYINT(1)列，返回的数据类型可在Types.BOOLEAN和Types.BIT之间切换。如果设为“假”（默认），对于TINYINT(1)列，DatabaseMetaData.getColumns()和ResultSetMetaData.getColumnType()将返回Types.BOOLEAN。如果为“真”，将返回Types.BOOLEAN。无论该配置属性是如何设置的，如果允许了“tinyInt1isBit”，具有TINYINT(1)类型的列将作为ResultSet.getObject(..)的java.lang.Boolean实例返回，而且ResultSetMetaData.getColumnClassName()将返回“java.lang.Boolean”。
-更正了BUG#10496，与cp932或eucjpms一起使用“characterSetResults”属性时将抛出SQLException。
-重组了目录格局，源码现位于“src”文件夹下，创建时不填充父目录，输出位于“./build”下，分发版位于“./dist”下。
-这类支持/缺陷跟踪特性，将“autoGenerateTestcaseScript”设置为“真”时，该特性能够为STDERR生成.sql测试脚本。
-更正了BUG#10850，使用服务器端预处理语句时，不会将“0长度”流发送给服务器。
-现在，如果设置了“cachePrepStmts=true”，也会使连接进行高速缓冲操作，检查驱动程序的执行情况，以判断预处理语句是否能够在服务器端工作，并能在连接的生命期内对服务器端预处理语句进行高速缓冲处理。与以往一样，参数“prepStmtCacheSize”负责控制这些高速缓冲区的大小。
-进行了尝试，以更为优美的方式处理OutOfMemoryErrors。尽管所能作的事情不是很多，但在大多数情况下它们能关闭所遇到的连接，这样，进一步的操作不会进入状态不明的连接。出现OOM时，连接上的任何进一步操作均将失败，同时抛出“连接已关闭”异常，还将列出作为隐式连接关闭事件原因的OOM异常。
-如果未要求，执行服务器端预处理语句时不发送COM_RESET_STMT。
-驱动程序将检测是否正在运行MySQL-5.0.7或更高版本，而且不扫描正在处理的语句中的“LIMIT ?[,?]”，这是因为目前服务器支持这类查询。
-更正了BUG#11115，使用服务器端预处理语句和ResultSet.getBytes()时，VARBINARY数据发生崩溃
-Connection.setCatalog()想在能够识别“useLocalSessionState”配置属性，将该属性设为“真”时，如果所请求的catalog与当前catalog相同，会阻止驱动程序将“USE ...”发送给服务器。
-增加了下述配置捆包，通过“useConfigs”配置属性使用1个或多个：
* maxPerformance：考虑后果时的最大性能
* solarisMaxPerformance：Solaris的需性能，在可能的情况下避免系统调用。
* 3-0-Compat：与Connector/J 3.0.x功能兼容。
-增加了“"maintainTimeStats”配置属性（默认为“真”），用于通知驱动程序是否应跟踪上次查询时间，以及上次成功将信息包发送到服务器的时间。如果将其设置为“假”，将删除每查询的两次系统调用。
-更正了BUG#11259，autoReconnect的ping操作会导致连接启动时的异常。
-更正了BUG#11360，Connector/J将查询两次转储到SQLException。
-更正了PreparedStatement.setClob()，不接受Null作为参数。
-更正了BUG#11411，生产包不包括JBoss集成类。
-删除了使用“usage advisor”时无意义的“开销昂贵的类型转换”告警。
04-14-05：版本3.1.8-stable
-更正了DatabaseMetaData.getTables()，未要求时，以请求表的类型之一返回视图。
-在5.0.3和更高版本的MySQL中，增加了对新精度数学DECIMAL类型的支持。
-更正了ResultSet.getTime()，作用于服务器端预处理语句的Null值上时抛出NPE。 -使Connection.ping()成为public方法。 -更正了Bug#8868，DATE_FORMAT()查询从getObject()返回BLOB。 - ServerPreparedStatements现在能正确地将BLOB/CLOB数据以“流方式”发送至服务器。你可以使用属性“blobSendChunkSize”配置程序块大小的阈值（默认值为1MB）。
-生成预处理语句时，BlobFromLocator现在能使用正确的ID引用。
-使用连接属性“sessionVariables”的逗号分隔列表方式传递它们，能够在连接时预先设置服务器端会话变量。
-为使用“autoReconnect=true”的用户更正了ping()中的回归问题。
-更正了BUG#9040，PreparedStatement.addBatch()不能与服务器端预处理语句和流式BINARY数据一起工作。
-更正了BUG#8800，对于运行于区分大小写的文件系统上的服务器，DBMD.supportsMixedCase*Identifiers()返回错误值。
-更正了BUG#9206，对于characterSetResults配置属性，不能使用“UTF-8”。
-更正了BUG#9236，连续BUG#8868，在查询中使用了多个函数，查询本应返回非字符串类型，但当临时表解析它们时，返回类型突然变为难以理解的二进制字符串（针对服务器限制采取了相应的避规措施）。此外，还更正了类型为CHAR(n) CHARACTER SET BINARY的字段，使其能够为RSMD.getColumnClassName()和ResultSet.getObject()返回正确／匹配的类。
-更正了BUG#8792，对于“仅正向/只读”结果集（我们支持该方式），DBMD.supportsResultSetConcurrency()未返回“真”。
-更正了BUG#8803，访问时，DBMD.getBestRowIdentifier()的“DATA_TYPE”列导致ArrayIndexOutOfBoundsException（事实上，未返回任何值）。
-检查了将char/varchar列数据转换为数值时的空字符串('')，如果配置属性“emptyStringsConvertToZero”被设为“假”，抛出异常（为了与3.0版的向后兼容，默认情况下，将其设为“真”，但在3.2版中，最可能的默认设置为“假”）。-更正了BUG#9320，在特定条件下，当未使用服务器端预处理语句时，PreparedStatement.getMetaData()在数据库中插入了空白行。
-Connection.canHandleAsPreparedStatement()现在将尽“最大努力”来识别带有占位符的LIMIT子句，目的在于，对于服务器目前不能将其当作服务器端预处理语句予以处理的语句，为其生成处理措施时，获得较少的错误肯定结果。
-更正了build.xml，如果log4j不可用，不编译log4j日志功能。
-增加了对c3p0连接池的（http://c3p0.sf.net/）验证/连接检验器接口的支持，如果服务器可用，该检验器接口将使用轻型“COM_PING”调用。要想使用它，请配置c3p0连接持的“connectionTesterClassName”属性，以使用“com.mysql.jdbc.integration.c3p0.MysqlConnectionTester”。
-更好的检测引用字符串的内外LIMIT，以便驱动程序能更加正确地判断是否可以在服务器上处理预处理语句。
-更正了BUG#9319，当驱动程序试图确定参数计数/类型时，分不清不同数据库中具有相同名称的存储程序。
-为ResultSet和Statement实施增加了最终确定器，以便与JDBC规范兼容，该规范要求，如果它们未明确关闭，在无用单元收集阶段应关闭这些资源。
-更正了BUG#9682，对于具有DECIMAL参数和存储要求的存储程序，如果包含“,”，将失败。
- PreparedStatement.setObject(int, Object, int type, int scale)现在能使用针对BigDecimal实例的标度值。
-更正了BUG#9704，当已有结果集是.close()d时，Statement.getMoreResults()可能抛出NPE。
-性能度量特性现能收集关于SELECT中引用的表数量的信息。
-现在能够自动配置日志系统。如果用户通过URL属性“logger”或系统属性“com.mysql.jdbc.logger”设置了值，那么将使用用户的设置，否则将采用下述步骤自动检测设置：
如果Log4j可用，将使用它，接下来是JDK1.4日志功能，再接下来是STDERR日志功能。
-更正了BUG#9778，即使数据库版本不支持视图，如果请求了视图，DBMD.getTables()不应返回表。
-更正了驱动程序，当在服务器端预处理语句返回的结果集上调用了ResultSet.getBoolean()时，对于“-1”不返回“真”。
-为.jar文件增加了Manifest.MF文件以及实施信息。
-在Field.isOpaqueBinary()中提供了更多测试，以识别晦涩的二进制字段（即具有CHAR(n)和CHARACTER SET BINARY类型的字段），这类字段来自各种标量函数和聚合函数（返回字符串）的输出。
-更正了BUG#9917，出于传统方面的考虑，即使它与JDBC不兼容，也应接受DBMD方法中用于catalog（使用当前值）的Null。将连接属性“nullCatalogMeansCurrent”设置为“假”可禁止它（在C/J 3.2.x中，它是默认设置）。
-更正了BUG#9769，出于传统方面的考虑，即使它与JDBC不兼容，也应接受DBMD中用于名称（“%”）的Null。将连接属性“nullNamePatternMatchesAll”设置为“假”可禁止它（在C/J 3.2.x中，它是默认设置）。
02-18-05：版本3.1.7-stable
-更正了BUG#7686，Timestamp关键字列数据需要分离的“_binary”，用于UpdatableResultSet.refreshRow()。
-更正了BUG#7715，对于服务器端预处理语句和可更新结果集，Timestamps错误地转换为字符串。
-检测字符串表单（以前为整数）中的sql_mode变量，并恰当调整字符串的引用方法。
-增加了“holdResultsOpenOverStatementClose”属性（默认为“假”），它能将statement.close()的结果集保持打开状态，或执行相同语句（由Kevin Burton推荐）。
-更正了BUG#7952，在故障切换配置下回退至主连接时的无限递归。
-如果允许了高速缓冲，将禁止4.1.10版之前MySQL-4.1版本的多语句功能（如果以允许的话），这是因为在该配置下，服务器会返回错误的结果。
-更正了configureClientCharset()中的重复代码，该类代码将阻止useOldUTF8Behavior=true的恰当运行。
-删除了“dontUnpackBinaryResults”功能，现在，驱动程序将按原样保存来自服务器端预处理语句的结果（与服务器提供的相同，并在需要时展开）。
-更正了BUG#8096，使用服务器端预处理语句时，模拟定位器破坏了二进制数据。
-更正了ServerPreparedStatement.serverPrepare()的同步事宜，如果在多个线程间共享连接，可能会导致死锁/崩溃。
-默认情况下，驱动程序能通过各种Connection.prepareStatement()的各种变体扫描SQL，以判断它是否是能够在服务器端支持的语句类型，如果不被服务器端支持，会将其作为客户端模拟预处理语句进行处理（BUG#4718)）。也可以通过在JDBC URL中传递“emulateUnsupportedPstmts=false”禁止该特性。
-从CallableStatement中删除了用作输入／输出参数的“_binary”引介词。
-对于注册为*BINARY的输出参数，总返回byte[]。
-对于PreparedStatement.setObject(n, "true", Types.BIT)，将布尔“True”的正确值发送给服务器。
-更正了与连接有关的缺陷，当语句不是服务器端预处理语句时，无法对来自prepareStatement()的语句进行高速缓冲处理。
-使用ResultSet.get(..., cal)和PreparedStatement.set(...., cal)时，如果客户端和服务器均位于GMT（格林威治标准时间）时区，选择进行时间调整的正确方向。
-增加了“dontTrackOpenResources”选项（默认为“假”以便兼容JDBC），对于具有不良特性的应用程序（例如应关闭语句时，却未关闭语句的应用程序），它有助于改善内存的使用。
-更正了BUG#8428，ResultSet.getString()不能保持存储在服务器上的格式，仅当将“noDatetimeStringSync”属性设置为“真”（默认为“假”）时，才能允许缺陷更正。
-更正了使用“usage advisor”而且结果集已关闭时ResultSet.realClose()中的NPE。
-更正了BUG#8487，不创建流式结果集的PreparedStatements。
-不将NULL传给给ResultSet.getNativeConvertToString()中的String.valueOf()，原因在于String.valueOf()会对其进行字符串处理（即返回“null”）,对于所述方法，这是错误的。
-更正了BUG#8484，当需要舍入操作以设定标度时，ResultSet.getBigDecimal()抛出异常。如果非舍入性BigDecimal.setScale()失败，驱动程序现在将选择“半向上”舍入模式。
-增加了“useLocalSessionState”配置属性，将其设置为“真”时，JDBC驱动程序将认为应用程序行为良好，并会使用java.sql.Connection提供的方法仅设置autocommit和事务隔离级别，因此，能够在大多数情况下处理这些值，而不引发数据库服务器循环。
-为连接池实施实例的语句增加了enableStreamingResults()，可检查Statement.setFetchSize()是否存在兼容规范的值。调用“Statement.setFetchSize(>=0)”可禁止关于该语句的流式结果。
-增加了对MySQL-5.0.3中BIT类型的支持。驱动程序会将BIT(1-8)当作JDBC的BIT类型对待（映射至java.lang.Boolean），这是因为当声明了“< 9 bits”)时，服务器目前不会发送能确定比特字段（bitfield）大小的足够信息。BIT(>9)将被当作VARBINARY对待，并当调用getObject()时返回byte[]。
12-23-04：版本3.1.6-stable
-更正了SocketInputStream.read()的挂起问题，当驱动程序必须直接截取结果集，而不是跟踪结果集末尾的“LIMIT n”时，与Statement.setMaxRows()和多个结果集一起使用时SocketInputStream.read()挂起。
-更正了BUG#7026，DBMD.getProcedures()不考虑catalog参数。
12-02-04：版本3.1.5-gamma
-更正了字符串常数和动态字符串之间的比较事宜，或是toUpperCase()d或是toLowerCase()d，以使用Locale.ENGLISH，将其用作英语的覆盖规则。此外，还使用StringUtils.indexOfIgnoreCase()替代了.toUpperCase().indexOf()，以避免创建很短的过渡性字符串实例。
-更正了BUG#5235，服务器端预处理语句不考虑“zeroDateTimeBehavior”属性，而且当使用ResultSet.getObject()时会导致类抛弃异常，这是因为总返回全0字符串。
-更正了批更新和服务器预处理语句有关的问题，与以前的集合相比，如果在给定的批参数集合中发生了类型变更，服务器预处理语句不会检测这类变化，从而导致服务器返回错误“Wrong arguments to mysql_stmt_execute()”。
-解决了当时间戳的字符串表示包含后缀“.”但其后没有数字时的情况。
-更正了BUG#5706，对ResultSet.getNativeString()中以前存在字符串实例的低效检测。
-不抛出针对Connection.releaseSavepoint()的异常。
-解码来自ServerPreparedStatements的日期时，默认情况下使用按会话进行的日历实例（通过设置“dynamicCalendars=true”，设置为早期的性能较低的方式）。
-增加了实验性配置属性“dontUnpackBinaryResults”，它延迟了解包二进制结果集取值的功能，直至请求了它们为止（默认情况下设为“假”）。对于某些usecase/jvm组合，它对无用信息收集器更友好。
-更正了BUG#5729，对来自服务器端预处理语句结果集的UNSIGNED BIGINT，未能正确解包。
-更正了BUG#6225，ServerSidePreparedStatement，分配了不必要的具有短生存时间的对象。
-删除了ResultSet构造函数中有害的新Throwable()，原因在于不良合并（导致任何所创建结果集永远不会使用的新对象），分析BUG#6359时发现。
-更正了在EscapeProcessor.escapeSQL()中过早创建StringBuffer的问题，而且在不需要转义功能时仍返回字符串（防止不必要的对象分配）。分析BUG#6359时发现。
-为可更新结果集中的键比较使用“null-safe-equals”。
-更正了BUG#6537，如果需要0填充，作用在Decimal上的SUM()以及服务器端预处理语句均将忽略标度（由于服务器将其转换为DOUBLE，0填充将结束，将其转换为BigDecimal类型的字符串进行解析时，丢失所有的填充“0”）。
-创建DBMD查询时使用DatabaseMetaData.getIdentifierQuoteString()。
-如果在服务器上LOAD DATA LOCAL INFILE小于“max_allowed_packet”，使用1MB的信息包发送文件。
-更正了BUG#6399，对于多字节字符集，ResultSetMetaData.getColumnDisplaySize()返回错误值。
-通过“autoDeserialize”属性（默认为“假”），能够对保存在BLOB中的java.lang.Objects的自动串并转换功能进行配置。
-修改了Field.isOpaqueBinary()以检测“CHAR(n) CHARACTER SET BINARY”，从而能够支持用于ResultSet.getObject()的固定长度二进制字段。
-使用我们自己的缓冲输入流实施方式来处理java.io.BufferedInputStream的封闭行为。使用“useReadAheadInput=false”可禁止它。
-更正了BUG#6348，当给定主机名的某一地址是IPV6时无法连接到服务器（服务器尚未与IPV6捆绑） 驱动程序现在能够查找给定主机的所有IP地址，并停在接受socket.connect()的第1个地址上。
09-04-04：版本3.1.4-beta
-更正了BUG#4510，Connector/j 3.1.3 beta不能正确处理整数（由为了支持Buffer.readInt() -> Buffer.readShort()中的无符号读取操作所作的更改而导致）。
-在DatabaseMetaData.getTables()和getTableTypes()中增加了对VIEW的支持，该类特性现已在MySQL服务器5.0.x版中提供。
-更正了BUG#4642，解包字段元数据时，ServerPreparedStatement.execute*()有时会抛出ArrayIndexOutOfBoundsException。
-优化了整数解析功能，通过“useFastIntParsing=false”属性，允许使用JDK类较慢的解析功能。
-增加了“useOnlyServerErrorMessages”属性，它会使服务器生成的异常中的消息文本仅包含由服务器发送的文本（与SQLState“标准”介绍中给出的相反，此时文本后面还包括服务器的错误消息）。默认情况下，该属性被设置为“真”。
-更正了BUG#4689，如果前面的Null已被返回，对于原语，ResultSet.wasNull()不工作。
-如果“enablePacketDebug=true”，跟踪信息包的序列号，如果收到的信息包次序混乱，抛出异常。
-更正了BUG#4482，使用预处理语句时，对于字符串，ResultSet.getObject()返回错误类型。
-两次调用MysqlPooledConnection.close()（虽然也是应用程序错误）会导致NPE。已更正。
-更正了BUG#5012，处理DECIMAL类型的返回值的ServerPreparedStatements不工作。
-更正了BUG#5032，对于来自4.1.x版预处理语句的伪位类型，ResultSet.getObject()不返回布尔类型（在针对伪位类型的getObject()中使用二进制编码的结果集模糊测试时，它提供了避免额外类型转换的快捷方式）。
-现在能够在“LOAD DATA LOCAL INFILE”语句中使用URL，而且驱动程序将使用Java的内置处理程序来检索数据，并将其发送到服务器。默认情况下不允许该特性，要想使用它，必须将“allowUrlInLocalInfile”连接属性设置为“真”。
-对于在ResultSet.get*()的数值上执行的截取操作，驱动程序将更加严格，而且当检测到截取操作时将抛出SQLException。将“jdbcCompliantTruncation”设置为“假”，可以禁止该功能（在默认情况下允许该功能，这是因为该功能是兼容JDBC所需的）。
-从结果集读取“全零”日期时间值时，增加了三种处理它们的方法，“exception”，（默认值），用代码为“S1009”的SQLState抛出SQLException；“convertToNull”，返回NULL而不是数据；以及“round”，对日期进行舍入处理，使之成为最接近的值，即“0001-01-01”。
-更正了ServerPreparedStatement，使之能够“以脱线”方式读取预处理语句元数据，尽管在目前它是取代在任何时侯均不工作的MysqlIO.clearInputStream()的占位符，之所以如此，是因为目前尚未从服务器读取数据。通过抛出ArrayIndexOutOfBoundExceptions的erverPreparedStatements，它修正了用户遇到的偶发性错误。
-加载资源捆包时使用com.mysql.jdbc.Message的类加载器，应能更正调用器的类加载器不能确定资源捆包位置时出现的偶发性错误。
07-07-04：版本3.1.3-beta
-对CallableStatements的输出参数名进行Mangle处理，使得在与用户变量名一起使用时，这类名称不会崩溃。
-增加了对CallableStatements中INPUT参数的支持。
-更正了BUG#4119，为服务器端预处理语句发送的null比特掩码不正确。
-默认情况下使用SQL的标准SQL状态，除非将“useSqlStateCodes”属性设置为“假”。
-增加了信息包调试代码（请参见“enablePacketDebug”属性文档）。
-为MySQL错误编号增加了常量（可公共访问，请参见com.mysql.jdbc.MysqlErrorNumbers），并增加了生成映射的能力，能够将厂家代码映射为驱动程序使用的SQLStates（出于文档编制目的）。
-使更多消息更为具体（正在努力）。
-更正了BUG#4311，在检索具有预处理语句和二进制协议特性的mediumint列时发生错误。
-当“useTimezone=true”时，在MySQL-4.1.3中支持新的时区变量。
-支持无符号数值作为预处理语句返回的类型。对于“bigint unsigned”类型，这也会导致ResultSet.getObject()中的内容发生变化，“bigint unsigned”类型用于返回BigDecimal实例，现在它将返回java.lang.BigInteger实例。
06-09-04：版本3.1.2-alpha
更正了为参数（如char(), varchar()）指定大小时存储程序参数的解析信息。
-通过“cacheCallableStmts”属性，允许对可调用语句进行高速缓冲处理。
-更正了下述问题：未为存储程序指定输出参数时，发出虚假查询来检索输出参数，从而导致服务器语法错误。
-更正了在CallableStatement.setOutputParameters()中没有任何参数会导致NullPointerException的问题。
-删除了MysqlIO.changeUser()中的异常捆包。
-更正了关于发送大型查询分离信息包方面的问题，也允许发送大信息包的nio功能。
-为ServerPreparedStatement增加了.toString()功能，如果你正在调试作为预处理语句（显示为服务器应处理的SQL）的查询，它应有所帮助。
-增加了“gatherPerformanceMetrics”属性，以及用于控制在何时/何处记录这类信息的多种属性（更多信息请参见相关文档）。
-调用.close()时，ServerPreparedStatements实际上不能取消对服务器端资源的分配。
-增加了“logSlowQueries”属性，以及“slowQueriesThresholdMillis”属性，以控制应在何时将查询视为“缓慢”。
-相对于registerOutParameter()中隐含的顺序，正确地将输出参数映射到prepareCall()中给定的位置，；更正了BUG#3146。
-对于版本等于高于4.1.0的服务器，能正确地检测字符集。
-整理了服务器属性的检测功能。
-对于版本等于高于4.1.2的服务器，支持用于参数元数据的占位符。
-更正了BUG#3539，getProcedures()未返回结果集中的任何进程。
-更正了BUG#3540，getProcedureColumns()不能与程序名的通配符一起使用。
-更正了BUG#3520，DBMD.getSQLStateType()返回不正确的值。
-增加了“connectionCollation”属性，如果给定字符集的默认校对不恰当，驱动程序将在连接初始过程中发出“set collation_connection=...”查询。
-更正了在MySQL-5.0.0上运行时的DatabaseMetaData.getProcedures()问题（在5.0.1和5.0.0间，“show procedure status”的输出有所不同）。
-更正了BUG#3804，getWarnings()返回SQLWarning而不是DataTruncation。
-对于版本为5.0.0或5.0.1的服务器，不要启用服务器端预处理语句，这是因为，它们与驱动程序使用的“4.1.2+”风格不兼容（驱动程序预计返回的信息并不存在，因而挂起）。
02-14-04：版本3.1.1-alpha
-更正了与不使用客户端预处理语句的UpdatableResultSets有关的缺陷。
-当MySQL不提供字符集并将JVM设置为多字节编码时，更正了将字节转换为ASCII时的字符编码事宜（通常会影响数值检索）。
-将服务器预处理语句的“未知”数据类型解包为字符串。
-为服务器预处理语句实现了长数据类型（Blob、Clob、InputStreams、Readers）。
-为MySQL-4.1和更高版本实现了Statement.getWarnings()（使用“SHOW WARNINGS”）。
-默认结果集类型更改为TYPE_FORWARD_ONLY（兼容JDBC）。
- 结果集类型和并发性的集中设置。
-再次确定了连接属性的设置方式和显示为DriverPropertyInfo的方式，以及Connection和DataSource属性。
-支持NIO。在支持NIO的平台上使用“useNIO=true”。
-支持SAVEPOINTs（MySQL >= 4.0.14或4.1.1）。
-支持“mysql_change_user()...”，请参见“com.mysql.jdbc.Connection”中的changeUser()方法。
-减少了平均查询中调用的方法数目，使之更有效率。
-自动再连接时重新处理预处理语句。任何遇到的错误均被延迟，直至首次尝试再执行经过重新处理的语句为止。
-按照JDBC规范，确保在预处理语句上执行查询前给出的警告是明确的（目前，我们支持警告功能）。
-在ConnectionProperties中，支持“旧的”profileSql大写特性。该属性已受到冷落，应尽量使用“profileSQL”。
-优化了Buffer.readLenByteArray()，以便当长度为0时返回共享的空字节数组。
-在对.execute*()的多次调用之间，允许保留PreparedStatement.setBlob()的内容。
-处理了EscapeProcessor中的0长度令牌（由可调用语句转义语法导致）。
-在UpdatableResultSet中的删除／更新／插入行操作上，检查关闭的连接。
-更正了检查UpdatableResultSet中的所有主键时对表别名的支持事宜。
-删除了useFastDates连接属性。
-对来自JNDI Refs的数据源属性进行了正确的初始化，包括明确指定的URL。
-对于版本为5.0.0或更高的MySQL，DatabaseMetaData现在能通报supportsStoredProcedures()。
-更正了Connection.prepareCall()中的堆栈溢出问题（不良合并）。
-对低于1.4版的JDK，更正了对DateTimeValue中Calendar.getTimeInMillis()的IllegalAccessError（非法访问错误）。
-更正了BUG#1673，对于非“%”列名，DatabaseMetaData.getColumns()未返回正确的列顺序信息。
-合并了数据类型映射的更正事项，从MySQL类型“FLOAT”到java.sql.Types.REAL（自3.0版起）的数据类型映射。
-检测用于RSMD.isCaseSensitive()的列校对。
-更正了与发送大于16M查询有关的问题。
-为CallableStatement增加了命名和索引式输入／输出参数支持。
MySQL-5.0.x或更高版本。
-更正了ServerPreparedStatement.setTimestamp()中的NullPointerException，以及ServerPreparedStatement.setTimestamp()、setDate()中的年月差异。
-为build.xml中的一致性和递归/单元测试增加了拥有多个数据库/JVM目标的能力。
-更正了访问ServerPreparedStatements和其结果集中某些日期时间功能时的NPE和不良年月转换问题。
-显示关闭连接的位置和原因（用于帮助调试）。
-实现了CommunicationsException，它能尝试判断与服务器失去通信的原因，并能在调用.getMessage()时显示可能的原因。
-更正了BUG#2359，二进制编码结果集中数值类型的NULL值会导致NullPointerExceptions。
-实现了Connection.prepareCall()，DatabaseMetaData.getProcedures()，以及getProcedureColumns()。
-调用clearParameters()时，通过发送COM_RESET_STMT至服务器，复位了ServerPreparedStatement中的“long binary”参数。
-自3.0版起，合并了预处理语句高速缓冲和.getMetaData()支持。
-解包来自服务器端预处理语句的结果时，在某些情况下，对于TimeUtil.fastDate/TimeCreate()的年份，会出现off-by-1900错误，更正了该错误。
-更正了BUG#2502，getTables()中的字符集转换事宜。
-实现了由语句或存储程序返回的多个结果集。
-更正了BUG#2606，服务器端预处理语句未正确返回数据类型“YEAR”。
-允许对来自服务器端预处理语句的结果集进行流处理。
-更正了BUG#2623，使用滚动结果集和服务器端预处理语句时出现类舍弃异常。
-自3.0版起，合并了无缓冲输入代码。
-更正了不能通过存取器恰当显示的ConnectionProperties，并整理了ConnectionProperties代码。
-更正了BUG#2671，在服务器端预处理语句中，在任何情况下均不能正确编码NULL字段。
-更正了将数字写入缓冲以发送预处理语句执行请求时出现的罕见缓冲区下溢问题。
-对于交付的驱动程序，使用了文档的DocBook版。
02-18-03：版本3.1.0-alpha
-增加了“requireSSL”属性。
-增加了“useServerPrepStmts”属性（默认为“假”）。当服务器版本支持并将该属性设置为“真”时（4.1和更高版本），驱动程序将使用服务器端预处理语句。目前其默认设置为“假”，除非所有的捆绑／获取功能均已实施。目前，仅为4.1版的服务器端预处理语句实现了DML预处理语句。
-跟踪打开的语句，并在调用Connection.close()时关闭所有打开的语句（JDBC兼容）。
06-23-05：版本3.0.17-ga
-更正了BUG#5874，当useTimeZone='true'而且服务器时区不同于客户端时区时，Timestamp/Time转换出现方向错误。
-更正了BUG#7081，DatabaseMetaData.getIndexInfo()忽略“唯一”参数。
-支持新的协议类型“MYSQL_TYPE_VARCHAR”。
-增加了“useOldUTF8Behavoior”配置属性，连接到MySQL-4.1或更高版本且字符编码为“utf-8”时，该属性能使JDBC驱动程序的行为方式类似于在MySQL-4.0.x和更早版本下的行为方式。
-更正了BUG#7316，调用getConnection()时，从连接池创建的语句返回实际连接而不是逻辑连接。
-更正了BUG#7033，在静态SQL字符串中，PreparedStatements不能正确编码Big5（以及其他多字节）字符集。
-更正了BUG#6966，启动了故障切换的连接（由于主连接失败）从不再次尝试主连接。
-更正了BUG#7061，PreparedStatement.fixDecimalExponent()增加额外“+”，使得MySQL服务器无法解析数值。
-更正了BUG#7686，Timestamp关键字列数据需要分离的“_binary”，用于UpdatableResultSet.refreshRow()。
-反向移植了来自Connector/J 3.1的SQLState代码映射，使用连接属性“useSqlStateCodes=true”可启用它，在本版本中默认为“假”，以免破坏传统应用程序（对于Connector/J 3.1，默认为“真”）。
-更正了BUG#7061，PreparedStatement.fixDecimalExponent()增加额外“+”，使得MySQL服务器无法解析数值。
-转义序列{fn convert(..., type)}现在支持由SQL预先设定的ODBC类型。-更正了configureClientCharset()中的重复代码，该类代码将阻止useOldUTF8Behavior=true的恰当运行。
-通过更正行数计数器的环绕式处理程序，能正确处理大于20亿行的流式结果集。
-更正了BUG#7607，MS932、SHIFT_JIS和Windows_31J不接受针对sjis的别名。
-更正了BUG#6549（更正#7607的同时），为sjis增加了CP943别名。
-更正了BUG#8064，与预处理语句一起使用多字节字符集时，要求对二进制数据进行十六进制转义处理。
-更正了BUG#8812，DBMD.getIndexInfo()的NON_UNIQUE列返回倒置值。
-解决了服务器BUG#9098，无法将DATE/TIME/TIMESTAMP/TIMESTAMP列CURRENT_*的默认值与“字符串”值区别开，因此，插入默认值时，UpdatableResultSet.moveToInsertRow()会生成不良的SQL。
-更正了BUG#8629，将“EUCKR”作为“SET NAMES euc_kr”发送，MySQL-4.1以及更高版本不能理解该特性。
-根据服务器的版本，DatabaseMetaData.supportsSelectForUpdate()返回正确值。
-对于含别名Windows-31J、CP934、MS932的双字节字符集，对于PreparedStatement.setBytes()，采用十六进制转义特性。
-增加了对“EUC_JP_Solaris”字符编码的支持，映射到“eucjpms”的MySQL编码（从3.1版开始的反向移植）。它只能在支持eucjpms的服务器山工作，也就是说5.0.3或更高版本。
11-15-04：版本3.0.16-ga
-连接至MySQL-4.1或更高版本且再次使用连接池和／或Connection.changeUser()时，将再次发出字符集配置命令。
-更正了ResultSetMetaData.isReadOnly()，以便在连接至MySQL-4.1或更高版本时，能根据“原始的”表名和列名，检测不可写的列。
-更正了BUG#5664，当ResultSet.updateByte()位于插入行上时抛出ArrayOutOfBoundsException。
-更正了DatabaseMetaData.getTypes()，对于NUMERIC类型，它返回不正确的（非负）标度。
-更正了BUG#6198，Buffer.readString(string)中的“off-by-one”问题。
-通过“tinyInt1isBit”属性，使得能够对TINYINT(1) -> BIT/Boolean转换进行配置（为了与JDBC兼容，默认为“真”）。
-如果服务器版本大于等于4.1.1，在连接建立过程中仅设置“character_set_results”。
-更正了回归问题，其中，useUnbufferedInput默认为“假”。
-更正了BUG#6231，ResultSet.getTimestamp()作用在具有TIME的列上时失败。
09-04-04：版本3.0.15-production
-更正了BUG#4010，对于GBK，StringUtils.escapeEasternUnicodeByteStream仍被破坏。
-更正了BUG#4334，对于autoReconnect的故障切换，对任何主机均不使用端口“#”，而且不重试所有主机。（警告：需要更改SocketFactory connect()方法的特征，它目前是公共套接字连接（String host，int portNumber，Properties props）。也能次，必须更改任何第三方套接字实施方式以支持该特征。
-当它们已被关闭并被返回到连接池时，由MysqlConnectionPoolDataSource创建的逻辑连接将发出rollback()。如果你的应用服务器/连接池已帮助你完成了该任务，可以将“rollbackOnPooledClose”属性设置为“假”以避免额外的rollback()开销。
-删除了结果集中对checkRowPos()的多余调用。
-更正了BUG#4742，在DBMD.getTypeInfo()中，“DOUBLE”映射了两次。
-增加了FLOSS许可豁免。
-更正了BUG#4808，在PooledConnection上调用两次.close()将导致NPE。
-更正了BUG#4138和BUG#4860，对于无符号列，DBMD.getColumns()返回错误的JDBC类型。这也会影响对RSMD.getColumnType()和RSMD.getColumnTypeNames()方法中所有数值类型的类型映射，以确保DBMD.getColumns()的类似类型与RSMD.getColumnType()和RSMD.getColumnTypeNames()返回的类型匹配。
-分发版命名方案中的“Production”-“GA”。
-更正了BUG#4880，对于非数值类型，RSMD.getPrecision()返回0（对于非二进制类型，应返回字符的最大长度，对于二进制类型，应返回最大字节长度）。根据服务器发回的长度（在网络协议层，服务器不区分TINYBLOB、BLOB、MEDIUMBLOB或LONGBLOB），它还更正了针对BLOB类型的RSMD.getColumnType()和RSMD.getColumnTypeName()映射。
-更正了BUG#5022，结果集应在“.close()”中释放Field[]实例。
-更正了BUG#5069，如果结果集已关闭，ResultSet.getMetaData()不应返回未正确初始化的元数据，而是应抛出SQLException。此外，在对实例级别的字段（.close()过程中取消的字段）进行操作之前，通过调用checkClosed()，它还更正了getRow()、getWarnings()和遍历方法。
-从4.1.x版服务器开始，能解析新的时区变量。
-与MySQL-4.1.x或更高版本连接时，为PreparedStatement.setBytes()和set*Stream()使用“_binary”引介词，以防止在字符集转换过程中出现错误判断。
05-28-04：版本3.0.14-production
-更正了URL解析错误。
05-27-04：版本3.0.13-production
-更正了BUG#3848，无服务器名称时，不能使用MySQLDatasource。
-更正了BUG#3920，使用MysqlConnectionPoolDataSource时出现“No Database Selected”（未选择数据库）。
-更正了BUG#3873，对于批插入，PreparedStatement.getGeneratedKeys()方法仅返回1个结果。
05-18-04：版本3.0.12-production
-为TYPE_NAME列中的DatabaseMetaData.getColumns()输出增加了无符号属性。
-增加了“failOverReadOnly”属性，允许最终用户配置出现故障切换时的连接状态（只读／可写）。
-自3.1开始，反向移植了“change user”和“reset server state”功能，允许MysqlConnectionPoolDataSource的客户端复位连接池上getConnection()的服务器状态。
-使用MySQL-4.1或更高版本时，不对SJIS/GBK/BIG5进行转义处理。
-允许MysqlDataSource和MysqlConnectionPool数据源使用“url”参数，以便能够从内部应用服务器传递其他属性。
-将复制键和外键错误映射到“23000”的SQLState。
-自3.1开始，反向移植了文档编制工具。
-返回用于结果集的创建语句，该结果集由getGeneratedKeys()创建（BUG#2957）。
-允许作为参数将java.util.Date发送到PreparedStatement.setObject()，将其转换为Timestamp类型以保持完整精度（BUG#3103）。
-使用setBytes()和/或setBinary/CharacterStream()时，不截取BLOB/CLOB（BUG#2670）。
-连接时，在使用“SHOW COLLATION”的MySQL-4.1.0和更高版本上，为字段级字符集动态配置字符集映射。
-将“binary”字符集映射到“US-ASCII”，以支持4.1.2和更高版本服务器的DATETIME字符集识别功能。
-在初始化过程中使用“SET character_set_results”，允许将结果集的任何字符集返回到驱动程序。
-在>= 4.1.0的MySQL上发出“SET NAMES”之前，在连接至编码查询的过程中，使用返回的charsetnr。
-为ResultSetMetaData（getColumnCharacterEncoding()和getColumnCharacterSet()）增加了Helper（助手）方法，允许最终用户查看驱动程序认为应在列上使用的字符集。
-在>= 4.1.0的MySQL上仅设置character_set_results。
-更正了BUG#3511，StringUtils.escapeSJISByteStream()不能正确处理所有的东方双字节字符集。
-将StringUtils.escapeSJISByteStream()重新命名为更贴切的escapeEasternUnicodeByteStream()。
-更正了BUG#3554，在URL中未指定数据库将导致MalformedURL exception。
-如果使用了characterEncoding属性，自动将MySQL编码名称转换为Java编码名称。
-增加了在某些JVM上能识别的编码名称，以更正错误地将其逆向映射为MySQL编码名称的问题。
-为所有单元测试使用junit.textui.TestRunner（允许在Ant或Eclipse以外的命令行上运行它们）。
-更正了BUG#3557，UpdatableResultSet不能获取moveToInsertRow()的默认值。
-更正了BUG#3570，不一致的列类型通报。服务器仍不能正确返回*BLOBs *TEXT的所有类型，因此驱动程序也不能正确返回它们。
-更正了BUG#3520，DBMD.getSQLStateType()返回不正确的值。
-更正了PreparedStatement.setString()和东方字符编码中的递归问题。
- 增加了对StringRegressionTest 4.1-unicode的识别。
02-19-04：版本3.0.11-stable
-通过“characterEncoding”属性将编码方式强制设为“utf8”或“utf-8”时，触发“SET NAMES utf8”。以前，只能用Java风格的“utf-8”编码名称才能触发该操作。
-AutoReconnect时间的增长速度快于指数速度（BUG#2447）。
-更正了故障切换总跳至列表中最后1个主机的问题（BUG#2578）。
-增加了“useUnbufferedInput”参数，它也是目前的默认参数（因JVM事宜，http://developer.java.sun.com/developer/bugParade/bugs/4401235.html）。
-检测服务器上lower_case_table_names的“on/off”，或“1”、“2”、“3”形式。
-为ResultSetMetaData.getColumnClassName()的TINYINT和SMALLINT类型返回“java.lang.Integer”（更正了BUG#2852）。
-为ResultSetMetaData.getColumnClassName()的FLOAT类型返回“java.lang.Double”（更正了BUG#2855）。
-为ResultSetMetaData.getColumnClassName()的BINARY、VARBINARY和LONGVARBINARY类型返回“[B”而不是“java.lang.Object”（兼容JDBC）。
-在由ConnectionPoolDataSource创建的所有实例上发出连接事件。
01-13-04：版本3.0.10-stable
-在PreparedStatement解析中，当位于“字符串”内时，不对引用的ID进行计数（更正了BUG#1511）。
-关于PacketTooLargeException的“Friendlier”异常消息（BUG#1534）。
-从3.1版开始，反向移植了对checkUpdatability()方法中别名表和UpdatableResultSets的补丁。
-更正了使用Statement.setMaxRows()时出现的ArrayIndexOutOfBounds异常（BUG#1695）。
-更正了BUG#1576，处理未正确读取的大BLOB和分离信息包。
-更正了Statement.getGeneratedKeys()和REPLACE语句的递归问题。
-更正了BUG#1630，如果结果集是不可更新的，对ResultSet.updateFoo()的后续调用将导致NPE。
-确定了4.1.1风格的auth，无密码。
-更正了BUG#1731，外键列的顺序与DatabaseMetaData.getImported/Exported/CrossReference()不一致。
-更正了BUG#1775，DatabaseMetaData.getSystemFunction()返回错误函数“VResultsSion”。
-更正了BUG#1592，未正确检查交叉数据库可更新结果集的可更新性。
-对于MySQL LONGTEXT类型，DatabaseMetaData.getColumns()应返回Types.LONGVARCHAR。
-作用在TINYINT和SMALLINT列上的ResultSet.getObject()应返回Java类型“Integer”（BUG#1913）。
-增加了“alwaysClearStream”连接属性，它会使驱动程序在每次查询前清空输入流上任何余留的数据。
-增加了更具描述性的错误消息“Server Configuration Denies Access to DataSource”（服务器配置拒绝对数据源的访问），并能从服务器上检索消息。
-如果已发生变化，Autoreconnect代码在红心连接时不设置catalog。
-实现了ResultSet.updateClob()。
-对于CHAR/VARCHAR列，ResultSetMetaData.isCaseSensitive()返回错误值。
-更正了BUG#1933，不尊重连接属性“maxRows”。
-更正了BUG#1925，在DBMD.extractForeignKeyFromCreateTable()中，创建语句的次数太多。
-更正了BUG#1914，支持转义序列{fn convert ... }-更正了BUG#1958，当参数编号等于参数数目＋1时，ArrayIndexOutOfBounds。
-更正了BUG#2006，当SELECT查询中有多个重复列名时，ResultSet.findColumn()应使用第1个匹配的列名（兼容JDBC）。
-从PreparedStatement.setTimestamp()中删除了静态同步瓶颈。
-从SingleByteCharsetConverter的实例方法中删除了静态同步瓶颈。
-允许通过“cachePrepStmts”、“prepStmtCacheSize”和“prepStmtCacheSqlLimit”属性，对预处理语句的解析步骤进行高速缓冲处理（默认情况下禁止）。
-加快了PreparedStatements的解析操作，只要可能，尽量采用一次性方式。
-更正了在小应用程序中使用时的安全异常问题（小应用程序不能读取LOAD DATA LOCAL INFILE所需的系统属性“file.encoding”）。
-为SQLStates使用常数。
-连接至MySQL-4.1.0或更高版本时，将字符集“ko18_ru”映射到“ko18r”。
-确保Buffer.writeString()保存在“\0”之外的空间内。
-更正了“connect w/ JDK-1.4.0”上的异常“未知字符集danish”。
-更正了SQLError中的映射功能，用“41000”SQLStates通报死锁状态。
-“maxRows”属性会影响内部语句，因此，应检查为驱动程序创建的所有内部语句，并在不是内部语句的情况下将其设为0。
10-07-03：版本3.0.9-stable
-ResultSet和PreparedStatement中更快的日期处理代码（不再使用用来同步静态日历的Date方法）。
-更正了对Buffer.readString()中缓冲区末端的测试。
-更正了ResultSet.previous()行为方式，当位于结果集的第1行上时，将当前位置移到结果集之前（bugs.mysql.com BUG#496）。
-更正了当已使用setMaxRows()而且在查询中包含LIMIT子句时发出伪查询的语句和PreparedStatement。
-更正了BUG#661，当主键值包含需要转义的值时refreshRow不工作（以双倍转义结束）。
-提取DatabaseMetaData中的外键信息时，支持InnoDB约束名，BUG#517和BUG#664（由Parwinder Sekhon提出）。
-从3.1版开始，反向移植了4.1协议变化（服务器端SQL状态，新字段信息，较大的客户端能力标志，与数据库的连接等）。
-更正了UpdatableResultSet，作用在插入行上时，为getXXX()返回值（BUG#675）。
-调用moveToInsertRow()时，能够用默认的列值加载UpdatableResultSet中的insertRow（BUG#688）。
-对于指定为NULL的默认值，DatabaseMetaData.getColumns()未返回NULL。
-将默认的语句类型／并发行更改为TYPE_FORWARD_ONLY和CONCUR_READ_ONLY（兼容规范）。
-如果MySQL不支持，不要尝试或复位再连接上的隔离级别。
-不将SQLExceptions封在RowDataDynamic内。
-如果useTimezone==true，不更改时间戳TZ两次（BUG#774）。
-更正了大的分离信息包处理中存在的回归问题（BUG#848）。
-更好地诊断“流式”结果集异常中的错误消息。
-在空结果集上抛出关于ResultSet.getXXX()的异常（在某些情况未被俘获）。
-不隐藏关于在I/O层中抛出异常的消息。
-关闭连接池时或在具有已打开连接的PooledConnection.getConnection()上，不触发连接关闭时间（BUG#884）。
-截短+/- INF（最小和最大代表值，对于MySQL中的类型），以及NaN（至0，对于setDouble/setFloat()），当服务器不支持+/- INF或NaN时，就语句发出警告。
-更正了BUG#879，当字符集为SJIS或GBK时，以及“\”出现在非转义输入中时对“\”的双转义处理。
-清空“流式”结果集未使用行的输入流时，每100行均有当前线程yield()，以免独占CPU时间。
-更正了BUG#1099，DatabaseMetaData.getColumns()弄不清字符列中的关键字“set”。
-更正了与Statement.setMaxRows()相关的死锁事宜。
-更正了CLOB.truncate()，BUG#1130。
-优化了CLOB.setChracterStream(), BUG#1131。
-使databaseName、portNumber以及serverName成为MysqlDataSourceFactory的可选参数（BUG#1246）。
-修订了BUG#1247，导致字符127损坏的ResultSet.get/setString。
-从3.1版开始，反向移植了针对4.11和更高版本的auth.更改。
-增加了com.mysql.jdbc.util.BaseBugReport，以帮助创建缺陷报告的测试范例。
-通过将“clobberStreamingResults”属性设置为“真”（默认为“假”），为“clobber”流式结果增加了属性。这会使“流式”结果集被自动关闭，如果在所有数据尚未从服务器中读取完之前，执行了另一查询，正在从服务器流出的任何未完成数据均将被舍弃。
05-23-03：版本3.0.8-stable
-允许在Driver.getPropertyInfo()中使用伪URL。
-与Statement.getGeneratedKeys()一起使用多值INSERTS时，返回所生成键的列表。
-与文件名和“LOAD DATA [LOCAL] INFILE”一起使用JVM字符集。
-更正了与Connection.cleanup()有关的无限循环。
-将Ant目标“compile-core”更改为“compile-driver”，并使测试套件编译成为单独的目标。
-更正了未获得关于Statement.executeUpdate()的集合的结果集，在某些情况下，它会影响getGeneratedKeys()和getUpdateCount()。
-字符串中的Unicode字符0xFFFF会导致驱动程序抛出ArrayOutOfBoundsException（Bug #378）。
-使用“REPLACE”语句时返回所生成键的正确数目。
-更正了在某些情况下检测服务器字符集的问题。
-更正了使用极大信息包时的行数据解码错误。
-优化了行数据解码。
-在已关闭预处理语句上执行操作使抛出异常。
-更正了SJIS编码缺陷，感谢Naoto Sato。
-优化了EscapeProcessor的使用。
-允许对Statement.close()的多次调用。
04-08-03：版本3.0.7-stable
-更正了调用错误事件类型的MysqlPooledConnection.close()。
-更正了PreparedStatement.setClob()中的StringIndexOutOfBoundsException。
- 4.1版列元数据更正。
-从Driver.connect()和Driver.acceptsUrl()中删除了同步功能。
-事务过程中的IOExceptions现在会导致关闭连接。
-更正了ResultSetMetaData.getColumnTypeName()中丢失的“YEAR”类型转换。
-对于DBMD.getPrimaryKeys()，不提取以“pri”作为主键起始的索引。
-试图在强制关闭的连接上执行操作时抛出SQLExceptions（即，通信链路失败时）。
-现在，可以使用Connection.setProfileSql(boolean)来打开或关闭仿型功能。
更正了与数据库元数据有关的字符集事宜（字符集不能正确获取集合）。
-与MySQL-4.1或更高版本连接时，现在能够为别名表/列创建可更新结果集。
-更正了文件大于“max_allowed_packet”时的“LOAD DATA LOCAL INFILE”缺陷。
-对于GBK和Big5字符集，更正了0x5c ('\')字符的转义功能。-更正了基础字段为DATE类型时的ResultSet.getTimestamp()问题。
-保证了来自alignPacketSize()的信息包大小不超过MAX_ALLOWED_PACKET（JVM缺陷）。
-autoReconnecting（自动再连接）时不复位Connection.isReadOnly()。
02-18-03：版本3.0.6-stable
-更正了ResultSetMetaData，当catalog未知时返回""。更正了与Sun CachedRowSet有关的NullPointerExceptions。
-更正了DBMD.getTypeInfo()和DBMD.getColumns()为TEXT/BLOB类型中的精度返回不同值的问题。
-通过将“ignoreNonTxTables”设置为“真”，在回退期间（兼容性／可用性），允许忽略“non transactional tables”（非事务表）告警。
-更正了在初始连接上SQLExceptions耗尽的问题。
-更正了Statement.setMaxRows()，当其不需要时，停止发送“LIMIT”类型的查询（性能）。
-整理了语句查询/方法失配测试（即，不允许与.executeQuery()一起使用INSERT）。
-在ResultSet遍历方法中增加了更多检查，以获取何时处于关闭状态的信息。
-更正了ResultSetMetaData.isWritable()以返回正确值。
-为DBMD.nullsAreSortedAtStart增加了不同NULL分类行为的“窗口”（4.0.2至4.0.10，真，其他为“否”）。
-实现了Blob.setBytes()。仍需要将所得的Blob传回到可更新ResultSet（结果集）或PreparedStatement以保持变更，这是因为MySQL不支持“定位器”。
-从Connector/J 3.1反向移植了4.1字符集字段。
01-22-03：版本3.0.5-gamma
-更正了解包字段时对某些查询Buffer.fastSkipLenString()导致ArrayIndexOutOfBounds异常的问题。
-为Connection.getTypeMap()实现了空的TypeMap，以便某些第三方应用程序能与MySQL一起工作（IBM WebSphere 5.0连接池）。
-为DBMD.getColumns()增加了丢失的LONGTEXT类型。
-当MySQL版本支持时，Connection.getTransactionIsolation()能从数据库检索TX_ISOLATION，而不是实例变量。
-引用DatabaseMetaData.getColumns()、getPrimaryKeys()、getIndexInfo()、getBestRowIdentifier()中的表名。
-大幅度降低了PreparedStatements中setBinaryStream()所需的内存。
-更正了ResultSet.isBeforeFirst()处理空结果集方面的问题。
-为外键元数据增加了“更新”选项。
01-06-03：版本3.0.4-gamma
-为Connection.setCatalog增加了对数据库名的引用ID。
-在PreparedStatement分析程序中增加了对引用ID的支持。
-对于setByte()，在PreparedStatements中，流线式字符转换和byte[]处理。
-通过与MysqlIO共享出站信息包，降低了PreparedStatements的内存占用。
-增加了“strictUpdates”属性，能够对可更新结果集的大量“正确性”检查进行控制。如果希望获得更快的可更新结果集，并使用主键通过作用在表上的SELECT创建了结果集，而且在查询中选择了所有的主键，应将其设置为“假”。
-增加了对4.0.8风格大信息包的支持。
-更正了PreparedStatement.executeBatch()参数重写的问题。
12-17-02：版本3.0.3-dev
-将SingleByteCharConverter中的charsToByte更改为非静态类型。
-更改了SingleByteCharConverter，以使用各转换器的空闲初始化特性。
-更正了Fields.java中的字符集处理功能。
-实现了Connection.nativeSQL()。
-更可靠的转义标志“-- recognize '--'”注释，并允许嵌套式转义序列（请参见testsuite.EscapeProcessingTest）。
-DBMD.getImported/ExportedKeys()现在能处理每个表上的多个外键。
-更正了对某些浮点类型ResultSetMetaData.getPrecision()返回错误值的问题。
-更正了ResultSetMetaData.getColumnTypeName()对TEXT类型返回BLOB，对BLOB类型返回TEXT的问题。
-对于4.1和更高版本服务器，更正了Buffer.isLastDataPacket()。
-增加了CLIENT_LONG_FLAG，以便能获得更多的列标志（isAutoIncrement()最重要）。
-由于上述原因，实现了ResultSetMetaData.isAutoIncrement()以使用Field.isAutoIncrement()。
-在DatabaseMetaData方法中比较表名且在服务器中允许时，优先考虑“lower_case_table_names”。
-一些MySQL-4.1协议支持（扩展字段信息）。
-使用非别名表/列名和数据库名，以完全限定UpdatableResultSet中的表和列（需要MySQL-4.1或更高版本）。
-允许用户通过“continueBatchOnError”属性（默认为“真”）更改Statement/PreparedStatement.executeBatch()的行为。
-在更多连接方法（createStatement、prepareStatement、setTransactionIsolation、setAutoCommit）中检查关闭的连接。
-更可靠地实现了可更新结果集。检查表的所有主键是否已被选择。
-如果在服务器的配置允许，“LOAD DATA LOCAL INFILE ...”现在能正常工作。不能使用“allowLoadLocalInfile”属性关闭它（请参见README）。
-在单字节字符集中，对于未知的字符转换，用“?”替代“\0”。
- NamedPipeSocketFactory现能正常工作（仅对Windows平台）。具体说明请参见README。
11-08-02：版本3.0.2-dev
-更正了可更新结果集和PreparedStatements不工作的问题。
-更正了ResultSet.setFetchDirection(FETCH_UNKNOWN)。
-更正了使用任意值并调用Statement.setFetchSize()时的问题。
-更正了ResultSet.getLong()中的不正确转换。
-实现了ResultSet.updateBlob()。
-删除了UpdatableResultSet中的重复代码（能从ResultSet继承而来，不需要各方法处理可更新性的额外代码，但我认为在将来可能需要）。
-更正了通过属性“强制”字符编码时抛出的“UnsupportedEncodingException”。
-更正了各种非ASCII字符编码问题。
-增加了驱动程序属性“useHostsInPrivileges”。默认值为“真”。它将影响是否在“DBMD.getColumn/TablePrivileges”中使用“@hostname”。
-描述方案的所有DBMD结果集列现返回NULL，以便能与用于其他数据库的其他JDBC驱动程序的行为更兼容（MySQL不支持方案）。
-增加了SSL支持。关于如何使用它的更多信息，请参见README。
-执行自动再连接或故障切换时，恰当恢复连接属性，包括autoCommit状态以及隔离级别。
-可能时，使用“SHOW CREATE TABLE”，以确定用于DatabaseMetaData的外键信息，对于返回的DELETE信息还允许级联选项。
-对于SJIS字符集，转义了字符串中的“0x5c”字符。
-更正了Clob.getSubString()中起始位置偏离1的错误。
-实现了Clob.truncate()。
-实现了Clob.setString()。
-实现了Clob.setAsciiStream()。
-实现了Clob.setCharacterStream()。
-增加了com.mysql.jdbc.MiniAdmin类，该类允许你将“shutdown”命令发送至MySQL服务器。在最终用户应用中嵌入Java和MySQL服务器时使用。
-增加了“connectTimeout”参数，允许JDK-1.4和更高版本的用户指定建立连接所需等候的最长时间。
-仅当连接处于autoCommit(false)状态时，故障切换和autoReconnect才能工作，目的在于保持事务的安全。
-增加了“queriesBeforeRetryMaster”属性，出现故障切换时而且在重新连接到主服务器之前，该属性指定了能够发出的查询数目（默认为50）。
-更正了DBMD.supportsResultSetConcurrency()，以便为ResultSet.TYPE_SCROLL_INSENSITIVE和ResultSet.CONCUR_READ_ONLY或ResultSet.CONCUR_UPDATABLE返回“真”。
-更正了ResultSet.isLast()处理空结果集方面的问题（应返回“假”）。
- PreparedStatement现在将优先考虑setBinary/Ascii/Character Stream()中的流长度，除非将连接属性“useStreamLengthsInPrepStmts”设置为“假”。
-删除了一些使用EscapeProcessor、Connection和DatabaseMetaData类中的“Strings smarter”创建的不需要的临时对象。
09-21-02：版本3.0.1-dev
-更正了ResultSet.getRow()偏差1的缺陷。
-更正了RowDataStatic.getAt()偏差1的缺陷。
-增加了有限Clob功能（ResultSet.getClob()、PreparedStatemtent.setClob()、PreparedStatement.setObject(Clob)）。
-为URL增加了socketTimeout参数。
- Connection.isClosed()不再对服务器执行“Ping”操作。
-当“getAutoCommit() == false”时Connection.close()发出rollback()。
-增加了“妄想”参数，通过删除其中的“敏感”信息清理了错误消息（即，主机名、端口、用户名等），并在可能的情况下，清理了“敏感”的数据结构。
-更正了ResultSetMetaData.isSigned()在处理TINYINT和BIGINT方面的问题。
- 现在将自动检测字符集。优化了单字节字符集转换的代码。
-实现了ResultSet.getCharacterStream()。
-为DatabaseMetaData.getTableTypes()中的表类型增加了“LOCAL TEMPORARY”。
- 整理了大块代码，以遵循Java编码惯例（时机成熟）。
07-31-02：版本3.0.0-dev
- !!! 许可变化!!! 驱动现在是GPL。如果需要非GPL许可，请与我们联系（mark@mysql.com）。
- JDBC-3.0功能包括Statement/PreparedStatement.getGeneratedKeys()和ResultSet.getURL()。
-性能增强，在大多数情况下，驱动程序快了50-100％，而且创建的临时对象更少。
-重新封装...新的驱动程序名是“com.mysql.jdbc.Driver”，但旧名称依然有效（驱动程序现由MySQL-AB提供）。
-更好地在语句和PreparedStatement中检查已关闭的连接。
-支持流式结果集（按行），请参见README，感谢Doron。
-支持大信息包（MySQL-4.0协议的新增内容），更多信息请参见README。
- JDBC兼容，除了存储程序测试外，提供了所有测试。
-更正并分类了DBMetaData中的主键名称（SF缺陷582086和582086）。
-浮点类型现为java.sql.Types.FLOAT（SF缺陷579573）。
- ResultSet.getTimestamp()现在能处理DATE类型（SF缺陷559134）。
- ResultSet.getDate/Time/Timestamp现在能识别由MySQL设置为全零的所有形式的无效值（SF缺陷586058）。
- Testsuite现在将使用Junit（可从www.junit.org获得）。
-驱动程序现在仅能与JDK-1.2或更高版本一起工作。
-增加了多主机故障切换支持（请参见README）。
-进行了一般性的源码清理。
-读取信息包时，通过控制MysqlIO类创建的过渡对象，改善了总的速度。
-改善了字符串处理和字段元数据创建的性能（例示），由Alex Twisleton-Wykeham-Fiennes提供。
05-16-02：版本2.0.14
-更多代码整理。
- PreparedStatement现在能释放.close()上的资源（SF缺陷553268）。
-如果服务器版本不支持，不使用引用ID。此外，如果服务器是以“—ansi”或“--sql-mode=ANSI_QUOTES”开始，那么“"”将用作ID引用，否则将使用“`”。
- ResultSet.getDouble()现在能更准确地使用JDK内置的代码（但较慢）。
- LogicalHandle.isClosed()调用，直至物理连接。
-增加了SQL仿型功能（到STDERR）。在JDBC url中设置“profileSql=true”。更多信息请参见README。
-更正了relaxAutoCommit参数的类型。
04-24-02：版本2.0.13
-更多代码整理。
-更正了未能正确读取的unicode字符（SF缺陷541088）。
-为PrepStmt提供了更快的Blob转义功能。
-为DataSource(s)增加了set/getPortNumber()（SF缺陷548167）。
-为MySQLXADataSource增加了setURL()（SF缺陷546019）。
-更正了PreparedStatement.toString()（SF缺陷534026）。
-实现了ResultSetMetaData.getColumnClassName()。
- 现在实施了来自JDBC-3.0的Statement.getGeneratedKeys()的初级版本（要想使之工作，需要使用JDK-1.4，我个人认为）。
- DBMetaData.getIndexInfo()，更正了不良的PAGES（SF缺陷542201）。
04-07-02：版本2.0.12
-一般性代码整理。
-为Connection和MysqlLogicalHandle增加了getIdleFor()方法。
-放松了所有类中的功能，应更正520615和520393。
-为DBMD增加了getTable/ColumnPrivileges()（更正484502）。
-为getTypeInfo()增加了新类型，更正了已有类型，感谢Al Davis和Kid Kalanon。
-为PreparedStatement增加了BIT类型支持（51870）。
-更正了ResultSet中的getRow()缺陷（527165）。
-更正了PreparedStatement中的ResultSet可更新性。
-更正了PreparedStatement中时区偏差1小时的缺陷（538286、528785）。
- ResultSet: 更正了可更新性（如果不可更新，将值设为NULL）。
- DataSources，更正了setUrl缺陷（511614、525565），错误的数据源类名（532816、528767）。
-为需要它们的所有DatabaseMetaData方法增加了ID引用（应更正518108）。
-增加了对YEAR类型的支持（533556）。
- ResultSet.insertRow()目前能够在大多数情况下检测auto_increment字段，并在新行中使用该值。但是，该检测不适用于多值键，原因在于MySQL协议不返回该类信息。
-实现了ResultSet.refreshRow()。
-更正了testsuite.Traversal afterLast()缺陷，感谢Igor Lastric。
01-27-02：版本2.0.11
-更正了DBMD.getImported/ExportedKeys()和getCrossReference()中丢失的DELETE_RULE值。
-Statement.java的完全同步。
-多处修改，更正了读取BLOB时的“Unexpected end of input stream”（输入流意外结束）错误。这应是最后更正。
01-24-02：版本2.0.10
-更正了MysqlIO中的虚假“Unexpected end of input stream”（输入流意外结束）错误（缺陷507456）。
-更正了与Websphere 4一起使用MysqlConnectionPoolDataSource时的“null-pointer-exceptions”（缺陷505839）。
01-13-02：版本2.0.9
- Ant创建失败，包括jar文件，已更正（缺陷487669）。
-更正了MysqlIO.readPacket()中额外的内存分配（缺陷488663）。
-实现了DatabaseMetaData.getExported/ImportedKeys()和getCrossReference()。
-在更改实例和类共享引用的方法上，实现了完全同步，驱动程序现在是完全线程安全的（如果遇到问题，请告诉我）。
-将DataSource实施移至org.gjt.mm.mysql.jdbc2.optional软件包，PooledConnectionDataSource和XADataSource的原始实施仍保留在原处（感谢Todd Wolff给出了PooledConnectionDataSource与IBM WebSphere 4一起的实施方案和测试结果）。
-增加了读取信息包时对关闭网络连接的检测（感谢Todd Lizambri）。
-更正了与转义处理其有关的错误（缺陷486265）。
-通过DatabaseMetaData，支持批更新（缺陷495101）。
-更正了PreparedStatement.setTimestamp()中偏差1小时的错误（缺陷491577）。
-从驱动程序中删除了级连支持（“||”操作符），较早的VisualAge版本似乎是使用它的唯一软件，它与逻辑“||”操作符冲突。要想使用“||”操作符作为级联，需要用“--ansi”标志启动mysqld（缺陷491680）。
-更正了PreparedStatement中的舍弃缺陷（488663）。
11-25-01：版本2.0.8
-现在支持批更新（感谢Daniel Rall的鼓励）。
- XADataSource/ConnectionPoolDataSource代码（实验性）。
- PreparedStatement.setAnyNumericType()现在能正确处理正指数（增加了“+”，因此MySQL能理解它）。
- DatabaseMetaData.getPrimaryKeys()和getBestRowIdentifier()目前在识别主键方面更加可靠（匹配，不管主键在Key_type列中的大小写、或缩写／全名）。
10-24-01：版本2.0.7
- PreparedStatement.setCharacterStream()现已实现。
-更正了处于高利用率模式（autoReconnect=true）下时的悬挂套接字问题，连接的finalizer将关闭任何在GC上悬挂的套接字。
-更正了在较新版本的MySQL上ResultSetMetaData.getPrecision()返回的值比实际值小1的问题。
-如果列值为NULL，ResultSet.getBlob()现在将返回NULL。
-如果useUnicode=true而且未设置characterEncoding，将从数据库读取字符集。（感谢Dmitry Vereshchagin）。
-从数据库读取初始事务隔离级别（如果可用的话）（感谢Dmitry Vereshchagin）。
-更正了DatabaseMetaData.supportsTransactions()，supportsTransactionIsolationLevel()，getTypeInfo() SQL_DATETIME_SUB，以及不可读取的SQL_DATA_TYPE字段。
-更正了用于生成SQL并回在某些查询中以语法错误结束的PreparedStatement。
-更正了ResultSet.isAfterLast()总返回“假”的问题。
-更正了PreparedStatement.setTimestamp()中的时区问题（感谢Erik Olofsson）。
-在URL或属性中传递了“captializeTypeNames=true”时，将类型名转换为大写（对于WebObjects，感谢Anjo Krank）。
-可更新结果集现在能正确处理字段中的NULL值。
- PreparedStatement.setDouble()现在能使用双精度值（撤销了以前所作的截取更正）。
-如果MySQL的版本高于或等于3.21.23，PreparedStatement.setBoolean()将使用1/0值。
06-16-01：版本2.0.6
-更正了PreparedStatement参数检查功能。
-更正了ResultSet.java中区分大小写的列名。
06-13-01：版本2.0.5
- 更正了ResultSet.getBlob() ArrayIndex超出范围的问题。
-更正了ResultSetMetaData.getColumnTypeName关于TEXT/BLOB的问题。
-更正了发送大BLOB查询时的ArrayIndexOutOfBounds问题（未设置最大信息包大小）。
-为Connection.setIsolationLevel()增加了ISOLATION级别支持。
-更正了所有列均未设置时在PreparedStatement.executeUpdate()上的NPE问题。
-更正了采用两位数字年份的TIMESTAMP的数据解析问题。
-为PreparedStatement.setObject()增加了Byte。
- ResultSet.getBoolean()现在能将“-1”识别为“真”。
- ResultSet具有+/-Inf/inf支持特性。
-即使并非所有列均已被设置（设为NULL），ResultSet.insertRow()现在也能工作。
- DataBaseMetaData.getCrossReference()不再使用ArrayIndexOOB。
-作用在结果集上的getObject()能正确执行TINYINT->Byte和SMALLINT->Short操作。
12-03-00：版本2.0.3
-为JDBC2实现了不带标度组分的getBigDecimal()。
-更正了与可更新结果集有关的复合键问题。
-增加了-/+INF对双精度的检测。
-更快的ASCII字符串操作。
-更正了MAX_ALLOWED_PACKET的不正确检测，因此，现在能发送大的Blob。
-更正了java.sql.Blob实施代码中的“偏差1”错误。
-增加了“ultraDevHack”URL参数，将其设置为“真”，可允许Macromedia UltraDev使用该驱动程序。
04-06-00：版本2.0.1
-更正了RSMD.isWritable()返回错误值的问题。感谢Moritz Maass。
-整理了连接确定时的异常处理功能。
-使用getObject()，具有TEXT类型的列现在会作为字符串返回。
- DatabaseMetaData.getPrimaryKeys()现在能正确工作（写入到key_seq）。感谢Brian Slesinsky。
-按照JDBC规范，在PreparedStatements上，不再进行转义处理。
-更正了很多JDBC-2.0遍历、定位错误，尤其是写入空结果集的问题。感谢Ron Smits、Nick Brook、Cessar Garcia和Carlos Martinez。
-更正了使用多个主键时，与结果集中可更新性支持有关的一些问题。
02-21-00：版本2.0pre5
-更正了不良的握手问题。
01-10-00：版本2.0pre4
-更正了针对insertRow()的结果集，感谢Cesar Garcia。
-对驱动程序进行了修改，使之能够通过加载JDBC-2.0类来识别JDBC-2.0，而不是依靠JDK版本号。感谢John Baker。
-更正了结果集，以返回正确的行号。
- Statement.getUpdateCount()现在能返回匹配的行，而不是实际更新的行，它更像SQL-92。
10-29-99
-更正了Statement/PreparedStatement.getMoreResults()缺陷。感谢Noel J. Bergman。
-为PreparedStatement.setObject()增加了Short类型。感谢Jeff Crowder。
-驱动程序现在能通过查询服务器自动配置最大/首选的信息包大小。
-如果服务器支持，Autoreconnect代码将使用更快的ping命令。
-更正了从服务器读取信息包、以及为写入到服务器而分配信息包时与信息包大小有关的多种缺陷。
08-17-99：版本2.0pre
-目前是在JDK-1.2下编译的。通过核心类集合，驱动程序同时支持JDK-1.1和JDK-1.2。在运行时，通过判断你所使用的JVM版本，驱动程序将加载恰当的接口类。
-修正了在首行中全为NULL的结果集。（由Tim Endres指出）。
-更正了结果集内SQLExceptions的列编号（感谢Blas Rodriguez Somoza）。
-不再需要将数据库指定给连接。（感谢Christian Motschke）。
07-04-99：版本1.2b
-更好的文档（不断改善），doc/mm.doc/book1.html。
-对于列名模式，DBMD现在允许null（未在规范中定义），它将被更改为“%”。
- DBMD现在提供了针对getXXX()的正确类型／长度。
-修改了ResultSet.getDate()、getTime()和getTimestamp()。（由Alan Wilken提供）。
- EscapeProcessor现在能正确处理引号内的“\{ \}”和“{ or }”。（感谢Alik就如何修正它给出的观点）。-对连接中的属性处理功能进行了修正。（由Juho Tikkala提供）。
-对于表中的NULL列，ResultSet.getObject()现在能返回NULL，而不是销毁。（感谢Ben Grosman）。
-对于MySQL不了解的类型，ResultSet.getObject()现在能返回字符串。（由Chris Perdue建议）。
-删除了不需要的DataInput/Output流，对于每次IO操作，1／2的方法调用都是不需要的。
-如果未指定字符编码，使用默认的字符编码。这是对已损坏JVM的一种避规措施，这是因为，按照规范，所有的JVM都必须支持“ISO8859_1”，但并非如此。
-更正了连接事宜，如果未明确设置字符编码，将使用平台的字符编码，而不是“ISO8859_1”。它修正了加载并不总存在的字符转换器类时存在的问题（JVM缺陷）。（感谢Fritz Elfert指出了该问题）。
-修改了MysqlIO，使之在可能的情况下再次使用信息包，而不是降低内存使用率。
-更正了与引号内“{}”有关的转义处理器缺陷。04-14-99：版本1.2a
-更正了对非Javasoft JVM的字符集支持（感谢很多指出该问题的人员）。
-更正了ResultSet.getBoolean()，使之能够识别作为布尔标志的“y”和“n”，以及“1”和“0”。（感谢Tim Pizey）。
-更正了ResultSet.getTimestamp()，以提供更好的性能。（感谢Richard Swift）。
- 更正了getByte()在处理数值类型方面的问题。（感谢Ray Bellis）。
- 更正了DatabaseMetaData.getTypeInfo()在处理DATE类型时存在的问题。（感谢Paul Johnston）。
-更正了用于“fn”调用的EscapeProcessor。（感谢locomotive.org的Piyush Shah）。
-更正了EscapeProcessor，如果没有转义代码，不执行额外操作。（感谢Ryan Gustafson）。
-更正了驱动程序，使之能解析“jdbc:mysql://host:port”形式的URL（感谢Richard Lobb）。
03-24-99：版本1.1i
-更正了关于PreparedStatements的Timestamps问题。
-更正了RSMD和RS中的Null指针异常。
-对于有效的类文件，与jikes一起进行了再编译（感谢ms!）。
03-08-99：版本1.1h
-更正了转义处理器，以处理不匹配的“{”和“}”（感谢Craig Coles）。-更正了转义处理器，以创建移植性更好的（在DATETIME和TIMESTAMP类型间）表达式，以便能与BETWEEN子句一起使用。（感谢Craig Longman。
- MysqlIO.quit()现在能关闭套接字连接。在此之前，多次连接失败后，某些操作系统将耗尽文件描述符。（感谢Michael Brinkman）。
-更正了Driver.getPropertyInfo中的NullPointerException（感谢Dave Potts）。
-修正了MysqlDefs，允许字字符串形式检索所有的*text字段。（感谢Chris at Leverage）。
-更正了PreparedStatement中的setDouble，使之能用于处理大数字，防止将科学记数法发送到数据库。（感谢J.S. Ferguson）。
-更正了RSMD中的getScale()和getPrecision()。（由James Klicman贡献）。
-更正了字段为DECIMAL或NUMERIC时的getObject()（感谢Bert Hobbs）。
-传递Null表名时，DBMD.getTables()出现严重故障。已更正（感谢Richard Lobb）。
-增加了在连接过程中对“client not authorized”（客户端未被授权）错误的检查。（感谢Hannes Wallnoefer）。
02-19-99：版本1.1g
-结果集行现在是字节数组。Blob和Unicode现在能双向工作。目前实施了useUnicode和编码选项。
-修正了PreparedStatement，使用setXXXStream（不改变地发送）将二进制集合发送到MySQL服务器。
-修正了getDriverPropertyInfo()。
12-31-98：版本1.1f
-将所有的结果集字段更改为字符串，这样，应能使Unicode工作，但你的JVM必须能够在字符集间进行转换。它还能使对服务器的数据读取更快，原因在于，现在不存在从StringBuffer到String（字符串）的转换。
-更改了PreparedStatement.streamToString()，使之更有效（代码由Uwe Schaefer提供）。
- URL解析功能更可靠（对于错误，抛出SQL异常，而不是NullPointerExceptions）。
- PreparedStatement现在能通过setObject()将String转换为Time/Date值（代码由Robert Currey提供）。
-在Buffer.readInt()中，IO进程不再被挂起，该缺陷是在1.1d中当将结果集更改为全字节数组时引入的。（由Samo Login指出）。
11-03-98：版本1.1b
-修正了DatabaseMetaData，允许IBM VA和J-Builder同时工作。请告诉我它的工作机制。（感谢Jac Kersing）。
-修正了ResultSet.getBoolean()在处理NULL字符串方面的问题（感谢Barry Lagerweij）。
-开始代码整理，并进行了格式处理。开始将其分出为并行的JDBC-2.0源树。
-为MysqlIO和Buffer内的关键部分增加了“最终”限定符，允许编译器采用内联方法以提高速度。
9-29-98
-如果传递给PreparedStatement中setXXX()的对象引用是空的，将自动调用setNull()。（感谢Erik Ostrom给出的提议）。
-对于Types.OTHER对象和未知类型对象，PreparedStatement中的setObject()现在会尝试将对象的串行化表示写入到数据库。
- Util现在有了1个静态方法readObject()，结果集和列索引将以上述方式在此例示序列化的对象。
9-02-98 – 版本1.1
-消除了MysqlIO.nextRow()中的“丑陋缺陷”。更正了Buffer.isLastDataPacket()，而不是获取异常。
- Connection.getCatalog()和Connection.setCatalog()现在能够工作。
- Statement.setMaxRows()能够正常工作，也能使用属性maxRows进行设置。通过属性或URL参数，Statement.setMaxRows()能覆盖maxRows设置。
-提供了自动再连接功能。由于在每次查询前不得不Ping数据库，在默认情况下，它将被关闭。要想使用该功能，请在连接URL中传递“autoReconnect=true”。通过“maxReconnects=n”（默认为3）和“initialTimeout=n”（默认为2秒）参数，你也可以更改再连接尝试的次数和初始超时值。Timeout是超时的指数补偿类型。例如，如果初始超时设置为2秒，maxReconnects为3，那么再连接尝试之间的间隔分别是2秒，4秒和16秒。
8-24-98：版本1.0
- 更正了Buffer.java中Blob数据的处理功能。
-更正了与尺寸过小的鉴定信息包有关的缺陷。
-JDBC驱动程序现在采用LPGL。
8-14-98 -
- 更正了 Buffer.readLenString()，使之能正确读取BLOB数据。
-更正了PreparedStatement.stringToStream，使之能正确读取BLOB数据。
-更正了PreparedStatement.setDate()，使之不增加1天。（感谢Vincent Partington在上述修正项方面的贡献）。
-增加了URL参数解析功能（?user=...等等）。
8-04-98：版本0.9d
- 重大新闻！ 新的软件包名。ICE工程公司的Tim Endres着手为GNU GPL的Java软件建立新的源树。他友好地将org.gjt.mm软件包目录提供给我，因此，现在驱动程序在org.gjt.mm.mysql软件包中。目前我是合法用户。期待Tim项目的更多信息。
-现在采用了动态确定大小的信息包，向数据库发送命令时，能够减少内存使用。
-对getTypeInfo()的参数等方面进行了小的修正。
- DatabaseMetaData现已完全实现。如果这些驱动程序能与各种IDE一起工作，请告知。我已听说它们正与Jbuilder一起使用。
-在软件包中增加了JavaDoc文档。
-软件包采用.zip或.tar.gz格式提供。
7-28-98：版本0.9
-实现了getTypeInfo()。根据JDBC规范，Connection.rollback()现在能抛出SQLException。
-增加了PreparedStatement，它支持预处理语句的所有JDBC API方法，包括InputStreams。请检查该点，如有问题，请告知。
-更正了ResultSet中的1个缺陷，该缺陷会破坏仅返回1行的某些查询。
- 更正了DatabaseMetaData.getTables()、DatabaseMetaData.getColumns()和DatabaseMetaData.getCatalogs()中存在的缺陷。
-增加了语句的功能，允许executeUpdate()保存由AUTO_INCREMENT字段自动生成的ID值。一般而言，执行executeUpdate()后，将查找SQLWarnings以了解警告信息，如LAST_INSERTED_ID = 'some number'，COMMAND = 'your SQL query'。
如果在表中正使用AUTO_INCREMENT字段，并在一条语句上执行了多个executeUpdate()，务必每次都执行clearWarnings()以节省内存。
7-06-98：版本0.8
-将MysqlIO和Buffer分离为单独类。对于这两个类中的某些字段，一些ClassLoader（类加载器）会给出IllegalAccess（非法访问）错误。现在，mm.mysql能够在小应用程序和所有类加载器中正常工作。
感谢Joe Ennis jce@mail.boone.com指出该问题，并与我一起进行了修正。
7-01-98：版本0.7
-更正了getColumns()中的DatabaseMetadata problems，并更正了字段构造函数内开关语句中存在的缺陷。
感谢Costin Manolache costin@tdiinc.com指出了它们。
5-21-98：版本0.6
-在MysqlIO.java和ResultSet.java中，结合Richard Swift Richard.Swift@kanatek.ca给出的有效变更内容。
-现在，我们的驱动程序比GWE的驱动程序快15％。
- 开始着手处理DatabaseMetaData。
实现了下述方法：
* getTables()
* getTableTypes()
* getColumns
* getCatalogs()