当前位置：文档之家 › SQL 查询效率

SQL 查询效率

  • 格式：docx
  • 大小：21.63 KB
  • 文档页数：7

很多人不知道SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。

比如：select * from table1 where name='zhangsan' and tID > 10000和执行:select * from table1 where tID > 10000 and name='zhangsan'一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name='zhangsan'的，而后再根据限制条件条件tID>10000来提出查询结果。

事实上，这样的担心是不必要的。

SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。

虽然查询优化器可以根据where子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。

在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。

如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。

SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的AND连接。

形式如下：列名操作符<常数或变量>或<常数或变量> 操作符列名列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。

如：Name=‟张三‟价格>50005000<价格Name=‟张三‟ and 价格>5000如果一个表达式不能满足SARG的形式，那它就无法限制搜索的范围了，也就是SQL SERVER必须对每一行都判断它是否满足WHERE子句中的所有条件。

所以一个索引对于不满足SARG形式的表达式来说是无用的。

介绍完SARG后，我们来总结一下使用SARG以及在实践中遇到的和某些资料上结论不同的经验：1、Like语句是否属于SARG取决于所使用的通配符的类型如：name like …张%‟ ，这就属于SARG而：name like …%张‟ ,就不属于SARG。

原因是通配符%在字符串的开通使得索引无法使用。

2、or 会引起全表扫描Name=‟张三‟ and 价格>5000 符号SARG，而：Name=‟张三‟ or 价格>5000 则不符合SARG。

使用or会引起全表扫描。

3、非操作符、函数引起的不满足SARG形式的语句不满足SARG形式的语句最典型的情况就是包括非操作符的语句，如：NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等，另外还有函数。

下面就是几个不满足SARG形式的例子：ABS(价格)<5000Name like …%三‟有些表达式，如：WHERE 价格*2>5000SQL SERVER也会认为是SARG，SQL SERVER会将此式转化为：WHERE 价格>2500/2但我们不推荐这样使用，因为有时SQL SERVER不能保证这种转化与原始表达式是完全等价的。

4、IN 的作用相当与OR语句：Select * from table1 where tid in (2,3)和Select * from table1 where tid=2 or tid=3是一样的，都会引起全表扫描，如果tid上有索引，其索引也会失效。

5、尽量少用NOT6、exists 和in 的执行效率是一样的很多资料上都显示说，exists要比in的执行效率要高，同时应尽可能的用not exists来代替not in。

但事实上，我试验了一下，发现二者无论是前面带不带not，二者之间的执行效率都是一样的。

因为涉及子查询，我们试验这次用SQL SERVER自带的pubs数据库。

运行前我们可以把SQL SERVER的statistics I/O状态打开。

（1）select title,price from titles where title_id in (select title_id from sales where qty>30)该句的执行结果为：表'sales'。

扫描计数18，逻辑读56 次，物理读0 次，预读0 次。

表'titles'。

扫描计数1，逻辑读2 次，物理读0 次，预读0 次。

（2）select title,price from titles where exists (select * from sales where sales.title_id=titles.title_id and qty>30)第二句的执行结果为：表'sales'。

扫描计数18，逻辑读56 次，物理读0 次，预读0 次。

表'titles'。

扫描计数1，逻辑读2 次，物理读0 次，预读0 次。

我们从此可以看到用exists和用in的执行效率是一样的。

7、用函数charindex()和前面加通配符%的LIKE执行效率一样前面，我们谈到，如果在LIKE前面加上通配符%，那么将会引起全表扫描，所以其执行效率是低下的。

但有的资料介绍说，用函数charindex()来代替LIKE速度会有大的提升，经我试验，发现这种说明也是错误的：select gid,title,fariqi,reader from tgongwen where charindex('刑侦支队',reader)>0 and fariqi>'2004-5-5'用时：7秒，另外：扫描计数4，逻辑读7155 次，物理读0 次，预读0 次。

select gid,title,fariqi,reader from tgongwen where reader like '%' + '刑侦支队' + '%' and fariqi>'2004-5-5'用时：7秒，另外：扫描计数4，逻辑读7155 次，物理读0 次，预读0 次。

8、union并不绝对比or的执行效率高我们前面已经谈到了在where子句中使用or会引起全表扫描，一般的，我所见过的资料都是推荐这里用union来代替or。

