Java_JDBC优化策略

via: http://lavasoft.blog.51cto.com/62575/225828/

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

 

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

 

1、选择纯Java的JDBC驱动。

 

2、使用连接池--使用一个“池”来管理JDBC连接，并精心调试池配置的参数，目前可用的数据库连接池很多很多。

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

 

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

有时候在一个过程中，会多次操作数据库，而仅仅需要一个连接就够了，没必用一次就获取一个连接，用完后关闭或者入池。这样会增加“池”管理的成本，千万别以为你用了“池”就可以随便申请和归还连接，都是有代价的。如果是一个庞大循环块中操作数据库，更应该注意此问题！

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

 

4、重用Statement/PreparedStatement--对于一些预定义SQL，设置为静态常量，并尽可能重用预定义SQL产生的PreparedStatement对象。对于多次使用一种模式的SQL，使用预定义SQL可以获取更好的性能。对于Statement对象，可以反复的重用，每次都可以接收不同的SQL语句，而对于PreparedStatement则不可以，因为预定义SQL在定义PreparedStatement对象时候已经确定了，但是如果sql语句不变，则可以调用clearParameters()来达到从用目的，如果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 对象的类型。

 

说明下：

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

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

对于是否并发操作：如果不需要考虑线程安全，则选择忽略并发的结果集类型，否则选择并发安全的类型。

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

 

7、事物优化--如果数据库不支持事物，就不要写回滚代码，如果不考虑事物，就不要做事务的控制。

 

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

 

9、异常处理优化--不要轻易吞噬SQLException，对于DAO、Service层次的数据访问，一般在DAO中跑出异常，在Service中处理异常。但DAO中也可以处理异常，并做转义抛出，不要随便抛出RuntimeExeption，因为这是JVM抛出的，不需要你可以去抛出，因为RuntimeException往往会导致系统挂起。

 

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

 

 

via: http://java.chinaitlab.com/JDBCJDO/18044.html

 

如果可能，避免访问数据库

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　·　 在存储过程中使用参量，不要将数据挨个地放在statement中，最小化解析开销。此条针对DB2来说，其它数据库未必适用。SQL总是以字符串形式发送给DB2数据库，例如：

　　CallableStatement cstmt = conn.prepareCall ("call getCustName (12345)");

　　ResultSet rs = cstmt.executeQuery ();

　　DB2服务器必须解析该SQL，验证参量类型，并将参量转化为正确的数据类型。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　·使用可滚动ResultSet (JDBC 2.0)