【转】SQL Server 索引结构及其使用(二)

SQL Server 索引结构及其使用(二) 

作者:freedk

一、深入浅出理解索引结构 

改善SQL语句 

  很多人不知道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、尽量少用NOT 

6、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'' 
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 次。 

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 毫秒。 扫描计数 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 非聚集索引列”的查询速度是快得多的。 
  同时,按照某个字段进行排序的时候,无论是正序还是倒序,速度是基本相当的。 

12、高效的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

  这条语句,从理论上讲,整条语句的执行时间应该比子句的执行时间长,但事实相反。因为,子句执行后返回的是10000条记录,而整条语句仅返回10条语句,所以影响数据库响应时间最大的因素是物理I/O操作。而限制物理I/O操作此处的最有效方法之一就是使用TOP关键词了。TOP关键词是SQL SERVER中经过系统优化过的一个用来提取前几条或前几个百分比数据的词。经笔者在实践中的应用,发现TOP确实很好用,效率也很高。但这个词在另外一个大型数据库ORACLE中却没有,这不能说不是一个遗憾,虽然在ORACLE中可以用其他方法(如:rownumber)来解决。在以后的关于“实现千万级数据的分页显示存储过程”的讨论中,我们就将用到TOP这个关键词。 
  到此为止,我们上面讨论了如何实现从大容量的数据库中快速地查询出您所需要的数据方法。当然,我们介绍的这些方法都是“软”方法,在实践中,我们还要考虑各种“硬”因素,如:网络性能、服务器的性能、操作系统的性能,甚至网卡、交换机等。 

文章引自:http://www.vckbase.com/document/viewdoc/?id=1308

转载于:https://www.cnblogs.com/gebenhagen/archive/2011/10/22/2221086.html

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/495271.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Dota 2被攻陷!OpenAI 人工智能5V5模式击败人类玩家(4000分水平)

来源&#xff1a;机器之心摘要&#xff1a;我们团队构建的模型&#xff0c;OpenAI Five&#xff0c;已经击败业余 Dota2 团队了。虽然如今是在有限制的情况下&#xff0c;但我们计划到 8 月份在有限英雄池下击败 TI 赛中的一支顶级专业队伍。我们团队构建的模型&#xff0c;Ope…

使用 mitmproxy + python 做拦截代理

From&#xff1a;https://blog.wolfogre.com/posts/usage-of-mitmproxy https://www.cnblogs.com/H4ck3R-XiX/p/12624072.html http://www.cnblogs.com/grandlulu/p/9525417.html mitmProxy 介绍&#xff1a;https://blog.csdn.net/h416756139/article/details…

ZeroMQ全面介绍

★ZMQ是啥玩意儿&#xff1f;   通俗地说&#xff0c;ZMQ是一个开源的、跨语言的、非常简洁的、非常高性能、非常灵活的网络通讯库。它的官方网站在"这里"&#xff0c;维基百科的介绍在"这里"&#xff08;暂时没有中文的维基词条&#xff09;。这玩意儿推…

Android IDA 动态调试最完善攻略,跨过各种坑

From&#xff1a;https://www.pianshen.com/article/3409449384/ IDA 静态分析 与 动态分析&#xff1a;https://zhuanlan.zhihu.com/p/38983223 新手向总结&#xff1a;IDA 动态调试 So 的一些坑&#xff1a;https://zhuanlan.zhihu.com/p/145383282 Android 逆向之旅 --- …

一场科技盛宴,一次“盈”满天下 安创成长营五期Demo Day完美收官

2018年6月21日&#xff0c;安创成长营第五期Demo Day在北京金隅喜来登拉开帷幕&#xff0c;16家安创成长营五期成员代表齐齐亮相&#xff0c;为资本圈带来了一场集科技、创新、前瞻于一体的项目展示。数百数位业内有影响力的Arm生态系统的合作伙伴、知名品牌厂商创新事业部负责…

安卓逆向_25 --- 密码学 之 《Java加密与解密的艺术》

《Java加密与解密的艺术》中文 PDF版 &#xff1a;https://www.jb51.net/books/65048.html 1. 密码学应用 &#xff1a;https://www.bilibili.com/video/BV1oA411J7Lb?p1 密码学应用 密码学的基本概念&#xff0c;对称密码&#xff0c;公钥密码&#xff0c;Hash算法&#xff…

使用 NetDataContractSerializer 共享类型

在上一章节《WCF可序列化方式》 提到了NetDataContractSerializer 适用于客户端与服务端共享类型信息&#xff0c;支持支持类型不变性。 但并没有提供现成的特性&#xff0c;所以无法使用对数据契约进行标记的方式来达到使用NetDataContractSerializer的目的&#xff0c;必须通…

深度丨一文读懂智能制造的主线——智能生产(工厂/车间数字化)

