现在几乎所有的应用系统都无法避免使用数据库系统。在JAVA世界里访问数据库是一件非常轻松的事情，JDBC为JAVA应用程序访问数据库提供了一个统一的接口，通过使用JDBC接口开发者无需关心系统最终采用哪种数据库，因为JDBC仅仅是定义了访问几个JAVA的接口类，具体的实现是由数据库厂商提供的，这种做法其实与其他数据库连接方式例如ODBC是类似的。但是在实际的应用过程中，开发者发现离JDBC设计的初衷还是有一定距离，就比如说在存储字符串时的编码问题，我想很多开发者都会遇见这个问题，倒不是因为说解决它有什么技术方面的难度，而是它的的确确非常繁琐。我们必须在每次写入或者读出字符串的时候进行编码和反编码处理；或者说我们可以写一个方法可以进行编码处理的，但又必须在每次数据库操作的时候调用，虽然调用很简单，可是我非得这样吗？要是忘了编码那又要DEBUG了。当然你可能觉得这并没有什么，或者你可能很勤快，喜欢写大量重复的代码，可是你难道没有觉得这种繁琐的工作正在浪费你过于宝贵的青春吗？停止你的键盘输入，让我们来解决这个问题吧！

　　解决思路

　　在传统的应用程序中数据库操作部分我们可以想象成两层，如图所示：一个是数据库的"连接池"，另外一个业务数据操作层。在这里数据库的连接池是广义的，你可以把JDBC中的DriverManager也当成是连接池，具体的意思就是我们可以通过这层来获取到指定数据库的连接而不去关心它是怎么获取的。如果这个时候数据库系统（有如Informix，SQL Server）要求对字符串进行转码才能存储（例如最常见的GBK->ISO8859_1转码），那我们就必须在业务数据操作层来进行，这样有多少业务数据操作我们就要做多少编码转码的工作，太麻烦了，代码中充斥中大量重复的内容。本文提出的解决方案就是利用对获取到的数据库连接实例进行二次封装，也就是在数据库连接池与业务数据操作层之间加入了连接封装层，当然了，我们也完全可以直接将连接封装集成到数据库连接池内部。关于连接池的实现请参照我的另外一篇文章《使用JAVA动态代理实现数据库连接池》

图一

　　我们知道进行编码和转码工作都是集中在JDBC的两个接口PreparedStatement和ResultSet上进行的，主要涉及PreparedStatement的setString方法以及ResultSet的getString方法。前面我们讲过需要加入一个连接封装层来对数据库连接实例进行二次封装，但是怎么通过这个封装来改变PreparedStatement和ResultSet这两个接口的行为呢？这个问题其实也很简单，因为PreparedStatement接口必须通过Connection接口来获取实例，而ResultSet接口又必须从Statement或者PreparedStatement接口来获取实例，有了这样的级联关系，问题也就迎刃而解了。还是利用我在文章《使用JAVA动态代理实现数据库连接池》中使用的动态接口代理技术。首先我们设计Connection接口的代理类_Connection，这个代理类接管了Connection接口中所有可能获取到Statement或者PreparedStatement接口实例的方法，例如：prepareStatement和createStatement。改变这两个方法使之返回的是经过接管后的Statement或者PreparedStatement实例。通过对于Statement接口也有相应的代理类_Statement，这个代理类接管用于获取ResultSet接口实例的所有方法，包括对setString方法的接管以决定是否对字符串进行编码处理。对于接口ResultSet的接管类_ResultSet就相应的比较简单，它只需要处理getString方法即可。

　　关键代码

　　前面我们大概介绍了这个解决方案的思路，下面我们给出关键的实现代码包括Connection的代理类，Statement的代理类，ResultSet的代理类。这些代码是在原来关于数据库连接池实现的基础上进行扩充使之增加对自动编码处理的功能。有需要源码打包的可以通过电子邮件跟我联系。

_Connection.java

/*
 * Created on 2003-10-23 by Liudong
 */
package lius.pool;
import java.sql.*;
import java.lang.reflect.*;

