当前位置:首页 » 编程语言 » sql语句优化技巧
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

sql语句优化技巧

发布时间: 2023-08-16 09:39:15

sql调优的几种方式

你好,
SQL优化的一些方法
1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描。
3.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描。
5.in 和 not in 也要慎用,否则会导致全表扫描,
6.下面的查询也将导致全表扫描:
select id from t where name like '%abc%'
7.应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。
8.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。
9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。
10.在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。

❷ 如何提高sql语句的执行效率

1、使用ordered提示

Oracle必须花费大量的时间来剖析多表的合并,用以确定表合并的最佳顺序。SQL表达式涉及七个乃至更多的表合并,那么有时就会需要超过30分钟的时间来剖析,Ordered这个提示(hint)和其他的提示一起使用能够产生合适的合并顺序。

2、使用ordered_predicates

ordered_predicates提示在查询的WHERE子句里指定的,并被用来指定布尔判断(Booleanpredicate)被评估的顺序。在没有ordered_predicates的情况下,Oracle会使用下面这些步骤来评估SQL判断的顺序:子查询的评估先于外层WHERE子句里的Boolean条件。

所有没有内置函数或者子查询的布尔条件都按照其在WHERE子句里相反的顺序进行评估,即最后一条判断最先被评估。每个判断都带有内置函数的布尔判断都依据其预计的评估值按递增排列。

3、限制表格合并评估的数量

提高SQL剖析性能的最后一种方法是强制取代Oracle的一个参数,这个参数控制着在评估一个查询的时候,基于消耗的优化器所评估的可能合并数量。

(2)sql语句优化技巧扩展阅读:

1、表设计的优化,数据行的长度不要超过8020字节,如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片,降低查询效率。

2、语句的查询优化,保证在实现功能的基础上,尽量减少对数据库访问次数;

3、建立高效的索引创建索引一般有以下两个目的:维护被索引列的唯一性和提供快速访问表中数据的策略。

大型数据库有两种索引即簇索引和非簇索引,一个没有簇索引的表是按堆结构存储数据,所有的数据均添加在表的尾部,而建立了簇索引的表,其数据在物理上会按照簇索引键的顺序存储。个表只允许有一个簇索引。

4、强制查询转换,有时候oracle 的优化器未必能走正确的查询路线,这个时候就需要添加一些hint 之类的来规定他的执行路线。当然了,这个未必是最好的处理方案。因为虽然现在走这个路线是对的,以为因为数据的变化到这这个HINT 变得不可取。

❸ 如何进行SQL性能优化

这里分享下mysql优化的几种方法。

1、首先在打开的软件中,需要分别为每一个表创建 InnoDB FILE的文件。

❹ 如何优化SQL语句

一、问题的提出
在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就可,而是要写出高质量的SQL语句,提高系统的可用性。
在多数情况下,Oracle使用索引来更快地遍历表,优化器主要根据定义的索引来提高性能。但是,如果在SQL语句的where子句中写的SQL代码不合理,就会造成优化器删去索引而使用全表扫描,一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引,这有助于写出高性能的SQL语句。
二、SQL语句编写注意问题
下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中,即使某些列存在索引,但是由于编写了劣质的SQL,系统在运行该SQL语句时也不能使用该索引,而同样使用全表扫描,这就造成了响应速度的极大降低。
1.
IS
NULL