来源&#xff1a; 亿欧摘要&#xff1a; 发展智能制造对于中国制造业乃至中国经济的重要性不言而喻&#xff0c;先进制造业作为深耕制造业领域的专业媒体&#xff0c;长期关注智能制造发展&#xff0c;助力中国制造转型升级&#xff0c;努力做“中国制造2025”的推动者。近年来…

最好用的十六进制编辑器 010 Editor

最好用的十六进制编辑器010 Editor https://blog.csdn.net/qq_38482805/article/details/89309120 新版010Edit注册机&去除网络验证&#xff1a;https://bbs.pediy.com/thread-249724.htm 010Editor脚本语法入门&#xff1a;https://www.jianshu.com/p/ba60ebd8f916 宇宙…

Object to XML

摘要&#xff1a;本节主要介绍如何把Object对象转换为XML 引言&#xff1a;最近工作中因为工作需要&#xff0c;需要把两个系统之间的传递的报文修改一下&#xff08;现在系统之间一般都是通过发送xml字符串传数据吧&#xff09;&#xff0c;最开始用的Jdom来实现的&#xff0c…

Science:发现重写创伤记忆的神经元

来源&#xff1a;生物谷摘要&#xff1a;对创伤经历的回忆会导致精神健康问题&#xff0c;如创伤后应激障碍&#xff08;PTSD&#xff09;&#xff0c;这会破坏一个人的生活。对创伤经历的回忆会导致精神健康问题&#xff0c;如创伤后应激障碍&#xff08;PTSD&#xff09;&…

安卓逆向_23 --- Hook 框架 Cydia Substrate( Hook Java层 和 so层)

From&#xff1a;Android Hook 框架 Cydia_substrate 详解&#xff1a;https://www.cnblogs.com/lkislam/p/4859957.html 通过 cydia substrate 对 framework API进行注入&#xff1a;https://www.jianshu.com/p/cc49b30c5b5b Android 逆向之旅 --- Native层的Hook神器Cydia …

数据结构C语言实现—队列操作

1 #include <stdio.h> 2 #include <stdlib.h> 3 4 typedef int elemType; 5 /************************************************************************/ 6 /* 以下是关于队列链接存储操作的6种算法 */ 7 /********************************************…

高校人工智能热的“冷”思考

来源&#xff1a;中国科学报高校在开设相关专业时&#xff0c;应该组织教授委员会、学术委员会&#xff0c;结合国家的人才政策、产业发展对人才的需求、国内外其他高校同类专业人才培养的情况&#xff0c;就本校开设这方面的专业有无现实条件&#xff0c;怎样进行师资建设、课…

转载:实用 FRIDA 进阶 --- objection :内存漫游、hook anywhere、抓包

转载&#xff1a;实用FRIDA进阶&#xff1a;内存漫游、hook anywhere、抓包&#xff1a;https://www.anquanke.com/post/id/197657 Frida Hook Android 常用方法&#xff1a;https://blog.csdn.net/zhy025907/article/details/89512096 实用FRIDA进阶&#xff1a;脱壳、自动化…

谷歌李飞飞:我们依旧站在人工智能研究的起点

来源&#xff1a;机器人大讲堂摘要&#xff1a;8 年来&#xff0c;在 ImageNet 数据集的训练下&#xff0c;人工智能对于图像识别的准确度整整提高了 10 倍&#xff0c;甚至超越了人类视觉本身。但李飞飞认为&#xff0c;我们对于人工智能的研究仍在起点上。说起人工智能&#…

Android Intent 用法总结

From&#xff1a;https://www.jianshu.com/p/67d99a82509b Android 中提供了 Intent 机制来协助应用间的交互与通讯&#xff0c;Intent 负责对应用中一次操作的动作、动作涉及数据、附加数据进行描述&#xff0c;Android 则根据此 Intent 的描述&#xff0c;负责找到对应的组件…

teamlab与redmine试用对比报告

系统介绍 l TeamLab 是一个免费开源的商业协作和项目管理的平台。TeamLab 主要功能包括&#xff1a;项目管理、里程碑管理、任务、报表、事件、博客、论坛、书签、Wiki、即时消息等等。 l Redmine 是一个开源的、基于Web的项目管理和缺陷跟踪工具。它用日历和甘特图辅助项目及…

FRIDA - API使用篇:rpc、Process、Module、Memory 使用方法及示例

官方 API (JavaScript API)&#xff1a;https://frida.re/docs/javascript-api/ From&#xff1a; ( FRIDA-API使用篇 )&#xff1a;https://www.anquanke.com/post/id/195215 前言 在这篇文章中来对其官方的一些非常常用的 API 进行学习。所谓工欲善其事&#xff0c;必先利其…

Entity Framework 实体关系总结(转)

通过 Entiy Framework实践系列文章&#xff0c;理了理 Entity Framework 的实体关系。 为什么要写文章来理清这些关系&#xff1f;“血”的教训啊&#xff0c;刚开始使用 Entity Framework 的时候&#xff0c;由于没有静下心来认真理清关系&#xff0c;走了一些"痛不欲生&…