/*
 *
 * 数据库连接的代理类
 * @author Liudong
 */
 class _Connection implements InvocationHandler{
 private Connection conn = null;
 private boolean coding = false;
 //指定是否进行字符串转码操作
 _Connection(Connection conn, boolean coding){
  this.conn = conn;
  this.coding = coding;
  initConnectionParam(this.conn);
 
 }
 
 /** 
  * Returns the conn. 
  * @return Connection 
  */
 
 public Connection getConnection() {
  Class[] interfaces = conn.getClass().getInterfaces();
  if(interfaces==null||interfaces.length==0){
   interfaces = new Class[1];
   interfaces[0] = Connection.class;
  
  }
 
  Connection conn2 = (Connection)Proxy.newProxyInstance( conn.getClass().getClassLoader(), interfaces,this);
  return conn2;
 
 }
 
 /** 
  * @see java.lang.reflect.InvocationHandler#invoke 
  */
 public Object invoke(Object proxy, Method m, Object[] args) throws Throwable { 
  String method = m.getName();
  //调用相应的操作
  Object obj = null;
  try{
   obj = m.invoke(conn, args);
   //接管用于获取语句句柄实例的方法
   if((CS.equals(method)||PS.equals(method))&&coding)
    return new _Statement((Statement)obj,true).getStatement();
  
  } catch(InvocationTargetException e) {
   throw e.getTargetException();
  }
  return obj;
 }
 
 private final static String PS = "prepareStatement";
 private final static String CS = "createStatement";
}

_Statement.java

/*
 * Created on 2003-10-23 by Liudong
 */
 
package lius.pool;
import java.sql.*;
import java.lang.reflect.*;

/**
 * 数据库语句对象实例的代理类
 * @author Liudong
 */
class _Statement implements InvocationHandler{ 
 private Statement statement ; //保存所接管对象的实例 
 private boolean decode = false; //指定是否进行字符串转码 

 public _Statement(Statement stmt,boolean decode) { 
  this.statement = stmt;
  this.decode = decode;
 }
 
 /** 
  * 获取一个接管后的对象实例 
  * @return 
  */
 public Statement getStatement() {
  Class[] interfaces = statement.getClass().getInterfaces();
  if(interfaces==null||interfaces.length==0){ 
   interfaces = new Class[1];
   interfaces[0] = Statement.class;
  } 
  Statement stmt = (Statement)Proxy.newProxyInstance(   
   statement.getClass().getClassLoader(), 
   interfaces,this);
  return stmt;
 
 }
 
 /** 
  * 方法接管 
  */
 public Object invoke(Object proxy, Method m, Object[] args) throws Throwable {
  String method = m.getName(); //接管setString方法 
  if(decode && SETSTRING.equals(method)) {
   try{
    String param = (String)args[1];
    if(param!=null)
     param = new String(param.getBytes(),"8859_1");
    return m.invoke(statement,new Object[]{args[0],param});
   } catch(InvocationTargetException e){
    throw e.getTargetException();
        
   }  
  }
  
  //接管executeQuery方法
  
  if(decode && EXECUTEQUERY.equals(method)){
   try{
    ResultSet rs = (ResultSet)m.invoke(statement,args);
    return new _ResultSet(rs,decode).getResultSet();
   
   }catch(InvocationTargetException e){
    throw e.getTargetException();
    }  
  }
  
  try{
   return m.invoke(statement, args);
  } catch(InvocationTargetException e) {
   throw e.getTargetException();
   } 
 }
 //两个要接管的方法名
 
 private final static String SETSTRING = "setString";
 private final static String EXECUTEQUERY = "executeQuery";
}

_ResultSet.java

/*
 * Created on 2003-10-23 by Liudong
 */
 
package lius.pool;
import java.sql.ResultSet;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

