JDBC优化策略总结

相比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　对象的类型。