JDBC性能优化方案

近期用到了利用JDBC查询Oracle数据库,但是查询效率不尽人意,研究了一下JDBC方面可以优化的地方,在这里跟大家分享一下。

1.设置最优的预取值

defaultRowPrefetch:预取条数默认值

defaultBatchValue:触发查询操作的批量请求值

这两个参数的默认值都是10,我们可以通过增加这两个参数值来减少数据库请求以提高查询效率,当然具体值大小要视具体情况而定。

2.通过连接池获取连接

创建连接的代价很大,通过连接池获取连接可省去创建连接时间。

3.选择合适的Statement接口(共有三种)

  • Statement:只支持静态sql
  • PreparedStatement:支持动态输入参数的sql, 因为其预编译的sql具有可重用性,可极大地避免Oracle对sql的(应解析和软解析)解析时间,提高查询速度
  • CallableStatement:专门针对存储过程,使用它能享受到所有存储过程带来的优势,但也包括存储过程带来的劣势如Java程序可移植性查,依赖数据库等

 4.设置检索时的批量值

Statement.getFetchSize();  
获取一次检索的批量值

Statement.setFetchSize(30); 设置批量值

传统情况下,设置FetchSize值对检索大数据表时性能的提升是很明显的,原因是jdbc驱动默认每次只检索10条记录(传到客户端的应该是一个游标),如果我们要检索100条数据,那么就需要客户端和服务器端进行10次网络往返才能全部传输完毕,每次网络间传输都会耗掉一些时间,比如采用TCP/IP协议的话,要建立连接握手及额外的协议头尾开销等,这样势必会影响客户端的响应。至于JDBC为何要设计这么小的数,有人说是为了避免jvm
out of memory 问题。

具体性能能提高多少,请参考:http://blog.lishman.com/2008/03/jdbc-fetch-size.html

当然,FetchSize并不是越大越好,至于原因请参考:http://stackoverflow.com/questions/9220171/setting-oracle-size-of-row-fetches-higher-makes-my-app-slower

 5.设置ResultSet的批量值

ResultSet.getFetchSize(); 获取默认批量值

ResultSet.setFetchSize(50); 设置批量值

处理大数据时可显著提高处理速度

6.设置ResultSet合适的处理方向

ResultSet.getFetchDirection(); 获取默认值

ResultSet.setFetchDirection(FETCH_REVERSE);设置合适的值

  7.从ResultSet获取数据时有两种方式, rs.getObject(int column_index) 和 rs.getObject(String column_label)

  • rs.getObject(int column_index):这种方式直接根据索引从rs对象中取出 ,最快
  • rs.getObject(String column_label) :
    这种方式需要先通过label获取到索引,然后再根据索引取数据,比直接利用索引多走了一步

8.合理的使用ResultSet的getXXX()方法

ResultSet提供了很多各式各样的getxxx() 方法,比如你知道第一个值是String类型的话,那么就写成getString(1),如果你不指示明确的话,它会则需要把这个值再转换成合适的Java类型,转换的代价是比较大的,如果检索出来的数据有一百万条的话,那么这个字段值就会被转换一百万次。

 9.优化查询SQL

比如避免使用select * from table where condition...,因为这么做会把所有的数据项目查询出来,比如我们只需要Salary的话,我们就写成select salary from employee where name=RR,避免不必要数据的检索。

 10.Cache只读(read-only)和主读(read-mostly)表的数据

只读表的数据不会发生变化,主读表发生变化较少,如果每次请求都读一遍表的话显然是没有必要,因此可以把这些数据缓存起来。当然,对于主读表要设定一定的更新时间。

11.迭代分批次获取数据替代一次大批量获取数据

某些情况下,应用程序可能会通过JDBC一次请求大量数据,而应用程序可能会一次把所有数据返回给客户端,这样会用掉很多时间,可以采取如下方式解决:

  • 在Server端缓存数据,分批次发给Client端,比如Server端查询出1000条数据,可以分10批次每次传送100条给Client端
  • 不在Server端缓存数据,而通过存储过程迭代的返回小批量数据

JDBC性能优化方案

时间: 2025-01-07 13:21:29

JDBC性能优化方案的相关文章

mysql 性能优化方案 (转)

