Java对数据库(Oracle)大量查询性能问题,达人指教!!!

Java对数据库(Oracle)大量查询性能问题,达人指教!!!,第1张

不会有问题,现在BBS很多都是一张表存上万条,用SQL SERVER都行,更何况ORACLE了。查询的性能问题不是你的语言决定的,而是数据库决定的。数据库本身建立了索引,不会线性的去找,速度非常快的,所以没必要分开检索

如果是纯遍历的话,他们俩没什么两样,速度都差不多。

我觉得你应该仔细考虑一下你的需求,为什么用遍历这种方式呢,耗费的时间不可预料,随着数据的增大,会变得很糟糕。建议你寻找其他方式,比如增加sql查询条件,限制返回的数据数量。

限流算法目前程序开发过程常用的限流算法有两个:漏桶算法和令牌桶算法。

漏桶算法

漏桶算法的原理比较简单,请求进入到漏桶中,漏桶以一定的速率漏水。当请求过多时,水直接溢出。可以看出,漏桶算法可以强制限制数据的传输速度。如图所示,把请求比作是水滴,水先滴到桶里,通过漏洞并以限定的速度出水,当水来得过猛而出水不够快时就会导致水直接溢出,即拒绝服务。

来自网络

漏桶的出水速度是恒定的,那么意味着如果瞬时大流量的话,将有大部分请求被丢弃掉(也就是所谓的溢出)。

令牌桶算法

令牌桶算法的原理是系统以一定速率向桶中放入令牌,如果有请求时,请求会从桶中取出令牌,如果能取到令牌,则可以继续完成请求,否则等待或者拒绝服务。这种算法可以应对突发程度的请求,因此比漏桶算法好。

来自网络

漏桶算法和令牌桶算法的选择

两者的主要区别漏桶算法能够强行限制处理数据的速率,不论系统是否空闲。而令牌桶算法能够在限制数据的平均处理速率的同时还允许某种程度的突发流量。如何理解上面的含义呢?漏桶算法,比如系统吞吐量是 120/s,业务请求 130/s,使用漏斗限流 100/s,起到限流的作用,多余的请求将产生等待或者丢弃。对于令牌桶算法,每秒产生 100 个令牌,系统容量 200 个令牌。正常情况下,业务请求 100/s 时,请求能被正常被处理。当有突发流量过来比如 200 个请求时,因为系统容量有 200 个令牌可以同一时刻处理掉这 200 个请求。如果是漏桶算法,则只能处理 100 个请求,其他的请求等待或者被丢弃。

1、主键就是聚集索引

2、只要建立索引就能显著提高查询速度

3、把所有需要提高查询速度的字段都加进聚集索引,以提高查询速度

 (四)其他书上没有的索引使用经验总结

1、用聚合索引比用不是聚合索引的主键速度快

2、用聚合索引比用一般的主键作order by时速度快,特别是在小数据量情况下

3、使用聚合索引内的时间段,搜索时间会按数据占整个数据表的百分比成比例减少,而无论聚合索引使用了多少个

4 、日期列不会因为有分秒的输入而减慢查询速度

(五)其他注意事项

1 不要索引常用的小型表

2 不要把社会保障号码(SSN)或身份z号码(ID)选作键

3 不要用用户的键

4 不要索引 memo/notes 字段和不要索引大型文本字段(许多字符)

5 使用系统生成的主键

 二、改善SQL语句

1、Like语句是否属于SARG取决于所使用的通配符的类型

2、or 会引起全表扫描

3、非 *** 作符、函数引起的不满足SARG形式的语句

4、IN 的作用相当与OR

5、尽量少用NOT

6、exists 和 in 的执行效率是一样的

7、用函数charindex()和前面加通配符%的LIKE执行效率一样

8、union并不绝对比or的执行效率高

9、字段提取要按照“需多少、提多少”的原则,避免“select ”

10、count()不比count(字段)慢

11、order by按聚集索引列排序效率最高

12、高效的TOP

数据库性能优化是无止境的 无论哪种优化技术只是一种手段 但最重要的不是技术 而是思想 掌握了索引优化技术仅仅刚入门 只有融会贯通 举一反三才能成为高手

本文引用一套实验室信息管理系统(LIS)使用的数据库 假设我们要查询 年 月做检验的患者记录 条件是大于 岁 姓周的患者 最终结果按检查日期进行倒序排列 要使用的表有三个

◆lis_report 报告主表 我们要用到的字段包括i_checkno(检查号) d_checkdate(检查日期) i_patientid(患者ID)

◆m_patient 患者信息表 我们要用到的字段包括i_patientid(患者ID) s_name(患者姓名) s_code(患者住院号) i_age(患者年龄) i_dept(患者所在病区)

