Php文档 Php问答行业资讯 Php论坛 Php手册 Php博客

游戏榜单

软件榜单

关闭导航

热搜榜

热门下载

热门标签

关闭搜索

php爱好者> php文档>JDBC优化策略总结

JDBC优化策略总结

时间：2010-04-12 来源：bdqnxindongfang

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文来自“北大青鸟济南新东方(山东大学)校区”网站 http://www.0531accp.com 原文链接：http://www.0531accp.com/zxzx/show___id=365.html

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

　　1、选择纯Java的JDBC驱动。

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

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

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

　　4、重用Statement--对于一些预定义SQL，设置为静态常量，并尽可能重用预定义SQL产生的PreparedStatement对象。对于多次使用一种模式的SQL，使用预定义SQL可以获取更好的性能。

　　5、使用批处理SQL。

　　6、优化结果集ResultSet--查询时候，返回的结果集有不同的类型，优先选择只读结果集、不可滚动的属性。

　　这里是很容易出现问题的地方：

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

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

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

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

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

本文来自“北大青鸟济南新东方(山东大学)校区”网站 http://www.0531accp.com　
原文链接：http://www.0531accp.com/zxzx/show___id=365.html