JDBC优化策略总结

JDBC优化策略总结

 

相比Hibernate、iBatis、DBUtils等，理论上JDBC的性能都超过它们。JDBC提供更底层更精细的数据访问策略，这是Hibernate等框架所不具有的。

 

在一些高性能的数据操做中，越高级的框架越不适合使用。这里是我在开发中对JDBC使用过程当中一些优化经验总结。

 

一、选择纯Java的JDBC驱动。

 

二、使用链接池--使用一个“池”来管理JDBC链接，并精心调试池配置的参数，目前可用的数据库链接池不少不少。

如何配置合适的参数呢，须要的是测试，而不是感受。

 

三、重用Connection--最大限度使用每一个数据库链接，获得了就不要轻易“丢弃”。

有时候在一个过程当中，会屡次操做数据库，而仅仅须要一个链接就够了，没必用一次就获取一个链接，用完后关闭或者入池。这样会增长“池”管理的成本，千万别觉得你用了“池”就能够随便申请和归还链接，都是有代价的。若是是一个庞大循环块中操做数据库，更应该注意此问题！

除此以外，还应该对链接进行密集使用，尽量晚的打开，并可能早的关闭。好比，你一个业务中有N多的操做，数据库操做穿插在其中，而其余的业务处理操做时间很长，那么使用一个链接处理这些操做是有问题的。这会致使长期占用链接，给数据库带来压力。

 

四、重用Statement/PreparedStatement--对于一些预约义SQL，设置为静态常量，并尽量重用预约义SQL产生的PreparedStatement对象。对于屡次使用一种模式的SQL，使用预约义SQL能够获取更好的性能。对于Statement对象，能够反复的重用，每次均可以接收不一样的SQL语句，而对于PreparedStatement则不能够，由于预约义SQL在定义PreparedStatement对象时候已经肯定了，可是若是sql语句不变，则能够调用clearParameters()来达到从用目的，若是sql语句发生变化，也能够从用变量名。

 

五、使用批处理SQL。

 

六、优化结果集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 对象的类型。

 

说明下：

 

结果集分两种类型：只读和可更改，只读的话，更省内存，查询的结果集不能更改。若是结果集在查询后，更改了值又要保存，则使用可更改结果集。

 

结果集的游标也有两种类型：若是不必让游标自由滚动，则选择单方向移动的游标类型。

 

对因而否并发操做：若是不须要考虑线程安全，则选择忽略并发的结果集类型，不然选择并发安全的类型。

 

另外，还要控制结果的大小，几乎全部的数据库都有查询记录条数控制的策略，能够海量数据进行分批处理，一次一批，这样不至于把系统搞死。

 

七、事物优化--若是数据库不支持事物，就不要写回滚代码，若是不考虑事物，就不要作事务的控制。

 

八、安全优化--管理好你的Connection对象，在异常时候能“入池”或者关闭。所以应该将Connection释放的代码写在异常处理的finally块中。

 

九、异常处理优化--不要轻易吞噬SQLException，对于DAO、Service层次的数据访问，通常在DAO中跑出异常，在Service中处理异常。但DAO中也能够处理异常，并作转义抛出，不要随便抛出RuntimeExeption，由于这是JVM抛出的，不须要你能够去抛出，由于RuntimeException每每会致使系统挂起。

 

十、代码高层优化--在以上的基础上，优化封装你的数据访问方式，尽量让代码简洁好维护，若是你还以为性能不行，那就该从整个系统角度考虑优化了，好比加上缓存服务器，集群、负载均衡、优化数据库服务器等等，以获取更好的系能。