相比Hibernate、iBatis、DBUtils等，理论上JDBC的性能都超过它们。JDBC提供更底层更精细的数据访问策略，这是Hibernate等框架所不具备的。
在一些高性能的数据操作中，越高级的框架越不适合使用。这里是我在开发中对JDBC使用过程中一些优化经验总结。
1、选择纯Java的JDBC驱动。
2、使用连接池--使用一个“池”来管理JDBC连接，并精心调试池配置的参数，目前可用的数据库连接池很多很多。
如何配置合适的参数呢，需要的是测试，而不是感觉。
3、重用Connection--最大限度使用每个数据库连接，得到了就不要轻易“丢弃”。
有时候在一个过程中，会多次操作数据库，而仅仅需要一个连接就够了，没必用一次就获取一个连接，用完后关闭或者入池。这样会增加“池”管理的成本，千万别以为你用了“池”就可以随便申请和归还连接，都是有代价的。如果是一个庞大循环块中操作数据库，更应该注意此问题！
4、重用Statement--对于一些预定义SQL，设置为静态常量，并尽可能重用预定义SQL产生的PreparedStatement对象。对于多次使用一种模式的SQL，使用预定义SQL可以获取更好的性能。
5、使用批处理SQL。
6、优化结果集ResultSet--查询时候，返回的结果集有不同的类型，优先选择只读结果集、不可滚动的属性。
这里是很容易出现问题的地方：
java.sql.ResultSet
static int CLOSE_CURSORS_AT_COMMIT
该常量指示调用 Connection.commit 方法时应该关闭 ResultSet 对象。
static int CONCUR_READ_ONLY
该常量指示不可以更新的 ResultSet 对象的并发模式。
static int CONCUR_UPDATABLE
该常量指示可以更新的 ResultSet 对象的并发模式。
static int FETCH_FORWARD
该常量指示将按正向（即从第一个到最后一个）处理结果集中的行。
static int FETCH_REVERSE
该常量指示将按反向（即从最后一个到第一个）处理结果集中的行处理。
static int FETCH_UNKNOWN
该常量指示结果集中的行的处理顺序未知。
static int HOLD_CURSORS_OVER_COMMIT
该常量指示调用 Connection.commit 方法时不应关闭 ResultSet 对象。
static int TYPE_FORWARD_ONLY
该常量指示指针只能向前移动的 ResultSet 对象的类型。
static int TYPE_SCROLL_INSENSITIVE
该常量指示可滚动但通常不受其他的更改影响的 ResultSet 对象的类型。
static int TYPE_SCROLL_SENSITIVE
该常量指示可滚动并且通常受其他的更改影响的 ResultSet 对象的类型。