◆lis_code_dept 病区信息表 我们要用到的字段包括i_id(病区ID 主键 与m_patient中的i_dept关联) s_name(病区名)

最终我们构造的SQL如下

select a i_checkno a d_checkdate b s_name b s_code b i_age c s_name from lis_report a inner join m_patient b on a i_patientid = b i_patientid inner join lis_code_dept c on b i_dept = c i_id where a d_checkdate > and a d_checkdate < and b i_age>= and b s_name like 周% order by a d_checkdate desc

我们的SQL使用的这三张表除了创建主键时自动创建的索引外 均未创建其它索引 下图是无索引时的执行计划

表m_patient和lis_report都使用了全表扫描 m_patient全表扫描的成本是 lis_report全表扫描的成本是 只有表lis_code_dept因关联时使用的是其主键 因此这里使用了主键索引 从而避免了全表扫描 它的成本是 我们知道提高查询性能的目标之一就是消灭掉全表扫描 因此我们应该给表m_patient和lis_report加上适当的索引 在SQL代码的where子句中 对m_patient表 我们引用了i_age和s_name字段 对lis_report表 我们引用了d_checkdate字段 通常给这些条件中引用的字段加上索引会提高查询速度 我们先给m_patient的i_gae字段加上索引 下面是对应的执行计划

表m_patient的全表扫描消失了 取而代之的是索引唯一性扫描 成本从 一下子降低到 了 注意这里并未使用我们给i_age增加的索引 但却靠它触发了使用表主键对应的索引 但表lis_report仍然是全表扫描 由于where子句中引用了该表的d_checkdate字段 因此我们给该字段加上索引看看效果

表lis_report的全表扫描消失了 取而代之的是索引范围降序扫描(INDEX RANGE SCAN DESCENDING) 成本也从 下降到 注意这里的索引范围降序扫描的来历 因为我的where子句中引用d_checkdate是介于 至 的一个范围 这时引用的这种字段上建立的索引通常都是执行范围扫描 因为这种条件返回的值往往不止一行 使用降序扫描的原因是order by子句使用了降序排序 如果我们将SQL代码中的 order by a d_checkdate desc 改为 order by a d_checkdate 则变为索引范围扫描(INDEX RANGE SCAN)

至此我们全部消除了全表扫描 我们看到加上索引后 查询执行的成本开销也有所降低 因为数据库表中的记录数不大 因此效果不太明显 如果有上百万条记录则会更直观

lishixinzhi/Article/program/Oracle/201311/18362

这个有很多可以说的了以下全部手打by lcg1986:

数据库层面优化

从数据库本身来优化,优化SQL语句,建立适当的索引尽量让查询条件命中索引,避免全表扫描

精简查询语句,使用select 字段,避免使用select

数据库使用主备机或者集群模式,进行读写分离

对数据进行分库分表

系统应用层面优化

系统使用连接池连接数据库,避免频繁的建立连接,释放连接的IO开销

使用缓存,根据业务场景对数据进行划分,尽量将基本不会发生改变的数据缓存下来,查询时优先查询缓存,减少对数据库的访问

对服务进行降级功能设计,在并发大到数据库实在无法处理的情况,对造成数据拥堵的服务进行降级

支持数据的读写分离读请求和写请求分别访问不同的数据库

支持分库分表,或引入数据库中间件,如Mycat

硬件方面优化

尽量使用SSD磁盘类型的数据库服务器,相比传统机械硬盘类型的服务器,具有更高的IO吞吐能力

如果可能,尽量保证系统与数据库,数据库各个机器在同一区域内避免如系统服务在北京,数据库服务器在上海的情况,减少因为网络环境,网络带宽等因素带来的影响

 SIMPLE:简单SELECT(不使用UNION或子查询等)

PRIMARY:最外面的SELECT

UNION:UNION中的第二个或后面的SELECT语句

DEPENDENT UNION:UNION中的第二个或后面的SELECT语句,取决于外面的查询

UNION RESULT:UNION的结果。

SUBQUERY:子查询中的第一个SELECT

DEPENDENT SUBQUERY:子查询中的第一个SELECT,取决于外面的查询

DERIVED:导出表的SELECT(FROM子句的子查询)

可以用多进程模拟。如果用批处理脚本的话。

看你怎么测。

如果使用jdbc程序段,多线程确实可以模拟。一个线程一个连接。

设计好标准的数据集。网上或许有下载的。记录好测试环境和测试各个阶段所花时间。

以上就是关于Java对数据库(Oracle)大量查询性能问题,达人指教!!!全部的内容,包括:Java对数据库(Oracle)大量查询性能问题,达人指教!!!、for循环遍历查找数据与sqlite数据库查找数据性能问题、如何查看高并发下mysql数据库的性能等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/sjk/9804167.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-02
下一篇2023-05-02

发表评论

登录后才能评论

评论列表(0条)

    保存