52480.htm

一本很基础的SQL讲解

<TR>
<TD class=it align=middle bgColor=#dddddd>图3</TD></TR></TBODY></TABLE>
<P>因而逻辑读增加了2——(由于发生Clustered Index Scan，除了根级别的聚集索引页占用1次外，从根级别聚集索引定位到叶级别的聚集索引也将额外占用1次逻辑读)。</P>
<P>另外一个变化是只发生了一次物理读，即读取根级别的聚集索引页，另外4个数据页则通过预读方式而不是物理读从磁盘装入内存Buffer。这使得有聚集索引的情况下，执行SQL所直接花费的代价实际上更小。</P>
<P><STRONG>2.2、执行高选择性选取</STRONG></P>
<P>在建立聚集索引情况下，对性能有益的变化是：</P>
<P>对于Select Top 1 * From P_Order 或者Select * From P_Order Where MobileNo=28702这样的语句，在有聚集索引情况下，只会将最终记录所在的页读入内存。</P>
<P><STRONG>测试3：建立非聚集索引情况下，执行SQL语句</STRONG></P>
<P><STRONG>3.1、执行全表选取或者低选择性选取</STRONG></P>
<P>如果将表中同一字段的聚集索引换成非聚集索引，则可以看到如下特点：</P>
<P>执行全表扫描将和没有任何索引的情况相似，将读取所有的数据页到内存。此时,SQL Server的查询引擎实际上无法使用非聚集索引。</P>
<P><STRONG>3.2、执行高选择性选取</STRONG></P>
<P>将只读取最终数据所在的页到内存。通过查询计划可以看到，SQL Server在非聚集索引上使用INDEX SEEK，然后通过lookup 得到数据实际所在行(索引覆盖情况下例外，因为不需要定位到实际数据行)。</P>
<P><STRONG>测试4：执行Nested Loop Join</STRONG></P>
<P>在进行测试前，我们先准备另外一张表和数据。</P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE>Create Table P_Order <BR>( UserStatus int NOT NULL, <BR>MobileNo int NOT NULL, <BR>Sid int Not NULL, <BR>LastSubTime DateTime <BR>)</PRE></TD></TR></TBODY></TABLE></P>
<P>插入数据：</P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE>Declare @i int <BR>Set @i=20000 <BR>WHILE @i&lt;30000 <BR>BEGIN <BR>Insert Into P_Order <BR>Select @i % 2,@i,@i-19999,GetUTCDate() <BR>set @i=@i+1 <BR>END</PRE></TD></TR></TBODY></TABLE></P>
<P>可以看到，在执行全表扫描情况下，该表10000条数据总共占用38个内存数据页。</P>
<P>#p#</P>
<P><STRONG>4.1、执行全表选取或者低选择性选取</STRONG></P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE>Select * From P_Order A <BR>Inner Loop JOIN P_User B ON A.MobileNo=B.MobileNo</PRE></TD></TR></TBODY></TABLE></P>
<P>对于此种高选择性选择，默认情况下SQL Server不会执行Loop Join。因此，使用了强制性的联接提示。</P>
<P>在两个表都没有任何索引的情况下，可以看到：</P>
<P>两个表所有的数据页都将被加载到内存。逻辑读取代价高达6万多次——对于P_Order表中的每一条记录，都将在P_User表中进行遍历。</P>
<P>在其中一个表有聚集索引情况下，尽管逻辑读取相比刚才的6万多次已经大大下降，但仍然达到2万次。而且联接的次序对查询性能影响很大。因为其实际执行的是将SQL语句中前面的表作为联接的外部输入，而后面的表作为联接的内部输入。</P>
<P>在两个表都有聚集索引情况下，相比较而言，逻辑读仍然达到数千次(取决于最终输出的数据大小)，但相比较已经大大改善。而且表中的数据只有最终需要输出的部分才会被读入内存Buffer中。</P>
<P><STRONG>4.2、执行高选择性选取</STRONG></P>
<P>执行如下的SQL语句：</P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE>Select * From P_Order A <BR>Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo <BR>Where A.MobileNo=28913</PRE></TD></TR></TBODY></TABLE></P>
<P>在两个表都没有任何索引情况下，两张表都将执行全表扫描。要读入所有的数据页到内存。总体逻辑读取决于两表的数据页数。</P>
<P>在一个表有聚集索引或者非聚集索引情况下，该表将执行Index Seek，另一个表将出现全表扫描。内存数据缓冲区中，将有一张表只读入最终数据所在的数据页、一张表读入全部数据页。逻辑读数取决于表在联接中的秩序、以及无索引表的数据页数。</P>
<P>在两个表都有聚集索引情况下，逻辑读最小，每个表只有2到3次。而且只有实际需要输出的数据才会被读入内存页。两个表都有非聚集索引情况下，消耗的逻辑读和内存资源近似。</P>
<P><STRONG>测试5：执行Merge Join</STRONG></P>
<P><STRONG>5.1、执行全表选取或者低选择性选取</STRONG></P>
<P>执行SQL：</P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE>Select * From P_Order A <BR>Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo</PRE></TD></TR></TBODY></TABLE></P>
<P>如果两张表都没有任何索引，则两张表都要进行全表扫描。所有的数据都要读入内存页。</P>
<P>逻辑读数近似等于两张表的数据页总和。SQL Server处理过程中将使用到临时表。</P>
<P>只有一张表有聚集索引的情形类似，SQL Server处理过程中将使用到临时表。并且读入所有的数据页到内存。</P>
<P>如果两张表都有聚集索引，尽管两表的数据都会被读入内存页，但逻辑读数已经大大减少，等于其中一张表总数据内存页数加上最终输出的数据页数。而且SQL Server处理过程中将不需要再使用临时表。</P>
<P><STRONG>5.2、执行高选择性选取</STRONG></P>
<P>对于这样的高选择性SQL语句，SQL Server 将提示无法生成执行计划。</P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE>Select * From P_Order A <BR>Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo <BR>Where A.MobileNo=28913</PRE></TD></TR></TBODY></TABLE></P>
<P>但可以执行：</P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE>Select * From P_Order A <BR>Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo <BR>Where A.MobileNo&lt;=28001 (注：最终结果只有2条)</PRE></TD></TR></TBODY></TABLE></P>
<P>这样的属于低选择性语句，但最终结果也很少的语句。如前面所述，这种情况下，采用netsted loop联接效率可能更高。</P>
<P>#p#</P>
<P><STRONG>测试6：执行Hash Join</STRONG></P>
<P><STRONG>6.1、执行全表选取或者低选择性选取</STRONG></P>
<P>对于两表联接，如果两张表都没有索引，不写明联接提示的情况下，SQL Server默认使用hash join。而对于两表联接，如果两张表都有聚集索引，则SQL Server默认使用Merge Join。</P>
<P>执行SQL：</P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE>Select * From P_Order A <BR>Inner hash JOIN P_User B ON A.MobileNo=B.MobileNo</PRE></TD></TR></TBODY></TABLE></P>
<P>在使用hash join情况下，无论两张表有无索引，都将读取所有的数据页到内存，SQL Server将使用临时表进行处理。逻辑读数近似等于两张表的数据页总和。</P>
<P><STRONG>6.2、执行高选择性选取</STRONG></P>
<P>和merge join执行高选择性选取情况类似，也无法直接执行：</P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE>Select * From P_Order A <BR>Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo <BR>Where A.MobileNo=28913</PRE></TD></TR></TBODY></TABLE></P>
<P>但可以执行这样的结果很少的低选择性脚本：</P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE>Select * From P_Order A <BR>Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo <BR>Where A.MobileNo&lt;=28001 (注：最终结果只有2条)</PRE></TD></TR></TBODY></TABLE></P>
<P>但此情况下，采用netsted loop联接效率更高。</P>
<P><STRONG>测试总结</STRONG></P>
<P>本次测试的主要意义在于，通过分析具体的内存变化结合执行计划、IO读取等信息，可以更清楚地了解SQL Server执行SQL 语句过程。</P>
<P>另外，也验证了一些通过分析SQL 语句的IO读取、执行计划曾经得到的经验：</P>
<P>(1) 在执行单表查询时，如果是高选择查询，要建立非聚集索引或者聚集索引(推荐非聚集索引，是独立于数据存放的)。如果是低选择性查询，则需要建立聚集索引。</P>
<P>(2) 在执行联接查询时，如果最终输出结果很少，则适宜使用nested loop join;如果输出结果较多，则通过建立聚集索引，而以merge join方式查询能得到好的性能。对于性能较低的hash join，最好通过转换成merge join或者nested loop join方式提高查询性能。</P>
<P><FONT size=4>【相关文章】</FONT></P>
<UL type=disc>
<LI><A href="http://database.51cto.com/art/200707/52060.htm" target=_blank><U><FONT color=blue>如何解决SQL Server占用内存的问题</FONT></U></A></LI></UL>
<UL type=disc>
<LI><A href="http://database.51cto.com/art/200707/51688.htm" target=_blank><U><FONT color=blue>SQL Server数据库同步问题</FONT></U></A></LI></UL>
<UL type=disc>
<LI><A href="http://database.51cto.com/art/200707/50713.htm" target=_blank><U><FONT color=blue>精讲SQL Server数据库备份多种方法</FONT></U></A></LI></UL>
<P align=right>【责任编辑：<A class=ln href="mailto:[e-mail]">火凤凰</A> TEL：[phone]】 </P></td>
      </tr>
      <tr>
        <td class="d_font4">&nbsp;</td>
      </tr>
    </table>