事实证明，这种说法对于大部分都是适用的。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' or gid>9990000用时：68秒。

扫描计数1，逻辑读404008 次，物理读283 次，预读392163 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'unionselect gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid>9990000用时：9秒。

扫描计数8，逻辑读67489 次，物理读216 次，预读7499 次。

看来，用union在通常情况下比用or的效率要高的多。

但经过试验，笔者发现如果or两边的查询列是一样的话，那么用union则反倒和用or的执行速度差很多，虽然这里union扫描的是索引，而or扫描的是全表。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' or fariqi='2004-2-5'用时：6423毫秒。

扫描计数2，逻辑读14726 次，物理读1 次，预读7176 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'unionselect gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-2-5'用时：11640毫秒。

扫描计数8，逻辑读14806 次，物理读108 次，预读1144 次。

9、字段提取要按照“需多少、提多少”的原则，避免“select *”我们来做一个试验：select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc用时：4673毫秒select top 10000 gid,fariqi,title from tgongwen order by gid desc用时：1376毫秒select top 10000 gid,fariqi from tgongwen order by gid desc用时：80毫秒由此看来，我们每少提取一个字段，数据的提取速度就会有相应的提升。

提升的速度还要看您舍弃的字段的大小来判断。

10、count(*)不比count(字段)慢某些资料上说：用*会统计所有列，显然要比一个世界的列名效率低。

这种说法其实是没有根据的。

我们来看：select count(*) from Tgongwen用时：1500毫秒select count(gid) from Tgongwen用时：1483毫秒select count(fariqi) from Tgongwen用时：3140毫秒select count(title) from Tgongwen用时：52050毫秒从以上可以看出，如果用count(*)和用count(主键)的速度是相当的，而count(*)却比其他任何除主键以外的字段汇总速度要快，而且字段越长，汇总的速度就越慢。

我想，如果用count(*)，SQL SERVER可能会自动查找最小字段来汇总的。

当然，如果您直接写count(主键)将会来的更直接些。

11、order by按聚集索引列排序效率最高我们来看：（gid是主键，fariqi是聚合索引列）select top 10000 gid,fariqi,reader,title from tgongwen用时：196 毫秒。

合集下载

SQLServer中妙用like提高查询效率

SQLServer中妙用like提高查询效率

SQLServer中妙⽤like提⾼查询效率查询是SQL Server中主要的功⽤，⽽在查询中将Like⽤上，可以搜索到⼀些意想不到的后果和成效，like的神奇之处在于其提供的模糊查询功⽤，议决与它相婚配的四⼤类通配符，like放在条件中起到画龙点睛的作⽤。

⼀、普通搜索条件中⽤Like可与LIKE配对的数据类型⾸要是字符串、⽇期或时间值。

LIKE 主要字可以运⽤惯例表达式包括上⾯三品种型数据，这些数据字符串中可包括下⾯四种通配符的随意组合。

通配符意思% 包括零个或更多字符的随意字符串。

_（下划线）任何单个字符。

[ ] 指定范围（⽐如 [a-f]）或集合（⽐如 [abcdef]）内的任何单个字符。

[^] 不在指定范围（⽐如 [^a - f]）或集合（⽐如 [^abcdef]）内的任何单个字符。

请将通配符和字符串⽤单引号惹起来，⽐如：LIKE '赵%' 将搜索姓赵的⼈名或许说以汉字‘赵’ 开头的字符串（如赵刚、赵⼩刚等）。

LIKE '%刚' 将搜索以汉字‘刚’开头的⼀切字符串（如刘刚、李⼩刚等）。

LIKE '%⼩%' 将搜索在任何位置包括汉字‘⼩’的⼀切字符串（如赵⼩刚、李⼩刚、⼭本⼩郎等）。

LIKE '_⼩刚' 将搜索以汉字“⼩刚”开头的⼀切三个汉字的称号（如李⼩刚、赵⼩刚）。

针对英⽂，情形更多，如LIKE '[CK]ars[eo]n' 将搜索下列字符串：Carsen、Karsen、Carson 和 Karson（如 Carson）。

LIKE '[M-Z]inger' 将搜索以字符串 inger 开头、以从 M 到 Z 的任何单个字母开头的⼀切称号（如 Ringer）。

