开发者应了解的一些SQL优化准则

下面介绍一些开发者在数据库操作中要注意的SQL编码准则。虽然本文不能覆盖所有的准则,但还是希望能给开发者带来些许帮助。下面就来看看在编码实践中哪些应该做,哪些不应该做。

  1.  在长时间运行的查询和短查询中使用事务

  如果预期有一个长时间运行的查询,并且有大量的数据输出时,开发者就应该在BEGIN TRAN 和END TRAN之间使用事务。

  这样事务会在缓冲区缓存为独立事务,并会被分配特定内存,以此来提高处理速度。

  2.  不要使用SELECT *

  如果使用SELECT * 来选择表中的所有记录,那么一些不必要的记录也被读取、缓存,增加了磁盘的I/O和内存消耗。

  3.  避免在WHERE子句中使用显式或隐式函数,比如Convert ()

  4.  避免在触发器中执行长时间的操作

  5.  适当使用临时表和表变量

  当结果集较小的时候,请尽量使用表变量;当结果集相当大时,使用临时表。

  6.  使用连接(JOIN)代替子查询(Sub-Queries)

  子查询通常作为内联代码来使用,而连接(JOIN)则作为表来使用,这样速度会更快。所以,应尽量避免在连接中使用子查询。

  7.  连接条件中表的顺序

  在连接条件中,应尽量首先使用较小的表,然后逐步使用较大的表。

  8.  循环优化

  如果操作在循环内部没有任何影响,那么应尽量将操作放到循环外面,这样可以减少不必要的重复工作。因为,SQL Server优化器不会自动识别这种低效率的代码,更不会自动优化(其他一些语言的编译器可以)。

  9.  参数探测

  不要在正执行的SP(存储过程)中使用SP参数,这样会导致参数探测(Parameter Sniffing)。应该在声明和设置后再使用SP参数。由于这个原因,SP的行为在每次运行期间都不相同。

  10.  当使用条件语句时,可以使用Index(索引)Hint(提示)

  比如在SQL Server 2008中,可以使用Index hint,也可以使用fixed plan hint强制在查询中使用hint,以提高运行速度。

  11.  在声明中明确指定存储过程中数据类型的大小

  开发者随机声明数据类型的大小是不可取的,如:Varchar (500)。这在执行时会在缓冲区中增加不必要的预留空间。

  12.  在查询中有效利用MAXDOP(最大并行度)设置

  询问数据库管理员关于四核CPU可用性的设置,包括内存的设置,然后适当使用hint,可以有效改善查询速度。

  13.  SQL Server 2008中的GROUPING SETS

  如果数据库服务器为SQL Server 2008,那么可以在所有的Unions中使用Grouping Set来代替Group By。这样在Union中重新进行group by排序时,优化器不会每次都制定一个计划。

  14.  当发生死锁时,总是使用With (nolock) 和With (rowlock)

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-27 12:29:26

开发者应了解的一些SQL优化准则的相关文章

Oracle sql 优化小结

对于sql优化,从实际工作经验出发,总结如下: 1).where过滤部分,等式左边不要带任何计算和嵌套函数,想办法等价替换,在等式右边去做变动: 2).能手动计算的部分,手动算好写上固定的值,不要写一个表达式在sql里,让程序每次去重算: 3).3个及以上大表关联,慢到跑个30分钟都不出结果,最直接简单的方法是建一个临时表,拆分多表关联为多个2表关联的等价sql; 4).对于非常慢的sql,可以尝试重新获取源表信息,获取新的执行计划: 5).在实现逻辑时,对于有排序操作的关键字(order by

SQL优化器原理 - Join重排

这是ODPS有关SQL优化器原理的系列文章之一.我们会陆续推出SQL优化器有关优化规则和框架的其他文章.添加钉钉群"关系代数优化技术"(群号11719083)可以获取最新文章发布动态. 本文的目标是解释Join重排这个特性的基础概念和算法,如果想快速了解并在MaxCompute上使用这个特性,请直接跳到"总结". 简介 Join重排是经典的SQL优化问题.考虑3个表的自然连接 A ⋈ B ⋈ C ,在不影响最终结果集的前提下,可以改变连接的顺序为下列: A ⋈ C

揭秘SQL优化技巧 改善数据库性能_Mysql

优化目标 1.减少 IO 次数 IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段. 2.降低CPU计算 除了 IO 瓶颈之外,SQL优化中需要考虑的就是CPU运算量的优化了.order by, group by,distinct - 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算).当我们的 IO 优化做到一定

