编写高性能的SQL语句注意事项.doc

编写高性能的SQL语句注意事项 28/28 编写高性能的SQL语句注意事项 在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。 在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引，这有助于写出高性能的SQL语句。 SQL语句编写注意问题 下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。 1. IS NULL 与 IS NOT NULL 不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。 任何在where子句中使用is null或is not null的语句优化器是不允许使用索引的。 2. 联接列 对于有联接的列，即使最后的联接值为一个静态值，优化器是不会使用索引的。我们一起来看一个例子，假定有一个职工表（employee），对于一个职工的姓和名分成两列存放（FIRST_NAME和LAST_NAME），现在要查询一个叫比尔.克林顿（Bill Cliton）的职工。 下面是一个采用联接查询的SQL语句， select * from employss where first_name||''||last_name ='Beill Cliton' 上面这条语句完全可以查询出是否有Bill Cliton这个员工，但是这里需要注意，系统优化器对基于last_name创建的索引没有使用。 当采用下面这种SQL语句的编写，Oracle系统就可以采用基于last_name创建的索引。 Select * from employee where first_name ='Beill' and last_name ='Cliton' 遇到下面这种情况又如何处理呢？如果一个变量（name）中存放着Bill Cliton这个员工的姓名，对于这种情况我们又如何避免全程遍历，使用索引呢？可以使用一个函数，将变量name中的姓和名分开就可以了，但是有一点需要注意，这个函数是不能作用在索引列上。下面是SQL查询脚本： select * from employee where first_name = SUBSTR('&&name',1,INSTR('&&name',' ')-1) and last_name = SUBSTR('&&name',INSTR('&&name’,' ')+1) 3. 带通配符（%）的like语句 同样以上面的例子来看这种情况。目前的需求是这样的，要求在职工表中查询名字中包含cliton的人。可以采用如下的查询SQL语句： select * from employee where last_name like '%cliton%' 这里由于通配符（%）在搜寻词首出现，所以Oracle系统不使用last_name的索引。在很多情况下可能无法避免这种情况，但是一定要心中有底，通配符如此使用会降低查询速度。然而当通配符出现在字符串其他位置时，优化器就能利用索引。在下面的查询中索引得到了使用： select * from employee where last_name like 'c% 4. Order by语句 ORDER BY语句决定了Oracle如何将返回的查询结果排序。Order by语句对要排序的列没有什么特别的限制，也可以将函数加入列中（象联接或者附加等）。任何在Order by语句的非索引项或者有计算表达式都将降低查询速度。 仔细检查order by语句以找出非索引项或者表达式，它们会降低性能。解决这个问题的办法就是重写order by语句以使用索引，也可以为所使用的列建立另外一个索引，同时应绝对避免在order by子句中使用表达式。 5. NOT 我们在查询时经常在where子句使用一些逻辑表达式，如大于、小于、等于以及不等于等等，也可以使用and（与）、or（或）以及not（非）。NOT可用来对任何逻辑运算符号取反。下面是一个NOT子句的例子： ... where not (status ='VALID') 如果要使用NOT，则应在取反的短语前面加上括号，并在短语前面加上NOT运算符。NOT运算符包含在另外一个逻辑运算符中，这就是不等于（<>）运算符。换句话说，即使不在查询where子句中显式地加入NOT词，NOT仍在运算符中，见下例： ... where status <>'INVALID' 再看下面这个例子： select * from employee where salary<>3000; 对这个查询，可以改写为不使用NOT： select * from employee where salary<3000 or salary>3000; 虽然这两种查询的结果一样，但是第二种查询方案会比第一种查询方案更快些。第二种查询允许Oracle对salary列使用索引，而第一种查询则不能使用索引。 6. IN和EXISTS 有时候会将一列和一系列值相比较。最简单的办法就是在where子句中使用子查询。在where子句中可以使用两种格式的子查询。 第一种格式是使用IN操作符： ... where column in(select * from ... where ...); 第二种格式是使用EXIST操作符： ... where exists (select 'X' from ...where ...); 我相信绝大多数人会使用第一种格式，因为它比较容易编写，而实际上第二种格式要远比第一种格式的效率高。在Oracle中可以几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。 第二种格式中，子查询以‘select 'X'开始。运用EXISTS子句不管子查询从表中抽取什么数据它只查看where子句。这样优化器就不必遍历整个表而仅根据索引就可完成工作（这里假定在where语句中使用的列存在索引）。相对于IN子句来说，EXISTS使用相连子查询，构造起来要比IN子查询困难一些。 通过使用EXIST，Oracle系统会首先检查主查询，然后运行子查询直到它找到第一个匹配项，这就节省了时间。Oracle系统在执行IN子查询时，首先执行子查询，并将获得的结果列表存放在在一个加了索引的临时表中。在执行子查询之前，系统先将主查询挂起，待子查询执行完毕，存放在临时表中以后再执行主查询。这也就是使用EXISTS比使用IN通常查询速度快的原因。 同时应尽可能使用NOT EXISTS来代替NOT IN，尽管二者都使用了NOT（不能使用索引而降低速度），NOT EXISTS要比NOT IN查询效率更高。(T004) SQL技巧：使用SQL子选择来合并查询 你是否曾经为了得到所需要的信息而反复查询？子选择，也被称为子查询，也许正是你在寻找的。SQL的这项功能使你可以在一组结果中查询，创造性地给结果组加以限定，或是在向数据库的单一调用中将结果与一个无关系的查询做相关。这篇文章中我将给出几个子选择的例子并就何时使用他们进行讨论。 在一个结果组中搜索 子选择的理念很简单：一个选择查询安置在另一个查询内部，创建一个在单一声明搜索中不可用的资源。子选择允许查询的合并，结果组比较的责任落到了数据库中而不是应用软件代码中。 使用这个功能的一个途径是对两个表格中的可比数据专栏中的值进行定位。例如，我的一个数据库有两个表格，Album和Lyric。我可以很容易地通过下面的子查询声明来找到每一个Metallica的歌曲中包含“justice”的歌名： SELECT song_name FROM Album WHERE band_name = ‘Metallica’ AND song_name IN (SELECT song_name FROM Lyric WHERE song_lyric LIKE ‘%justice%’); 这个例子是很简单的，我从Album表格中选择了所有Metallica的歌曲，接着，我在lyric表格中选择所有包含“justice”的歌曲，最后，我使用IN关键字来从Lyric表格结果组中显示的Album表格中返回歌曲名称。 我使用Lyric表格结果组来给Album表格中的结果做限定。WHERE子句中的子选择部分是完全自包含的，因此我不需要使用例如Album.song_name和Lyric.song_name等完整的专栏名称。我没有从最终结果组的Lyric表格中返回任何值，如果我需要歌曲的Lyric，我会使用一个JOIN声明。 使用NOT IN排除结果 你可以使用NOT IN关键字来获得明确地不被包含在另一个结果组中的结果。例如，我想要通过下面的代码来返回Metallica在“And Justice for All”专辑中不包含单词“justice”的歌曲： SELECT song_name FROM Album WHERE album_name = ‘And Justice for All’ AND band_name = ‘Metallica’ AND song_name NOT IN (SELECT song_name FROM Lyric WHERE song_lyric LIKE ‘%justice%’); 在前面的SQL代码中，我选择了Metallica的“And Justice for All,”专辑中的所有歌曲，接着是带有歌词中带有“justice”所有歌曲，最后从在Lyric结果组中没有出现的Album结果组返回了所有歌曲。较之于返回两个查询并使用代码来比较数组，你通过一个单独的声明就可以得到确切的结果。 使用EXISTS来相关结果 有时你可以通过多种途径来访问相同的数据，而且你需要对你的结果进行匹配（或相关）来得到值的交叉区。例如，我可以通过搜索Album表格来得到Metallica的歌曲列表，可是，我也可以从我的Cover表格中得到由Damage, Inc表演的Metallica的歌曲的列表，我可以在两个表格中直接比较查询结果来对值作相关。 SELECT Album.song_name FROM Album WHERE Album.band_name = ‘Metallica’ AND EXISTS (SELECT Cover.song_name FROM Cover WHERE Cover.band_name = ‘Damage, Inc.’ AND Cover.song_name = Album.song_name); 在SQL代码中，我使用完整的专栏名称，这是因为我直接对两个表格作比较，而不仅仅是将结果组作为一个被动资源来使用。我并不从Cover表格中返回结果。一些数据库支持NOT EXISTS关键字来确保你并没有匹配。 使用合计函数来比较 除了使用子选择在相关的表格中检查数据，你还可以在一个WHERE子选择中使用合计函数来确定主结果组。例如，我想要核实每一个Metallica歌曲在Album表格中的条目。而且，我还想返回缺少歌曲的专辑的名称。很方便地，AlbumInfo表格包含的一个专栏(album_tracks)给出了应该有多少首歌曲方面的信息。 SELECT AlbumInfo.album_name FROM AlbumInfo WHERE AlbumInfo.band_name = ‘Metallica’ AND album_tracks <> (SELECT COUNT(*) FROM Album WHERE Album.album_name = AlbumInfo.album_name); 现在我已经成功地返回了所有Metallica的专辑中，应有的曲目数量与Album表格中实际的歌曲条目数量不符的专辑名称。 返回子选择结果 如果我还是关心每一张专辑的曲目数量并需要得到一个比较报告怎么办？你可以将一个子选择的结果作为最终结果组的一部分来返回。这个功能经常被合计函数所使用。通常地，对其他表格的访问可以作为你的查询的一部分。下一个例子将返回每一张Metallica的专辑，应该包括的曲目数量和在Album表格中包括的条目数量： SELECT AlbumInfo.album_name, album_tracks, (SELECT COUNT(*) FROM Album WHERE Album.album_name = AlbumInfo.album_name) FROM AlbumInfo WHERE AlbumInfo.band_name = ‘Metallica’; 另一个强有力的例子涉及了在AlbumInfo表格中将album_tracks值改变为在Album表格中实际的条目数量： UPDATE AlbumInfo SET album_tracks = SELECT COUNT(*) FROM Album WHERE AlbumInfo.album_name = Album.album_name) WHERE AlbumInfo.band_name = ‘Metallica’; 在上两个例子中的子选择声明被看作一个自包含单位来执行。 子选择比较关键字(ALL, SOME, ANY) 除了使用标准查询功能，还有三个关键字可以使你将一个表达式值和一个单栏子选择声明结果组作比较，这些关键字返回TRUE或FALSE的Boolean值。ALL关键字要求子选择中所有值都遵守比较运算符。SOME和ANY关键字则要求至少一对。这里是ALL关键字的一个简单实例。 SELECT * FROM AlbumSales WHERE album_gross > ALL (SELECT album_costs FROM AlbumProduction); 上面的例子将从AlbumSales表格返回在AlbumProduction表格里面付出总额大于成本而生产最昂贵的专辑的所有记录。如果用ANY替代ALL，声明将返回所有付出总额大于最低专辑成本的专辑记录。声明= ANY与IN关键字意义是相同的。声明<> ALL与NOT IN关键字是对等的。关键字ANY和SOME也是等同的。数据库生产商中对这些关键字的支持情况是不同的，因此在出现问题时要相信查阅生产商方面的资料。(T004) 数据库优化之让你的SQL运行得更快 人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。笔者在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。在对它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个方面分别进行总结： 为了更直观地说明问题，所有实例中的SQL运行时间均经过测试，不超过１秒的均表示为（< 1秒）。 一、不合理的索引设计 例：表record有620000行，试看在不同的索引下，下面几个 SQL的运行情况： 1.在date上建有一非个群集索引 　　select count(*) from record where date > 　　'19991201' and date < '19991214'and amount > 　　2000 (25秒) 　　select date,sum(amount) from record group by date 　　(55秒) 　　select count(*) from record where date > 　　'19990901' and place in ('BJ','SH') (27秒) 分析：date上有大量的重复值，在非群集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描才能找到这一范围内的全部行。 2.在date上的一个群集索引 　　select count(*) from record where date > 　　'19991201' and date < '19991214' and amount > 　　2000 （14秒） 　　select date,sum(amount) from record group by date 　　（28秒） 　　select count(*) from record where date > 　　'19990901' and place in ('BJ','SH')（14秒） 分析：在群集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。 3.在place，date，amount上的组合索引 　　select count(*) from record where date > 　　'19991201' and date < '19991214' and amount > 　　2000 （26秒） 　　select date,sum(amount) from record group by date 　　（27秒） 　　select count(*) from record where date > 　　'19990901' and place in ('BJ, 'SH')（< 1秒） 分析：这是一个不很合理的组合索引，因为它的前导列是place，第一和第二条SQL没有引用place，因此也没有利用上索引；第三个SQL使用了place，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。 4.在date，place，amount上的组合索引 　　select count(*) from record where date > 　　'19991201' and date < '19991214' and amount > 　　2000(< 1秒) 　　select date,sum(amount) from record group by date 　　（11秒） 　　select count(*) from record where date > 　　'19990901' and place in ('BJ','SH')（< 1秒） 分析：这是一个合理的组合索引。它将date作为前导列，使每个SQL都可以利用索引，并且在第一和第三个SQL中形成了索引覆盖，因而性能达到了最优。 总结 缺省情况下建立的索引是非群集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测上。一般来说: ①.有大量重复值、且经常有范围查询（between, >,< ，>=,< =）和order by、group by发生的列，可考虑建立群集索引； ②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引； ③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。 二、不充份的连接条件 例：表card有7896行，在card_no上有一个非聚集索引，表account有191122行，在 account_no上有一个非聚集索引，试看在不同的表连接条件下，两个SQL的执行情况： 　　select sum(a.amount) from account a, 　　card b where a.card_no = b.card_no（20秒） 　　---- 将SQL改为： 　　select sum(a.amount) from account a, 　　card b where a.card_no = b.card_no and a. 　　account_no=b.account_no（< 1秒） 分析：在第一个连接条件下，最佳查询方案是将account作外层表，card作内层表，利用card上的索引，其I/O次数可由以下公式估算为： 外层表account上的22541页+（外层表account的191122行*内层表card上对应外层表第一行所要查找的3页）=595907次I/O。 在第二个连接条件下，最佳查询方案是将card作外层表，account作内层表，利用account上的索引，其I/O次数可由以下公式估算为： 外层表card上的1944页+（外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O。 可见，只有充份的连接条件，真正的最佳方案才会被执行。 总结 1.多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。 2.查看执行方案的方法-- 用set showplanon，打开showplan选项，就可以看到连接顺序、使用何种索引的信息；想看更详细的信息，需用sa角色执行dbcc(3604,310,302)。 三、不可优化的where子句 1.例：下列SQL条件语句中的列都建有恰当的索引，但执行速度却非常慢： 　　select * from record where 　　substring(card_no,1,4)='5378'(13秒) 　　select * from record where 　　amount/30< 1000（11秒） 　　select * from record where 　　convert(char(10),date,112)='19991201'（10秒） 分析：where子句中对列的任何操作结果都是在SQL运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被SQL优化器优化，使用索引，避免表搜索，因此将SQL重写成下面这样： 　　select * from record where card_no like 　　'5378%'（< 1秒） 　　select * from record where amount 　　< 1000*30（< 1秒） 　　select * from record where date= '1999/12/01' 　　（< 1秒> 你会发现SQL明显快起来！ 2.例：表stuff有200000行，id_no上有非群集索引，请看下面这个SQL： 　　select count(*) from stuff where id_no in('0','1') （23秒） 分析：where条件中的'in'在逻辑上相当于'or'，所以语法分析器会将in ('0','1')转化为id_no ='0' or id_no='1'来执行。我们期望它会根据每个or子句分别查找，再将结果相加，这样可以利用id_no上的索引；但实际上（根据showplan）,它却采用了"OR策略"，即先取出满足每个or子句的行，存入临时数据库的工作表中，再建立唯一索引以去掉重复行，最后从这个临时表中计算结果。因此，实际过程没有利用id_no上索引，并且完成时间还要受tempdb数据库性能的影响。 实践证明，表的行数越多，工作表的性能就越差，当stuff有620000行时，执行时间竟达到220秒！还不如将or子句分开： select count(*) from stuff where id_no='0' select count(*) from stuff where id_no='1' 得到两个结果，再作一次加法合算。因为每句都使用了索引，执行时间只有3秒，在620000行下，时间也只有4秒。或者，用更好的方法，写一个简单的存储过程： 　　create proc count_stuff as 　　declare @a int 　　declare @b int 　　declare @c int 　　declare @d char(10) 　　begin 　　select @a=count(*) from stuff where id_no='0' 　　select @b=count(*) from stuff where id_no='1' 　　end 　　select @c=@a+@b 　　select @d=convert(char(10),@c) 　　print @d 直接算出结果，执行时间同上面一样快！ 总结 可见，所谓优化即where子句利用了索引，不可优化即发生了表扫描或额外开销。 1.任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。 2.in、or子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把子句拆开；拆开的子句中应该包含索引。 3.要善于使用存储过程，它使SQL变得更加灵活和高效。 从以上这些例子可以看出，SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。 怎样使你的SQL运行得更加灵活和高效 人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。笔者在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。在对它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个方面分别进行总结： 为了更直观地说明问题，所有实例中的SQL运行时间均经过测试，不超过１秒的均表示为（< 1秒）。 测试环境 主机：HP LH II 主频：330MHZ 内存：128兆 操作系统：Operserver5.0.4 数据库：Sybase11.0.3 一、不合理的索引设计 例：表record有620000行，试看在不同的索引下，下面几个 SQL的运行情况： 1.在date上建有一非个群集索引 select count(*) from record where date > '19991201' and date < '19991214'and amount > 2000 (25秒) select date,sum(amount) from record group by date (55秒) select count(*) from record where date > '19990901' and place in ('BJ','SH') (27秒) 分析： date上有大量的重复值，在非群集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描才能找到这一范围内的全部行。 2.在date上的一个群集索引 select count(*) from record where date > '19991201' and date < '19991214' and amount > 2000 （14秒） select date,sum(amount) from record group by date （28秒） select count(*) from record where date > '19990901' and place in ('BJ','SH')（14秒） 分析： 在群集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。 3.在place，date，amount上的组合索引 select count(*) from record where date > '19991201' and date < '19991214' and amount > 2000 （26秒） select date,sum(amount) from record group by date （27秒） select count(*) from record where date > '19990901' and place in ('BJ, 'SH')（< 1秒） 分析： 这是一个不很合理的组合索引，因为它的前导列是place，第一和第二条SQL没有引用place，因此也没有利用上索引；第三个SQL使用了place，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。 4.在date，place，amount上的组合索引 select count(*) from record where date > '19991201' and date < '19991214' and amount > 2000(< 1秒) select date,sum(amount) from record group by date （11秒） select count(*) from record where date > '19990901' and place in ('BJ','SH')（< 1秒） 分析： 这是一个合理的组合索引。它将date作为前导列，使每个SQL都可以利用索引，并且在第一和第三个SQL中形成了索引覆盖，因而性能达到了最优。 5.总结： 缺省情况下建立的索引是非群集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测上。一般来说： ①.有大量重复值、且经常有范围查询（between, >,< ，>=,< =）和order by、group by发生的列，可考虑建立群集索引； ②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引； ③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。 二、不充份的连接条件： 例：表card有7896行，在card_no上有一个非聚集索引，表account有191122行，在account_no上有一个非聚集索引，试看在不同的表连接条件下，两个SQL的执行情况： select sum(a.amount) from account a, card b where a.card_no = b.card_no（20秒） 将SQL改为： select sum(a.amount) from account a,card b where a.card_no = b.card_no and a.account_no=b.account_no（< 1秒） 分析： 在第一个连接条件下，最佳查询方案是将account作外层表，card作内层表，利用card上的索引，其I/O次数可由以下公式估算为： 外层表account上的22541页+（外层表account的191122行*内层表card上对应外层表第一行所要查找的3页）=595907次I/O在第二个连接条件下，最佳查询方案是将card作外层表，account作内层表，利用account上的索引，其I/O次数可由以下公式估算为： 外层表card上的1944页+（外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O。可见，只有充份的连接条件，真正的最佳方案才会被执行。 总结： 1.多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。 2.查看执行方案的方法-- 用set showplanon，打开showplan选项，就可以看到连接顺序、使用何种索引的信息；想看更详细的信息，需用sa角色执行dbcc(3604,310,302)。 三、不可优化的where子句 1.例：下列SQL条件语句中的列都建有恰当的索引，但执行速度却非常慢： select * from record where substring(card_no,1,4)='5378'(13秒) select * from record where amount/30< 1000（11秒） select * from record where convert(char(10),date,112)='19991201'（10秒） 分析： where子句中对列的任何操作结果都是在SQL运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被SQL优化器优化，使用索引，避免表搜索，因此将SQL重写成下面这样： select * from record where card_no like '5378%'（< 1秒） select * from record where amount < 1000*30（< 1秒） select * from record where date= '1999/12/01'（< 1秒） 你会发现SQL明显快起来！ 2.例：表stuff有200000行，id_no上有非群集索引，请看下面这