LIKE 'M[^c]%' 将搜索以字母 M 开头，并且第⼆个字母不是 c 的⼀切称号（如 MacFeather）。

⽐如数据库pubs中有⼀个表author，它的电话号码⼀列即phone这⼀项，那么查找⼀切区号为 010 的电话号码命令为：SELECT phoneFROM pubs.dbo.authorsWHERE phone LIKE '010%'可以⽤⼀样的通配符运⽤ NOT LIKE。

SQL Server查询性能分析与查询效率提高

SQL Server查询性能分析与查询效率提高


则，归纳总结 出 了提 高 Ｓ ＬＳ ｒｅ 数据 库查询效率的方法． Ｑ ｅ ｒ ｖ
关 键 词 ： ＱＬ Ｓ ；查询 ；性 能
中图分类号： Ｐ １ ． Ｔ ３ １ １３
ｄ ｉ １．９９ ．ｓ ． ０ －４ ３２ １．３３ ｏ： ０３ ６ ／ｉ ｎ１ ３２ ８ ． ２ ． ｊｓ ０ ０ ０ ４
１ Ｓ ＬＳｒｅ 查询优化机制 Ｑ ｅｖｒ
Ｓ Ｌ Ｓ Ｒ Ｅ 中有一个“ Ｑ ＥＶ Ｒ 查询分析优化器” ，它能实现 自动优化，即查询提供一个最佳 的执行策略． 对于
ｓ Ｌ 的查询优化器， Ｑ 输入是一条查询语句， 输出是一个执行策略． 一条 Ｓ Ｌ查询语句可以有多种执行策 略， Ｑ 优 化器将会考察解决查询各个部分（ ｗ ｅ 条件、连接和函数） 估计出每个操作 的每项逻辑开销， 如 ｈｒ ｅ ， 并考虑索 引、 硬件 的限制和数据 的统计信息， 执行其中所需时间最少的所谓成本最低 的那一种方法． 虽然查询优化器可 以根
Ｍ ａ ．２ ２ ｙ ０１
。
文 章 编号 ： ０３２ ４ （０２０ － ８－４ １０ —８ ３２ １）３０ ３０ ４
Ｓ ＬＳ ｒｅ 查询性 能分析 与查询效率提高 Ｑ ｅｖｒ
彭 勇
（ 成都纺织高等专科学校电子信息及电气工程 系， 成都 摘 ６１３） １７ １
要 ： 绍 了 Ｓ Ｌ Ｓｒｅ 数据库 中查询优化机制与 索引类型，详细分析 旨在提 高 Ｓ Ｌ查询效率的有效 索引的建立规 介 Ｑ ｅｖ ｒ Ｑ
２ 影 响 Ｓ Ｌ查询语句执行效率 的主要 因素 Ｑ
２１ 是否建有有效的适合可用的索引 ． Ｓ Ｌ 查 询优 化 工作 很大 程 度上 是通 过利 用合 适 的索 引，以便 查询 优化 器可 以使 用快 速 索 引查 找，而 不 是慢 Ｑ 速 的表扫描． 如果没有索引， 查询优化器没有别的选择， 只能扫描表中的每一行 ； 若索引中的索引列 的顺序不是 最佳 的， Ｑ ｒｅ 可能会选择执行索引扫描的方式． Ｓ Ｌｓ ｒ ｅ ｖ Ｓ Ｌｓｒｅ 的索 引结构含有三种组成元素： Ｒ ｏ 节点分页； Ｑ ｖ ｒ ｅ 根（ｏｔ ） 叶子层（ｅｆ ｅｅ ；￣ Ｌ ａ Ｌ ｖ１ ｔ 叶子层（ ｎ Ｌ ａ Ｌ ｖ １ ） Ｎｏ ｅｆ ｅ ｅ） 即介于叶子层与根之 间的结构． 建立 索 引的 Ｓ ＱＬ语 法格 式如 下 ： Ｃ ｅ ｔ ［ＮＩ 】Ｃ ＵＳ Ｅ Ｅ ＮＯ Ｌ Ｔ Ｒ Ｄ］ ｒａｅ Ｕ ＱＥ 【 Ｌ Ｔ Ｒ Ｄ ｌ ＮＣ ＵＳ Ｅ Ｅ Ｉ ＮＤＥ ｄｘ ｎ ｍｅ Ｘ ｉ ｅ— ａ ｎ Ｏ ｛ ｂｅ ｉ （ｏｕ Ｎ ｔ ｌＩ ｅ ｃｌｍｎ［ Ｃｌ Ｓ ］ ．ｎ） ａ ｗ｝ ｖ ＡＳ ＤＥ Ｃ ［． 】 ，．
SQL优化工具及使用技巧介绍