MySQL数据库性能优化之SQL优化

这篇文章是以 MySQL 为背景,很多内容同时适用于其他关系型数据库,需要有一些索引知识为基础. 优化目标 1.减少 IO 次数 IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段. 2.降低 CPU 计算 除了 IO 瓶颈之外,SQL优化中需要考虑的就是 CPU 运算量的优化了.order by, group by,distinct - 都是

PHP开发程序应该注意的42个优化准则

PHP 独特的语法混合了 C.Java.Perl 以及 PHP 自创新的语法.它可以比 CGI或者Perl更快速的执行动态网页.用PHP做出的动态页面与其他的编程语言相比,PHP是将程序嵌入到HTML文档中去执行,执行效率比完全生成HTML标记的CGI要高许多.下面介绍了42个程序的优化准则. 1.如果一个方法可静态化,就对它做静态声明.速率可提升至4倍. 2.echo 比 print 快. 3.使用echo的多重参数(译注:指用逗号而不是句点)代替字符串连接. 4.在执行for循环之前确定最大

冻结时间倒数前一小时,记一次步步惊心的SQL优化

作者介绍 黄浩:从业十年,始终专注于SQL.十年一剑,十年磨砺.3年通信行业,写就近3万条SQL:5年制造行业,遨游在ETL的浪潮:2年性能优化,厚积薄发自成一家.   9月版本是一个大版本,上上下下都在紧锣密鼓地张罗着.   9月10日版本上线,8日开始,能明显的感觉到大战前战鼓擂动人喊马嘶的紧张氛围.项目组人头簇动,奔走如织:邮箱内,关于BUG单通报及处理意见的邮件,在这个骄阳似火的南方,犹如冷冽寒冬时北方的雪花般漫天纷飞.     14:40  主动出击   快下午三点钟的时候,一片雪花悄

一次马失前蹄的SQL优化:递归查询引发的血案

作者介绍 黄浩:从业十年,始终专注于SQL.十年一剑,十年磨砺.3年通信行业,写就近3万条SQL:5年制造行业,遨游在ETL的浪潮:2年性能优化,厚积薄发自成一家.   在上个案例分享时,有读者表示"很想知道,作者失败的时候是怎么办?",并且看热闹不嫌事大,要求"来一篇文章呗".好吧,正所谓,常在河边走,哪有不湿鞋.本人在SQL优化领域摸爬滚打多年,"接客"无数,难免会遇到些难以伺候的"官人",本文就跟大家分享一次不成功的优化

db2-求数据库大神帮忙,SQL优化

问题描述 求数据库大神帮忙,SQL优化 小弟数据库方面的知识非常浅薄,只会写sql语句实现查询,但是确不会做优化,以下有两个sql语句,在数据库中执行的非常慢,DB2,有没有数据库大神,帮忙优化一下,不胜感激. --单证号是否连续 select * from ( select double(replace(c.doc_nbr, 'QZ', '')) as nbr,c.doc_id, b.pip_nbr,c.inv_code,'1' as t from op_bill a,op_bill_deta

数据库SQL优化大总结之 百万级数据库优化方案

网上关于SQL优化的教程很多,但是比较杂乱.近日有空整理了一下,写出来跟大家分享一下,其中有错误和不足的地方,还请大家纠正补充. 这篇文章我花费了大量的时间查找资料.修改.排版,希望大家阅读之后,感觉好的话推荐给更多的人,让更多的人看到.纠正以及补充.   1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id