IS
NOT
NULL
不能用null作索引,任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下,只要这些列中有一列含有null,该列就会从索引中排除。也就是说如果某列存在空值,即使对该列建索引也不会提高性能。
任何在where子句中使用is
null或is
not
null的语句优化器是不允许使用索引的。
2.
联接列
对于有联接的列,即使最后的联接值为一个静态值,优化器是不会使用索引的。我们一起来看一个例子,假定有一个职工表(employee),对于一个职工的姓和名分成两列存放(FIRST_NAME和LAST_NAME),现在要查询一个叫比尔.克林顿(Bill
Cliton)的职工。
下面是一个采用联接查询的SQL语句,
select
*
from
employss
where
first_name||''||last_name
='Beill
Cliton';
上面这条语句完全可以查询出是否有Bill
Cliton这个员工,但是这里需要注意,系统优化器对基于last_name创建的索引没有使用。
当采用下面这种SQL语句的编写,Oracle系统就可以采用基于last_name创建的索引。
***
where
first_name
='Beill'
and
last_name
='Cliton';
.
带通配符(%)的like语句
同样以上面的例子来看这种情况。目前的需求是这样的,要求在职工表中查询名字中包含cliton的人。可以采用如下的查询SQL语句:
select
*
from
employee
where
last_name
like
'%cliton%';
这里由于通配符(%)在搜寻词首出现,所以Oracle系统不使用last_name的索引。在很多情况下可能无法避免这种情况,但是一定要心中有底,通配符如此使用会降低查询速度。然而当通配符出现在字符串其他位置时,优化器就能利用索引。在下面的查询中索引得到了使用:
select
*
from
employee
where
last_name
like
'c%';
4.
Order
by语句
ORDER
BY语句决定了Oracle如何将返回的查询结果排序。Order
by语句对要排序的列没有什么特别的限制,也可以将函数加入列中(象联接或者附加等)。任何在Order
by语句的非索引项或者有计算表达式都将降低查询速度。
仔细检查order
by语句以找出非索引项或者表达式,它们会降低性能。解决这个问题的办法就是重写order
by语句以使用索引,也可以为所使用的列建立另外一个索引,同时应绝对避免在order
by子句中使用表达式。
5.
NOT
我们在查询时经常在where子句使用一些逻辑表达式,如大于、小于、等于以及不等于等等,也可以使用and(与)、or(或)以及not(非)。NOT可用来对任何逻辑运算符号取反。下面是一个NOT子句的例子:
...
where
not
(status
='VALID')
如果要使用NOT,则应在取反的短语前面加上括号,并在短语前面加上NOT运算符。NOT运算符包含在另外一个逻辑运算符中,这就是不等于(<>)运算符。换句话说,即使不在查询where子句中显式地加入NOT词,NOT仍在运算符中,见下例:
...
where
status
<>'INVALID';
对这个查询,可以改写为不使用NOT:
select
*
from
employee
where
salary<3000
or
salary>3000;
虽然这两种查询的结果一样,但是第二种查询方案会比第一种查询方案更快些。第二种查询允许Oracle对salary列使用索引,而第一种查询则不能使用索引。
虽然这两种查询的结果一样,但是第二种查询方案会比第一种查询方案更快些。第二种查询允许Oracle对salary列使用索引,而第一种查询则不能使用索引。

❺ SQL语句的几种优化方法

1、尽可能建立索引,包括条件列,连接列,外键列等。

2、尽可能让where中的列顺序与复合索引的列顺序一致。

3、尽可能不要select *,而只列出自己需要的字段列表。

4、尽可能减少子查询的层数。

5、尽可能在子查询中进行数据筛选 。

❻ 【基于ORACLE数据库的SQL语句优化分析】 数据库查询语句的优化

