关闭

SARG

5595人阅读 评论(0) 收藏 举报

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

目录

形式
问题
  1. 通配符
  2. 全表扫描
  3. 非操作符
  4. IN 相当与OR
  5. exists 和 in 的执行效率
  6. 用函数和通配符效率
函数
  1. 数据
  2. union比or
  3. 避免select
  4. count不比count慢
  5. 排序效率最高
  6. 高效的TOP
展开

编辑本段形式

  如下:
  列名 操作符 <常数 或 变量>
  或
  <常数 或 变量> 操作符列名列名可以出现在操作符的一边,而常数或变量出现在操作符的另一边。如:
  Name=’张三’
  价格>5000
  5000<价格
  Name=’张三’ and 价格>5000 如果一个表达式不能满足SARG的形式,那它就无法限制搜索的范围了,也就是SQL SERVER必须对每一行都判断它是否满足WHERE子句中的所有条件。所以一个索引对于不满足SARG形式的表达式来说是无用的。
  如果一个阶段可以被用作一个扫描参数(SARG),那么就称之为可优化的,并且可以利用索引快速获得所需数据。

编辑本段问题

通配符

  Like语句是否属于SARG取决于所使用的通配符的类型
  如:name like ‘张%’ ,这就属于SARG
  而:name like ‘%张’ ,就不属于SARG。
  原因是通配符%在字符串的开通使得索引无法使用。

全表扫描

  如:Name=’张三’ and 价格>5000 符号SARG,
  而:Name=’张三’ or 价格>5000 则不符合SARG。
  使用or会引起全表扫描。

非操作符

  不满足SARG形式的语句最典型的情况就是包括非操作符的语句,如:NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等,另外还有函数。下面就是几个不满足SARG形式的例子:
  ABS(价格)<5000
  Name like ‘%三’
  有些表达式,如:
  WHERE 价格*2>5000
  SQL SERVER也会认为是SARG,SQL SERVER会将此式转化为:
  WHERE 价格>2500/2
  但我们不推荐这样使用,因为有时SQL SERVER不能保证这种转化与原始表达式是完全等价的。

IN 相当与OR

  语句:
  Select * from table1 where tid in (2,3)
  和
  Select * from table1 where tid=2 or tid=3
  是一样的,都会引起全表扫描,如果tid上有索引,其索引也会失效。
  尽量少用NOT

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的执行效率是一样的。

用函数和通配符效率

  前面,我们谈到,如果在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 次。

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'
  union
  select 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'
  union
  select gid,fariqi,neibuyonghu,reader,title from Tgongwen
  where fariqi='2004-2-5'
  用时:11640毫秒。扫描计数 8,逻辑读 14806 次,物理读 108 次,预读 1144 次。

避免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毫秒
  由此看来,我们每少提取一个字段,数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。

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(主键)将会来的更直接些。

排序效率最高

  我们来看:(gid是主键,fariqi是聚合索引列)
  select top 10000 gid,fariqi,reader,title from tgongwen
  用时:196 毫秒。 扫描计数 1,逻辑读 289 次,物理读 1 次,预读 1527 次。
  select top 10000 gid,fariqi,reader,title from tgongwen order by gid asc
  用时:4720毫秒。 扫描计数 1,逻辑读 41956 次,物理读 0 次,预读 1287 次。
  select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc
  用时:4736毫秒。 扫描计数 1,逻辑读 55350 次,物理读 10 次,预读 775 次。
  select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi asc
  用时:173毫秒。 扫描计数 1,逻辑读 290 次,物理读 0 次,预读 0 次。
  select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc
  用时:156毫秒。 扫描计数 1,逻辑读 289 次,物理读 0 次,预读 0 次。
  从以上我们可以看出,不排序的速度以及逻辑读次数都是和“order by 聚集索引列” 的速度是相当的,但这些都比“order by 非聚集索引列”的查询速度是快得多的。
  同时,按照某个字段进行排序的时候,无论是正序还是倒序,速度是基本相当的。

高效的TOP

  事实上,在查询和提取超大容量的数据集时,影响数据库响应时间的最大因素不是数据查找,而是物理的I/0操作。如:
  select top 10 * from (
  select top 10000 gid,fariqi,title from tgongwen
  where neibuyonghu='办公室'order by gid desc) as a
  order by gid asc
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:545691次
    • 积分:8915
    • 等级:
    • 排名:第2220名
    • 原创:305篇
    • 转载:69篇
    • 译文:0篇
    • 评论:13条
    文章分类
    最新评论