/**
 * 数据库结果集的代理类
 * @author Liudong
 */
 class _ResultSet implements InvocationHandler{ 
 private ResultSet rs = null;
 private boolean decode = false;
 
 public _ResultSet(ResultSet rs,boolean decode) {
  this.rs = rs;
  this.decode = decode;
 }
 
 public ResultSet getResultSet(){ 
  Class[] interfaces = rs.getClass().getInterfaces();
  if(interfaces==null||interfaces.length==0){
   interfaces = new Class[1];
   interfaces[0] = ResultSet.class;  
  }
 
  ResultSet rs2 = (ResultSet)Proxy.newProxyInstance(rs.getClass().getClassLoader(),interfaces,this);
  return rs2;
 
 }

 /** 
  * 结果getString方法 
  */
 public Object invoke(Object proxy, Method m, Object[] args) throws Throwable { 
  String method = m.getName();
  if(decode && GETSTRING.equals(method)){
   try{
    String result = (String)m.invoke(rs,args);
    if(result!=null)     
     return new String(result.getBytes("8859_1"));
    return null;
   
   }catch(InvocationTargetException e){
    throw e.getTargetException();
    }
   
  } 
  
  try{
   return m.invoke(rs, args);
  }catch(InvocationTargetException e){
   throw e.getTargetException();
  }
 }
 
 private final static String GETSTRING = "getString";

}

　　现在我们已经把三个接口的代理类做好了，下一步就是怎么来使用这三个类。其实对于使用者来讲并不需要关心三个类，只需要了解_Connection就可以了，因为另外两个是_Connection直接调用的。为了使用_Connection我们必须传入两个参数，第一个是数据库实际的数据库连接实例，另外一个是布尔值代表是否进行转码处理。我们必须先通过实际的情况获取到数据库连接后再传入_Connection的构造函数作为参数，下面例子告诉你如何来使用_Connection这个类：

　　Connection conn = getConnection(); //获取数据库连接
　　boolean coding = false; //从配置或者其他地方读取是否进行转码的配置 
　　//接管数据库连接实例 
　　_Connection _conn = new _Connection(conn,coding);
　　//获得接管后的数据库连接实例，以后直接使用conn2而不是conn 
　　Connection conn2 = _conn.getConnection();

　　因为对一个应用系统来讲，数据库连接的获取必然有统一的方法，在这个方法中加入对连接的接管就可以一劳永逸的解决数据库的编码问题。

　　性能比较

　　功能没有问题了，开发者接下来就会关心性能的问题，因为在进行一些对响应速度要求很高或者大数据量的处理情况下性能就成为一个非常突出的问题。由于JAVA中的动态接口代理采用的是反射（Reflection）机制，同时又加入我们自己的一些代码例如方法名判断，字符串转码等操作因此在性能上肯定比不上直接使用没有经过接管的数据库连接。但是这点性能上的差别是不是我们可以忍受的呢，为此我做了一个试验对二者进行了比较：

　　测试环境简单描述：

　　使用ACCESS数据库，建两张结构一样的表，计算从获取连接后到插入数据完毕后的时间差，两个程序（直连数据库和使用连接接管）都进行的字符串的转码操作。

　　测试结果：

　　从上面这张测试结果表中来看，二者的性能的差别非常小，尽管在两万条数据的批量插入的时候时间差别也不会多于一秒钟，这样的结果应该说还是令人满意的，毕竟为了程序良好的结构有时候牺牲一点点性能还是值得的。

　　本文算是我之前文章《使用JAVA动态代理实现数据库连接池》中提出的数据库连接池实现的进一步完善，同样使用动态接口代理的技术来解决数据库编码的问题。JAVA的这个高级技术可以用来解决许多实际中非常棘手的问题，就像本文提到的编码问题的处理以及数据库连接池的实现，同时在WEB开发框架的实现上也有非常大的作为。欢迎对这方面感兴趣的朋友来信共同来研究。

from: http://www.javafan.net/article/20041212111952983.html

JAVA的中文问题比较突出，主要表现在控制面板输出，JSP页面输出和数据库访问上。本文尽量避开字体问题，而只谈编码。通过本文，你可以了解JAVA中文问题的由来，问题的解决方法，其中提了一下用JDBC访问数据库的方法。

二、问题描述：

1）在中文W2000中文窗口编译和运行，用的是国际版的JDK，连接的是中文W2000下的Cp936编码的SQL SERVER数据库：