网 上有不少MySQL 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与复杂,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用 status信息对mysql进行具体的优化. mysql> show global status; 可以列出mysql服务器运行各种状态值,另外,查询mysql服务器配置信息语句: mysql> show variables; 一

kvm性能优化方案

kvm性能优化方案 kvm性能优化,主要集中在cpu.内存.磁盘.网络,4个方面,当然对于这里面的优化,也是要分场景的,不同的场景其优化方向也是不同的,下面具体聊聊这4个方面的优化细节. cpu 在介绍cpu之前,必须要讲清楚numa的概念,建议先参考如下两篇文章 CPU Topology 玩转cpu-topology 查看cpu信息脚本: #!/bin/bash # Simple print cpu topology # Author: kodango function get_nr_proc

GNU Linux高并发性能优化方案

/*********************************************************** * Author : Samson * Date : 07/14/2015 * Test platform: * gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 * GNU bash, 4.3.11(1)-release (x86_64-pc-linux-gnu) * Nginx version: * Nginx 1.6.2 * Nginx 1.8.0

Glusterfs目录ls性能优化方案分析

Glusterfs目录ls性能优化方案分析 目的和优化思路 讨论了glusterfs对文件系统爬虫rsync/ls目录性能的现有优化措施和可能的进一步优化方案.优化思路是减少本地文件系统的元数据操作,减少fuse client的负载,减少req的网络轮询次数,减少一次网络通信时间,缓存预抓取,并发,异步,bulk 传输 fuse readdirplus centos 6.4最新内核,支持fuse readdirplus.微调mount timeout参数. FUSE: Adaptive NFS-

web前端9大性能优化方案汇总

网页的性能问题是产品开发过程中的一个重要的环节,在产品成功地把功能实现后,性能能好与坏就直接影响了用户体验,以至于影响了产品的成败! 作为web前端开发者,对前端部分进行性能上的优化,是责无旁贷,刻不容缓的工作.下面简介一下9种性能优化方案. 一.罪魁祸首是http请求 一般网页,80%的响应时间花在下载网页内容(images, stylesheets, javascripts, scripts, flash等).减少请求次数是缩短响应时间的关键!可以通过简化页面设计来减少请求次数,但页面内容较

(转)Web性能优化方案

第一章 打开网站慢现状分析 在公司访问部署在IDC机房的VIP网站时会感觉很慢.是什么原因造成的?为了缩短页面的响应时间,改进我们的用户体验,我们需要知道用户的时间花在等待什么东西上. 可以跟踪一下我们的登录页面,如下图所示 从上图我们可以分析知道,HTML文档只占了总响应时间的20%,其它80%响应时间用来下载JS.CSS.图片等组件.所以WEB前端有很大的优化空间,我们将从WEB的前端优化.后端优化两方面综合考虑给出WEB的性能优化方案. 第二章 WEB前台的优化规则 一.尽量减少 HTTP

Redmine性能优化方案

近来公司redmine服务器表现很糟糕,在16核,64GRAM的机器上,压测结果竟然只有每秒5~7个请求,部分页面一个都出不来. 以下是我对Redmine性能优化方案: redmine服务器性能问题排查与优化建议: 以下建议的方案是基于redmine运行期的log文件中的render耗时.activerecord耗时,linux系统性能指标采样与 mysql 性能指标采样分析,以及redmine在不同web server下的benchmark而得:   一. 问题排查与定量分析 通过分析redm

mysql 性能优化方案

这是一篇关于mysql 性能优化的文章.网上有不少mysql 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用status信息对mysql进行具体的优化. mysql> show global status; 可以列出MySQL服务器运行各种状态值,另外,查询MySQL服务器配置信息语句:mysql> sho

数据库优化 | 亿级数据量系统数据库性能优化方案

一.数据库性能瓶颈主要原因 1.数据库连接 MySQL数据库默认连接为100,我们可以通过配置initialSize.minIdle.maxActive等进行调优,但由于硬件资源的限制,数据库连接不可能无限制的增加,对大型单体应用单实例数据库可能会出现最大连接数不能满足实际需求的情况,这时就会系统业务阻塞. 2.表数据量大(空间存储问题) 普遍观点认为单表数据量超过1000万条时就是出现数据库读取性能瓶颈.从索引角度分析,如果索引未被命中,数据库系统就会全表扫描,数据量越大,扫描全表的时间就会越