SQL优化工具及使用技巧介绍

SQL优化工具及使用技巧介绍SQL（Structured Query Language）是一种用于管理和操作关系型数据库的编程语言。

它可以让我们通过向数据库服务器发送命令来实现数据的增删改查等操作。

然而，随着业务的发展和数据量的增长，SQL查询的性能可能会受到影响。

为了提高SQL查询的效率，出现了许多SQL优化工具。

本文将介绍一些常见的SQL优化工具及其使用技巧。

一、数据库性能优化工具1. Explain PlanExplain Plan是Oracle数据库提供的一种SQL优化工具，它可以帮助分析和优化SQL语句的执行计划。

通过使用Explain Plan命令，我们可以查看SQL查询的执行计划，了解SQL语句是如何被执行的，从而找到性能瓶颈并进行优化。

2. SQL Server ProfilerSQL Server Profiler是微软SQL Server数据库管理系统的一种性能监视工具。

它可以捕获和分析SQL Server数据库中的各种事件和耗时操作，如查询语句和存储过程的执行情况等。

通过使用SQL Server Profiler，我们可以找到数据库的性能瓶颈，并进行相应的优化。

3. MySQL Performance SchemaMySQL Performance Schema是MySQL数据库提供的一种性能监视工具。

它可以捕获和分析MySQL数据库中的各种事件和操作，如查询语句的执行情况、锁的状态等。

通过使用MySQL Performance Schema，我们可以深入了解数据库的性能问题，并对其进行优化。

二、SQL优化技巧1. 使用索引索引是提高SQL查询性能的重要手段之一。

在数据库中创建合适的索引可以加快查询操作的速度。

通常，我们可以根据查询条件中经常使用的字段来创建索引。

同时，还应注意索引的维护和更新，避免过多或过少的索引对性能产生负面影响。

2. 避免全表扫描全表扫描是指对整个表进行扫描，如果表中数据量较大，查询性能会受到较大影响。

SQLSERVER视图对查询效率的提高

SQLSERVER视图对查询效率的提高

SQLSERVER视图对查询效率的提⾼SQL SERVER视图不仅可以实现许多我们需要的功能，⽽且对于SQL SERVER查询效率的提⾼也有帮助，下⾯⼀起来了解⼀下。

有两张数据表：A和B，其中A的记录为2万条左右，⽽B中的数据为200万条以上，现在要求以a.id=b.id为关联进⾏数据筛选。

为此要求，我做了个SQL SERVER视图View1，将a.id与b.id关联起来，运⾏该视图的查询，使⽤了2秒中就得到结果了。

这时⼜有⼀特殊需求：编写存储过程，该存储过程中有⼀个游标的循环，该循环重复1万次，在每次循环中都使⽤了对View1的查询。

举例如下： 循环游标体(重复1万次)以下是代码⽚段：{ select @text=text from view1 whereid=@id --其中@text,@id均为变量update form1 set text=@text where id=@id} 执⾏以上的存储过程，发现竟然要花费>7分钟的运算时间，进⾏分析后得知效率全损耗在对view1视图的扫描上，尽管单独对该视图进⾏查询只需2秒，但在这种情况下即需要太多的时间。

因此改进该存储过程如下：以下是代码⽚段：create table #tempTab( id nvarchar(20), text nvarchar(20)) 查询View1视图，将记录插⼊到#tempTab临时表中... 循环游标体(重复1万次)以下是代码⽚段：{ select @text=text from #tempTab whereid=@id --其中@text,@id均为变量update form1 set text=@text where id=@id} 别⼩瞧以上的改动，此时该存储过程只花费50秒的时间。

对于上述现象，分析如下：在多次循环对某个视图进⾏查询时，将会耗费⼤量的时间，因此将该视图的数据放在内存中进⾏计算会在很⼤程度上提⾼速度。