当前位置：首页 > news >正文

网站制作湖州/开封seo公司

news 2025/7/2 11:50:56

网站制作湖州,开封seo公司,网站建设柳州,今日时政新闻点击上方 "程序员小乐"关注, 星标或置顶一起成长每天凌晨00点00分, 第一时间与你相约每日英文 If nothing can be done, then just let nature take its course. 如果无能为力，那就它顺其自然吧。每日掏心话一切顺其自然，专注于过程而少想…

点击上方 "程序员小乐"关注, 星标或置顶一起成长

每天凌晨00点00分, 第一时间与你相约

每日英文

If nothing can be done, then just let nature take its course.

如果无能为力，那就它顺其自然吧。

每日掏心话

一切顺其自然，专注于过程而少想结果，安于当下，不想过去亦不想未来，把每一个发生都当作一种修炼。

来自：素小暖OSC | 责编：乐乐

链接：my.oschina.net/u/4006148/blog/3225442

程序员小乐(ID:study_tech)第 834 次推文图片来自百度

往日回顾：前后端分离模式下的权限设计方案

正文

最近在做有关查询数据库的工作，由于一个表的数据量过大，导致程序进程卡死情况出现，SQL优化迫在眉睫，索引闪亮登场！

Oracle中查询走索引的情况：

1、对返回的行无任何限定条件，即没有where子句。

2、未对数据表与任何索引主列相对应的行限定条件。

例如：在id-name-time列创建了三列复合索引，那么仅对name列限定条件不能使用这个索引，因为name不是索引的主列。

3、对索引的主列有限定条件，但是在条件表达式里使用以下表达式则会使索引失效，造成权标扫描：

(1)where子句中对字段进行函数、表达式操作，这将导致引擎放弃使用索引而进行全表扫描。

(2)查询字段is null时索引失效，引起全表查询。

解决办法：SQL语法中使用null会有很多麻烦，最好索引列时not null的；对于is null，可以建立组合索引， nvl(字段,0),对表和索引analyse后，is null查询时可以重新启用索引查找,但是效率还不是值得肯定；is not null时永远不会使用索引。一般数据量大的表不要用is null查询。

(3) 查询条件中使用了不等于操作符(<>、!=)会限制索引、引起全表扫描。

解决方法：通过把不等于操作符改成or，可以使用索引，避免全表扫描。
例如，把column<>10，改成column<10 or column>10，就可以使用索引了。

(4)对索引的主列有限定条件，但是条件使用like操作以及值以‘%’开始或者值是一个赋值变量。

例如：where city like '%大连%'。

select * from citys where name like '%大连' (不使用索引)
select * from citys where name like '大连%' (使用索引) 。

解决办法：首先尽量避免模糊查询，如果必须使用，不采用全模糊查询，也应尽量采用右模糊查询，即like ‘…%’，是会使用索引的；左模糊like ‘%...’无法直接使用索引，但可以利用reverse + function index 的形式，变化成 like ‘…%’；

全模糊查询是无法优化的，一定要使用的话建议使用搜索引擎。

4、 or语句使用不当会引起全表扫描

原因：where子句中比较的两个条件，一个有索引，一个没索引，使用or则会引起全表扫描。
例如：where A=：1 or B=：2，A上有索引，B上没索引，则比较B=：2时会重新开始全表扫描

5、组合索引

排序时应按照组合索引中各列的顺序进行排序，即使索引中只有一个列是要排序的，否则排序性能会比较差。

例如：

create index skip1 on emp5(job,empno，date);
select job，empno from emp5 where job=’manager’ and empno=’10’ order by job,empno,date desc;

实际上只是查询出符合 job=’manager’ and empno=’10’ 条件的记录并按date降序排序，但写成order by date desc性能较差。

6、 Update语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志。

7、对于多张大数据量的表JOIN，要先分页再JOIN，否则逻辑读会很高，性能很差。

8、 select count(*) from table；
这样不带任何条件的count会引起全表扫描，并且没有任何业务意义，是一定要杜绝的。

9、 sql的where条件要绑定变量，比如where column= 1，不要写成where column=‘aaa’，这样会导致每次执行时都会重新分析，浪费CPU和内存资源。

10、不要使用in操作符，这样数据库会进行全表扫描。

11、 not in 使用not in也不会走索引

推荐方案：用not exists或者(外联结+判断为空)来代替

12、 > 及 < 操作符(大于或小于操作符)

大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找。
但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段 A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。
那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时ORACLE会先找出为2的记录索引再进行比较，而A>=3时ORACLE则直接找到=3的记录索引。

13、 UNION操作符

UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。
实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表UNION。如：
select * from gc_dfys
union
select * from ls_jg_dfys
这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。
推荐方案：采用UNION ALL操作符替代UNION，因为UNION ALL操作只是简单的将两个结果合并后就返回。

14、 WHERE后面的条件顺序影响

Select * from zl_yhjbqk where dy_dj = '1K以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1K以下'

以上两个SQL中dy_dj及xh_bz两个字段都没进行索引，所以执行的时候都是全表扫描，
第一条SQL的dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较。
而在进行第二条SQL的时候 0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。

15、查询表顺序的影响

在FROM后面的表中的列表顺序会对SQL执行性能影响，在没有索引及ORACLE没有对表进行统计分析的情况下ORACLE会按表出现的顺序进行链接，
由此因为表的顺序不对会产生十分耗服务器资源的数据交叉。(注：如果对表进行了统计分析，ORACLE会自动先进小表的链接，再进行大表的链接)

表连接时，数据量大的为主表效率更高。

16、Oracle的解析器按照从右到左的顺序处理from子句中的表名，因此from子句中写在最后的表(基础班 driving table)将先被最先处理。

在from子句中包含多个表的情况下，必须选择记录条数最少的表作为基础表，放在最后。
以下几种情况快速判断基础表(驱动表)：

(1)where子句中尽量使用索引。

(2)连接操作应返回较少行上驱动。

(3)如果where中包含选择性条件，如where id=1，应将最具有选择性部分放在表达式最后。

(4)如果只有一个表有索引，另一表无索引，无索引的表通常作为基础表。