【摘要】随着数据库应用范围及规模的不断扩大,数据库的性能问题逐渐显现,优化数据库有助于维持系统的稳定性以及运行的高效性。本文主要依据笔者在实际工作中的精坦敏拍英,对SQL语句优化的目的、SQL语句优化技术及原则进行全面分析和阐述。
【关键词】ORACLE数据库;SQL语句;优化
1前言
随着现代化信息技术的迅猛发展,互联网应用的日益普及,数据库技术的影响力越来越大。作为信息系统管理的核心,数据库的主要操作就是查询,数据库的应用效率在很大程度上是由查询速度决定的,特别是对于规模较大的数据库而言,查询速度十分关键。查询速度在SQL语句中占有很大比重,所以,通过对查询语句进行优化有助于促进应用系统性能及效率的进一步提升。
2SQL语句优化分析
2.1SQL语句优化的目的
对于一个数据库而言,在确保设计无误的前提下,要想避免出现性能问题必须确保其拥有合理的SQL语句拿唤结构。最简单的数据库寻找数据路径是对SQL语句进行调整,ORACLE数据库性能提升的主要途径就是对SQL语句进行适当的调整。从本质上讲,SQL语句优化就是确保所使用的语句可以被优化器识别,对索引进行有效利用以便控制表扫描的I/O次数,有效防止出现表搜索。用高性能的SQL语句替代低性能的SQL语句,确定最佳的数据查找路径,尽可能使CPU时间与I/O时间保持平衡是进行优化的主要目的。在对SQL语句进行优化的过程中,以系统需求为依据确定最有可能实现性能提升的语句并进行优化。
2.2SQL语句优化技术及原则
当数据量积累到一定程度之后,对于数据库全表SQL语句进行一次扫描,若查询策略较好,一般只用几秒钟,但如果SQL语句性能较低,就需要用几分钟甚至更多时间。从这点不难看出,SQL语句性能对于查询速度具有极大的影响,所以,对于应用系统而言,不仅能满足功能的实现,还要保证SQL语句的质量。
(1)采取适宜的索引。为达到优化查询的目的,一项重要工作就是确定相适应的索引,并严格依照原则加以使用,与此同时,为有效控制I/O竞争,不可以在同一个磁盘中同时建立索引和用户表空间。
语句1:SELECT CUS_NO, CUS_NAME FROM CUSTOMER WHERE CUS_NO NOT IN
(SELECT CUS_NO FROM SERVICE);
语句2: SELECT CUS_NO, CUS_NAME FROM CUSTOMER WHERE NOT EXISTS
(SELECT * FROM SERVICE WHERE SERVICE.CUS_NO=CUSTOMER.CUS_NO);
上述两个语句可以达到一致的查询结果,对二者进行对比,当执行语句1时,由于ORACLE未利用CUSTOMER 表上CUS_NO索引,所以就会扫描整表,在执行语句2的过让羡程中,ORACLE所扫描的只是CUSTOMER 表子查询中的联合查询,并且使用了CUS_NO索引,因此,在执行效率方面明显优于前者。
(2)避免在SELECT子句中出现“*”。ORACLE在进行解析时,需要按照一定顺序对“*”进行转换,该项转换工作的进行需要对数据库的数据字典进行查询,势必需要花费较多的时间,这样就会导致较低的效率,所以,要避免在SELECT子句中出现“*”。
(3)如果必要可以利用COMMIT提交事务。ORACLE能够自动提交DDL语句,而诸如DML等类型的语句的提交则是通过手动方式或者回滚事务实现的。在编写应用程序的过程中,在操作诸如insert、delete以及update 等较为复杂的语境的时候,利用COMMIT提交事务可以讲会话中持有的锁加以释放,将存在于缓存中的未经修改的数据块进行清除,进而将系统资源予以释放,促进系统性能的进一步提升,因此,如果有必要,可以利用COMMIT对相关事务进行提交。
(4)联合查询连接顺序的确定。如果查询操作涉及到多个表,基础表应当是交叉表,所谓交叉表具体是指被其他表引用的表。连接执行效果在很大程度上受到FROM语句中表的顺序的影响,对于FROM中所包含的表,ORACLE解析器进行处理的顺序是由右至左,SQL语句中所选择的基础表会因优化器的不同而有所区别,在使用CBO的情况下,优化器会对SQL语句中各个表的物理大小以及索引状态进行检查,在此基础上确定一个花费最小的执行路径;在使用RBO的情况下,如果全部的连接条件均有索引与之相对应,那么,FROM子句中位置最后面的表就是基础表。
(5)IN用EXISTS取代。在对数个基础表查询过程中,一般需要进行表的连接。因为利用IN的子查询过程中,ORACLE的扫描对象是全表,因此,出于提高查询效率目的的考虑,应当将IN用EXISTS取代。
(6)在索引列中不使用计算。当通过对函数进行引用在WHERE子句中进行计算的时候,假如索引列只是函数的一部分,优化器就会针对全表进行扫描,而不会使用索引,所以,在索引列中不能使用函数。
3结语
综上所述,随着现代化信息技术的迅猛发展,互联网应用的日益普及,数据库技术的影响力越来越大。在信息量迅速激增的形势下,数据库优化调整成为当前所面临的一大关键性问题,特别是对规模较大的数据库而言,及时进行优化的意义更加倍重大。对于数据库的运行性能而言,最主要的影响因素主要体现在以下几点:数据库系统架构的设计是否合理,资源配置是否科学以及SQL语句编写效率等。笔者从事的是电信企业的运营分析工作,每天都要从数据库取各种数据,可以说是离不开数据库,所以在实践中,我觉得严格遵守SQL语句优化原则及方法,并在实践中及时总结经验教训,可以实现对系统响应时间的有效控制,促进运行效率的提升。
参考文献
[1] 许开宇,胡文骅. 如何提高ORACLE数据库应用程序的性能[J]. 计算机应用与软件. 2002(10)
[2] 郑耀,吴建岚. 基于Oracle数据库的语句优化策略[J]. 信息与电脑(理论版). 2011(07)
[3] 高攀,施蔚然. 基于Oracle数据库的SQL语句优化[J]. 电脑编程技巧与维护. 2010(22)
[4] 钟小权,叶猛. Oracle数据库的SQL语句优化[J]. 计算机与现代化. 2011(03)
作者简介:
王勇军,男,(1981.1-),吉林通化人,就职于中国联合网络通信有限公司长春市分公司,通信工程师,本科,研究方向:SQL使用
(作者单位:中国联合网络通信有限公司长春市分公司)