J:\exercise\demo\encode\HelloWorld>make

Created by XCompiler. PhiloSoft All Rights Reserved.

Wed May 30 02:54:45 CST 2001

J:\exercise\demo\encode\HelloWorld>run

Created by XRunner. PhiloSoft All Rights Reserved.

Wed May 30 02:51:33 CST 2001

中文

[B@7bc8b569

[B@7b08b569

[B@7860b569

中文

中文

????

中文

中文

????

??

??

??

2）如果在中文W2000的西文窗口（编码为437）下编译，用JAVA运行则由于无字体而无法正常显示，如果象上面一样在中文W2000的中文窗口运行，输出为：

J:\exercise\demo\encode\HelloWorld>run

Created by XRunner. PhiloSoft All Rights Reserved.

Wed May 30 02:51:33 CST 2001

????

[B@7bc0b66a

[B@7b04b66a

[B@7818b66a

????

????

????

????

????

????

中文

中文

????

三）分析

1）出现有乱码（也就是？）。由于只出现？而没出现小方框，说明只是编码有问题，而不是字体问题。 在编码中，如果从一种字符集转换到别一种字符集，比较典型的是从GB2312转换到ISO8859_1（即ASCII），那么很多汉字（半个汉字）是无法映射到西文字符中去的，在这种情形下，系统就把这些字符用？代替。同样，也存在小字符集无法到大字符集的情况，具体原因这里就不详谈了。

2）出现了中文环境编译，中文环境运行时汉字显示有正确也有不正确的地方，同样，在西文环境下编译，在中文环境下运行时也出现类似情况。这是由于自动（默认）或手工（也就new String(bytes[,encode])和bytes getBytes([encode])）转码的结果。

2.1）在JAVA源文件-->JAVAC-->Class-->Java-->getBytes()-->new String()-->显示的过程中，每一步都有编码的转换过程，这个过程总是存在的，只是有的时候用默认的参数进行。下面我们一步一步分析为什么出现上面的情形。

2.2）这里是源代码：

HelloWorld.java:

------------------------

public class HelloWorld

{

public static void main(String[] argv){

try{

System.out.println("中文");//1

System.out.println("中文".getBytes());//2

System.out.println("中文".getBytes("GB2312"));//3

System.out.println("中文".getBytes("ISO8859_1"));//4

System.out.println(new String("中文".getBytes()));//5

System.out.println(new String("中文".getBytes(),"GB2312"));//6

System.out.println(new String("中文".getBytes(),"ISO8859_1"));//7

System.out.println(new String("中文".getBytes("GB2312")));//8

System.out.println(new String("中文".getBytes("GB2312"),"GB2312"));//9

System.out.println(new

String("中文".getBytes("GB2312"),"ISO8859_1"));//10

System.out.println(new String("中文".getBytes("ISO8859_1")));//11

System.out.println(new

String("中文".getBytes("ISO8859_1"),"GB2312"));//12

System.out.println(new

String("中文".getBytes("ISO8859_1"),"ISO8859_1"));//13

}

catch(Exception e){

e.printStackTrace();

}

}

}

为了方便起见，在每个转换的后面加了操作序号，分别为1,2,...,13。

2.3）需要说明的是，JAVAC是以系统默认编码读入源文件，然后按UNICODE进行编码的。在JAVA运行的时候，JAVA也是采用UNICODE编码的，并且默认输入和输出的都是操作系统的默认编码，也就是说在new String(bytes[,encode])中，系统认为输入的是编码为encode的字节流，换句话说，如果按encode来翻译bytes才能得到正确的结果，这个结果最后要在JAVA中保存，它还是要从这个encode转换成Unicode，也就是说有bytes-->encode字符-->Unicode字符的转换；而在String.getBytes([encode])中，系统要做一个Unicode字符-->encode字符-->bytes的转换。

在这个例子中，除那个英文窗口编码的时候除外，其实情形下默认编码都是GBK（在本例中，我们暂且把GBK和GB2312等同看待）。

2.4）由于在未指明在上面的两个用代码实现的转换中，如果未指定encode，系统将采用默认的编码（这里为GBK），我们认为上面的5,6,7和8,9,10是一样的，8和9、11和12也是一样的，所以我们在讨论中将只讨论1,9,10,12,13。其中的2,3,4只是用于测试，不在我们的讨论范围之内。

2.5）下面我们来跟踪程序中的“中”字的转换历程，我们先说在中文窗口下作的编译和运行过程，注意在下面的字母下标中，我有意识地使用了一些数字，以表示相同，相异还是相关2.5.1)我们先以上面的13个代码段中的的代码9为例：

步骤 内容 地点 说明

01： C1 HelloWorld.java C1泛指一个GBK字符

02： U1 JAVAC读取 U1泛指一个Unicode字符

03： C1 getBytes()第一步 JAVA先和操作系统交流

04： B1,B2 getBytes()第二步 然后返回字节数组

05： C1 new String()第一步 JAVA先和操作系统交流

06： U1 new String()第二步 然后返回字符

07： C1 println(String) 能显示“中”字，内容和原来的相同

2.5.2）然后再以代码段10为例，我们注意到只是：

步骤 内容 地点 说明

01： C1 HelloWorld.java C1泛指一个GBK字符

02： U1 JAVAC读取 U1泛指一个Unicode字符

03： C1 getBytes()第一步 JAVA先和操作系统交流

04： B1,B2 getBytes()第二步 然后返回字节数组

05： C3,C4 new String()第一步 JAVA先和操作系统交流，这时解析错误

06： U5,U6 new String()第二步 然后返回字符

07： C3,C4 println(String) 由于中字给分成了两半，在ISO8859_1中刚好也没有字符

能映射上，所以显示为“??”。在上面的示例中，

“中文”两个字就显示为“？？？？”

2.5.3）在完全中文模式下的其它情形类似，我就不多说了

2.6）我们接着看为什么在西文DOS窗口下编译出来的类在中文窗口下也出现类似情形，特别是为什么居然有的情形下还能正确显示汉字。

2.6.1）我们还是先以代码段9为例：

步骤 内容 地点 说明

01： C1C2 HelloWorld.java C1C2分别泛指一个ISO8859_1字符，“中”字被拆开

02： U3U4 JAVAC读取 U1U2泛指一个Unicode字符

03： C5C6 getBytes()第一步 JAVA先和操作系统交流，这时解析错误

04： B5B6B7B8 getBytes()第二步 然后返回字节数组

05： C5C6 new String()第一步 JAVA先和操作系统交流

06： U3U4 new String()第二步 然后返回字符

07： C5C6 println(String) 虽然同是两个字符，但已不是最初的“两个ISO8859_1字

符”，而是“两个BGK字符”，“中”显示成了“？？”

而“中文”就显示成了“？？？？”

2.6.2）下面我们以代码段12为例，因为它能正确显示汉字

步骤 内容 地点 说明

01： C1C2 HelloWorld.java C1C2分别泛指一个ISO8859_1字符，“中”字被拆开

02： U3U4 JAVAC读取 U1U2泛指一个Unicode字符

03： C1C2 getBytes()第一步 JAVA先和操作系统交流（注意还是正确的哦！）

04： B5B6 getBytes()第二步 然后返回字节数组（这是很关键的一步！）

05： C12 new String()第一步 JAVA先和操作系统交流（这是更关键的一步，JAVA已经知道B5B6要解析成一个汉字！）

06： U7 new String()第二步 然后返回字符（真是一个项两！U7包含了U3U4的信息）

07： C12 println(String) 这就原来的“中”字，很委屈被JAVAC冤枉了一回，不过被程序员拨乱反正了一下！当然，“中文”两个字都能正确显示了！

3）那为什么有的时候用JDBC的

new String(Recordset.getBytes(int)[,encode])

Recordset.getSting(int)

Recordset.setBytes(String.getBytes([encode]))

和

Recordset.setString(String)

的时候会出现乱码了呢？

其实问题就出现在编写JDBC的的也考虑了编码问题，它从数据库读取数据后，可能自作主张做了一个从GB2312（默认编码）到Unicode的转换，我的这个WebLogic For SQL Server的JDBC Driver就是这样的，当我读字串的时候，发出读到的不是正确的汉字，可恨的是我却可以直接写汉字字串，这让人多少有点难以接受！

也就是说，我们不得不在读或写的时候进行转码，尽管这个转码有的时候不是那么明显，这是因为我们使用了默认的编码进行转码。JDBC Driver所做的操作，我们只有进入到源代码内部才能清楚，不是吗？

from: http://java.ccidnet.com/art/3737/20060605/571079_1.html

(4)如果是通过"a.jsp?param=中文"传递参数,则需要:
     a.在传参数之前先把参数进行转码:java.net.URLEncoder.encode(param);
       取值用java.net.URLDncoder.decode(param);再转回中文
     b.在你的Tomcat目录-->conf目录-->server.xml里找出这段:
       <Connector
         port="8080"               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" redirectPort="8443" acceptCount="100"
               debug="0" connectionTimeout="20000"
               disableUploadTimeout="true" <!--在里边加上这个参数-->URIEncoding="gb2312"/>

from: http://www.yuanma.org/data/2006/0911/article_1503.htm

l         为应用选择最好最快的 JDBC 驱动 ,参考本站文章 。 JDBC3.0提供了新的特性来提高性能，诸如连接池， statemente池的改进  

l        对数据库使用连接池并且重用连接，而不要重复打开和关闭连接。最佳的连接池大小是当连接池大到足够使服务请求不等待

l         尽量使用支持 JDBC3.0 的驱动，因为 JDBC3.0 支持包括 DataSource 对象，连接池，分布式事务支持， RowSets 和 prepared statement 池等性能增强特性

l         Prepared statement 池（自从 JDBC3.0 开始有）高速缓存已经预先优化并运行了的 SQL 查询，这样，他们被再次请求的时候，不必经历再次的优化预处理（避免最优化步骤，诸如检查语法，验证地址，优化访问路径和执行计划）。 Statement 池是一个很好的，重要的性能优化方法

l         JDBC3.0 中的 Statement 池和连接池能合作共享 statement 池，这样，能使用一个已高速缓存的 statement （该 statement 来自另外一个连接）的连接，在由任一连接执行的 一些SQL 首次被执行时，产生的 statement 准备开销仅一次

l         RowSet对象与 ResultSet 对象相似，但是能提供当断开连接的时候对数据库数据的访问。这允许数据以它最简单的形式被高效的高速缓存

l         用同一个连接执行多个 statements

l         关闭 autocommit ，但不要让事务打开太久

l         避免将事务分布开（事务跨越多个连接）

l         最小化数据库的行和列数据获取。使用 setMaxRows, setMaxFieldSize,和 SetFetchSize

l         使用最高效的数据类型：字符串比整数型快，整数型比浮点类型和时间戳类型都要高效（是否不太理解^&^，这是针对DB2数据库处理来说的，处理character类型最快，而处理integer类型通常需要一些转换或者字节排序）

l         使用 updateXXX()方法更新： updateXXX() 在可更新的结果集上调用。结果集已经定位到了一行 , 因此当使用一个 UPDATE statement 时，可以消除通常的查找要更新的数据行的开销

l         Cache任何请求的元数据（ metadata ）并尽可能少的使用元数据 方法，其慢的程度一用便知

l         避免在元数据 查询中使用 null 参数

l         使用虚拟查询获得一行的元数据，不要使用getcolumns()（假如应用允许用户使用列数据，应用是使用getColumns来返回列的信息给用户还是准备一个虚拟查询而后调用getMetadata呢？

l         使用存储过程，避免多余的网络传输

l         在存储过程中使用参量，不要将数据挨个地放在statement中，最小化解析开销。此条针对DB2来说，其它数据库未必适用。SQL总是以字符串形式发送给DB2数据库，例如：
CallableStatement cstmt = conn.prepareCall ("call getCustName (12345)");
ResultSet rs = cstmt.executeQuery ();
DB2服务器必须解析该SQL，验证参量类型，并将参量转化为正确的数据类型。

l         对需要重复执行的statement使用预处理statement（PreparedStatement）

l         选择使用最佳游标：对连续读取使用游标；对双向滚动使用游标。对仅返回一行的查询避免使用游标。

l         在JVM中Cache频繁请求的数据，避免不必要的数据库请求

l         采用预读取机制， 批量取行，而不要一次一行 。调整批大小和预取行的数量。避免使用预取 BLOB 数据。

l         除非绝对需要，否则避免移动数据

l         在数据穿过网络之前要使流化数据（ Streamline data ）

l         避免每次处理一行，尽可能一起处理多行。

l         在表中统计个数（例如：使用 select count(*) from myTable,yourTable where …）属于资源密集型的。试试首先选入临时表，仅返回该计数（count），然后发送精确的二次查询获得临时表中的行的子集。

l         恰当的使用 SQL 能减少资源请求。使用返回所需数据的最小值的查询：避免 select * 查询。一个返回小的数据子集的复杂查询，比一个简单的，返回超过所需的大量数据的简单查询更高效。

l         使你的查询尽可能精巧，例如：尽可能精确地最小化要传输的数据，使其是所需的子集

l         努力批量更新：将 statement 收集到一起，然后在一个事务里面一起执行。如果可能，使用有条件的逻辑和临时变量来达到 statement 批处理

l         永远不要让 DBMS 事务跨越用户输入

l         考虑使用乐观锁。乐观锁使用时间戳验证数据是否还没有被其他用户改变，否则事务失败

l         使用 恰当的更新，例如：更新行/表中已经存在的数据，而不要添加或者删除行/表。在适当的位置更新数据要比移动数据快得多，如果更新需要的空间比表设计能提供的更多，这可能是需要的。如果你设计的行需要空间初始化，更新将会更快。交易是你的表可能需要更多的磁盘空间，但可能速度更快。由于磁盘空间是便宜的，使用一点点能提高性能，这应该说是非常有价值的投资

l         分开存储正在操作的数据和历史数据（更一般的情况是将频繁使用的数据和不常使用的数据分开存储）

l         尽可能小的保留你的操作数据集，避免必须读那些不相关的数据

l         DBMS可以很好的并行运转，尽量将应用设计成当和 DBMS交互时应用能做其他事情。

l         使用流水线操作和并行操作。 将应用设计成支持大量并行进程， 使应用运行更快。如果要处理多步，努力设计好应用，以使后来的步骤能够在任何优先的进程已经完成的数据部分上开始工作，而不是必须等到优先进程完成

l       事物的保护级别越高，性能损失就越大。事物级别按增长的顺序为： TRANSACTION_NONE, TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE。使用Connection.setTransactionIsolation() 设置你想要的事物级别

l      默认的自动提交模式由于使每一个数据库命令都成为一个单独的事务，这会严重影响性能，关闭自动提交（Connection.setAutoCommit(false) ），明确声明事务

l         通过整合多个事务为一个的批量操作，并在一个statement中使用Statement.addBatch() 和Statement.executeBatch()

l       Savepoints (from JDBC3.0)需要昂贵的资源。一旦不再需要，就立刻使用Connection.releaseSavepoint()释放掉Savepoints

l         ConnectionPoolDataSource (from JDBC3.0)和PooledConnection接口为连接池提供了built-in支持

l           使用setLogWriter() (from Driver, DataSource, or ConnectionPooledDataSource; from JDBC3.0) 帮助跟踪JDBC流

l           使用Connection.setReadOnly(true)优化只读数据库（操作）交互

l           使用Connection.nativeSQL()察看SQL查询如何在数据库种执行，帮助确保SQL已被优化

l          切记：一旦可能，立刻关闭Statement和ResultSet

l          使用DatabaseMetaData获得数据库功能性信息

l          一直捕捉和处理数据库警告和异常

l          使用最恰当的数据类型明确数据的类型，例如：以date类型存储日期，儿不要用varchar<