SQL优化及注意事项

1、 把数据、日志、索引放到不同的I/O设备上,增加读取速度。数据量(尺寸)越大,提高I/O越重要。

2、 纵向、横向分割表,减少表的尺寸,如:可以把大数据量的字段拆分表。

3、 根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该尽量小,尽量使用字节数小的列建索引,不要对有限的几个值的列建单一索引。

4、 用OR的字句可以分解成多个查询,并且通过UNION链接多个查询。它们的速度只与是否使用索引有关,如果查询需要用到联合索引,用UNION all执行的效率更高。

5、 在查询SELECT语句中用WHERE子句限制返回的行数,避免表扫描。如果返回不必要的数据,则浪费了服务器的I/O资源,加重了网络的负担,降低了性能。如果表很大,在表扫描期间将表锁住,禁止其他的联结访问表,后果很严重。

6、 注意使用DISTINCT,在没有必要时不要用,它同UNION一样会使查询变慢。

7、 在IN后面值的列表中,将出现最频繁的值放在最前面,出现最少的放在最后面,减少判断的次数。

8、 一般在GROUP BY和HAVING子句之前就能剔除多余的行,所以尽量不要用它们来做剔除行的工作,也就是说尽可能在WHERE中过滤数据。

9、 尽量将数据的处理工作放在服务器上,减少网络的开销,如使用存储过程。存储过程是编译、优化过,并且被组织到一个执行规划里,且存储在数据库中的SQL语句(存储过程是数据库服务器端的一段程序),是控制流语言的集合,速度当然快。

10、 不要在一句话里再三地使用相同的函数,浪费资源,将结果放在变量里再调用更快。

11、 针对大量只读查询操作进行优化的方法:
1) 数据量小的数据,可以考虑不存储在数据库中,而是通过程序常量的方式解决。
2) 需要存储在数据库中的数据,可以考虑采用物化视图(索引视图)。当DBA在视图上创建索引时,这个视图就被物化(执行)了,并且结果集被永久地保存在唯一索引中,保存方式与一个有聚簇索引的表的保存方式相同。物化视图减除了为引用视图的查询动态建立结果集的开销,优化人员可以在查询中使用视图索引,而不需要在FROM子句中直接指定视图。
3) 数据存储时可以考虑适当的数据冗余,以减少数据库表之间的链接操作,提高查询效率。
4) 针对数据的特点,采取特定的索引类型。例如,位图索引等。

12、 对于SQL语句书写时的一些建议:
1) 写语句时能够确定数据库对象所有者的,尽可能把所有者带上,如:

SELECT * FROM dbo.Users

2) 存储过程中,参数定义最好放在最前面,尽可能一次定义,如:
DECLARE @USER_ID INT

,@USER_NAME VARCHAR(50)

,@PASSWORD VARCHAR(50)

3) 为参数赋值时,尽可能一次赋值,如:
SELECT @USER_ID = 1001

,@USER_NAME = ‘xiaojun.liu‘

4) 尽量少用游标

时间: 2024-10-11 04:52:13

SQL优化及注意事项的相关文章

mysql sql优化及注意事项

sql优化分析 通过slow_log等方式可以捕获慢查询sql,然后就是减少其对io和cpu的使用(不合理的索引.不必要的数据访问和排序)当我们面对具体的sql时,首先查看其执行计划A.看其是否使用索引B.查看其查询的记录数C.确定索引的代价是否过高D.是否可以使用复合索引E.是否有“using temporary”F.是否有“using filesort” 创建高效索引 mysql的innodb有自己特殊的聚集索引(数据是按聚集索引的顺序存储的并和索引存储在一起),索引访问效率较高,次要索引是

SQL优化的方法论

•找到最占用资源的SQL语句 –V$SQLAREA (Shared_pool) –V$session_longops(6秒) –StatsPack Report –SQL*Trace + TKProf –10g ADDM –Toad.Quest Data Center –… •问题定位 How to find Bad SQL –V$SQLAREA (Shared_pool) –StatsPack –SQL*Trace + TKProf –10g ADDM •优化SQL语句 –理解优化器.CBO

sql优化(oracle)- 第二部分 常用sql用法和注意事项

第二部分 常用sql用法和注意事项               1. exists 和 in                             2. union 和 union all                       3. with as  4. order by  5. group by  6. where 和 having  7. case when 和 decode 1.exits和in用法1)说明: 1. exists先对外表做循环,每次循环对内表查询:in将内表和外表

sql优化(oracle)- 第三部分  sql优化总结

第三部分  sql优化总结        1. 优化一般原则        2. 具体注意事项 1. SQL优化一般性原则 1)目标:减少服务器资源消耗(主要是磁盘IO) 2)设计: 1. 尽量依赖oracle优化器 2. 合适的索引(数据重复量大的列不要简历二叉树索引,可以使用位图索引: 对应数据操作频繁的表,索引需要定期重建,减少失效的索引和碎片) 3)编码: 1. 利用索引 2. 合理利用临时表 3. 避免写过于复杂的sql: 4. 尽量减小事务的粒度 2. 具体注意事项 1)查询时尽量使

sql优化(oracle)

永不放弃,一切皆有可能!!! 只为成功找方法,不为失败找借口! sql优化(oracle) 目录 第一部分知识准备                            第二部分 常用sql用法和注意事项                                第三部分  sql优化总结 1.  sql执行过程  1. exists 和 in                                                      1. 优化一般原则 2.  sql 共享

《跨 界 之SQL、PL/SQL优化指南》目录上

优化新作,<跨 界 之SQL.PL/SQL优化指南>详细目录. 目    录 一.理论篇....................................................................10    1.1). SQL的处理过程.......................................................10    1.2). 连接方式(JOIN METHODS)................................

sql优化总结

在项目前期目标是确保功能能够正常运行,但是随着时间的推移,数据的增加,逻辑的复杂,导致数据查询会越来越慢,这个时候我们首先想到的应该就是尽量优化sql. sql优化常见注意点: 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描. 3.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:

(转)大数据量高并发的数据库优化与sql优化

大数据量高并发的数据库优化 一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整

基于oracle的sql优化方法论

Oracle数据库里SQL优化的终极目标就是要缩短目标SQL语句的执行时间.要达到上述目的,我们通常只有如下三种方法可以选择: 1.降低目标SQL语句的资源消耗: 2.并行执行目标SQL语句: 3.平衡系统的资源消耗. "方法1:降低目标SQL语句的资源消耗"以缩短执行时间,这是最常用的SQL优化方法.这种方法的核心是要么通过在不更改业务逻辑的情况下改写SQL来降低目标SQL语句的资源消耗,要么不改SQL但通过调整执行计划或相关表的数据来降低目标SQL语句的资源消耗. 方法2:并行执行