❼ 这些SQL优化技巧握在手,面试可以横着走……

一、SQL执行顺序



二、基础SQL优化


1、查询SQL尽量不要使用select *,而是具体字段


1)反例



2)正例



3)理由



2、避免在where子句中使用or来连接条件


查询id为1或者薪水为3000的用户:


1)反例



2)正例


使用union all:



分开两条SQL写:



3)理由



3、使用varchar代替char


1)反例



2)正例



3)理由



4、尽量使用数值替代字符串类型



5、查询尽量避免返回大量数据


如果查询返回数据量很大,就会造成查询时间过长,网络传输时间过长。同时,大量数据返回也可能没有实际意义。如返回上千条甚至更多,用户也看不过来。

通常采用分页,一页习惯10/20/50/100条。


6、使用explain分析你SQL执行计划


SQL很灵活,一个需求可以很多实现,那哪个最优呢?SQL提供了explain关键字,它可以分析你的SQL执行计划,看它是否最佳。Explain主要看SQL是否使用了索引。



返回结果:



7、是否使用了索引及其扫描类型


type:



性能排行:


System > const > eq_ref > ref > range > index > ALL


possible_keys:



key:



8、创建name字段的索引


提高查询速度的最简单最佳的方式。



9、优化like语句


模糊查询,程序员最喜欢的就是使用like,但是like很可能让你的索引失效。


1)反例



2)正例



3)理由


未使用索引,故意使用sex非索引字段:




主键索引生效:




索引失效,type=ALL,全表扫描:




10、字符串怪现象


1)反例



2)正例



3)理由


为什么第一条语句未加单引号就不走索引了呢?这是因为不加单引号时,是字符串跟数字的比较,它们类型不匹配,MySQL会做隐式的类型转换,把它们转换为数值类型再做比较。


11、索引不宜太多,一般5个以内



12、索引不适合建在有大量重复数据的字段上


如性别字段。因为SQL优化器是根据表中数据量来进行查询优化的,如果索引列有大量重复数据,Mysql查询优化器推算发现不走索引的成本更低,很可能就放弃索引了。


13、where限定查询的数据


数据中假定就一个男的记录。


1)反例



2)正例



3)理由



14、避免在索引列上使用内置函数


业务需求:查询最近七天内新生儿(用学生表替代下)


给birthday字段创建索引:



当前时间加7天:



1)反例



2)正例



3)理由







15、避免在where中对字段进行表达式操作


1)反例



2)正例




3)理由






16、避免在where子句中使用!=或>操作符


应尽量避免在where子句中使用!=或>操作符,否则引擎将放弃使用索引而进行全表扫描。记住实现业务优先,实在没办法,就只能使用,并不是不能使用。如果不能使用,SQL也就无需支持了。


1)反例




2)理由




17、去重distinct过滤字段要少





1)理由


18、where中使用默认值代替null


环境准备:




1)反例



2)正例



3)理由



三、高级SQL优化


1、批量插入性能提升


大量数据提交,上千,上万,批量性能非常快,mysql独有。


1)多条提交



2)批量提交



3)理由



2、批量删除优化


避免同时修改或删除过多数据,因为会造成cpu利用率过高,会造成锁表操作,从而影响别人对数据库的访问。


1)反例




2)正例




3)理由



3、伪删除设计


1)商品状态(state)



2)理由



4、提高group by语句的效率


可以在执行到该语句前,把不需要的记录过滤掉。


1)反例:先分组,再过滤



2)正例:先过滤,后分组



5、复合索引最左特性


创建复合索引,也就是多个字段。



满足复合索引的左侧顺序,哪怕只是部分,复合索引生效。



没有出现左边的字段,则不满足最左特性,索引失效。



复合索引全使用,按左侧顺序出现 name,salary,索引生效。



虽然违背了最左特性,但MYSQL执行SQL时会进行优化,底层进行颠倒优化。



1)理由



6、排序字段创建索引


什么样的字段才需要创建索引呢?原则就是where和order by中常出现的字段就创建索引。



7、删除冗余和重复的索引




8、不要有超过5个以上的表连接



9、inner join 、left join、right join,优先使用inner join


三种连接如果结果相同,优先使用inner join,如果使用left join左边表尽量小。



1)理由



10、in子查询的优化


日常开发实现业务需求可以有两种方式实现:



如需求:查询所有部门的所有员工:



假设表A表示某企业的员工表,表B表示部门表,查询所有部门的所有员工,很容易有以下程序实现,可以抽象成这样的一个嵌套循环: