SQL Server执行部分语句的内存代价

核心提示： 在两个表都有聚集索引情况下，逻辑读最小，SQL Server执行部分语句的内存代价(6)，每个表只有2到3次，而且只有实际需要输出的数据才会被读入内存页，而以merge join方式查询能得到好的性能，对于性能较低的hash join，两个表都有非聚集索引情况下，消耗的逻辑读和内存资源近似

在两个表都有聚集索引情况下，逻辑读最小，每个表只有2到3次。而且只有实际需要输出的数据才会被读入内存页。两个表都有非聚集索引情况下，消耗的逻辑读和内存资源近似。

测试5：执行Merge Join5.1　　执行全表选取或者低选择性选取

执行SQL:

Select * From P_Order A
Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo

如果两张表都没有任何索引，则两张表都要进行全表扫描。所有的数据都要读入内存页。

逻辑读数近似等于两张表的数据页总和。SQL Server处理过程中将使用到临时表。

只有一张表有聚集索引的情形类似，SQL Server处理过程中将使用到临时表。并且读入所有的数据页到内存。

如果两张表都有聚集索引，尽管两表的数据都会被读入内存页，但逻辑读数已经大大减少，等于其中一张表总数据内存页数加上最终输出的数据页数。而且SQL Server处理过程中将不需要再使用临时表。

5.2　　执行高选择性选取

对于这样的高选择性SQL语句，SQL Server 将提示无法生成执行计划。

Select * From P_Order A
Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo
Where A.MobileNo=28913

但可以执行：

Select * From P_Order A
Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo
Where A.MobileNo<=28001 （注：最终结果只有2条）

这样的属于低选择性语句，但最终结果也很少的语句。如前面所述，这种情况下，采用netsted loop联接效率可能更高。

测试6：执行Hash Join6.1　　执行全表选取或者低选择性选取

对于两表联接，如果两张表都没有索引，不写明联接提示的情况下，SQL Server默认使用hash join。而对于两表联接，如果两张表都有聚集索引，则SQL Server默认使用Merge Join。

执行SQL:

Select * From P_Order A
Inner hash JOIN P_User B ON A.MobileNo=B.MobileNo

在使用hash join情况下，无论两张表有无索引，都将读取所有的数据页到内存，SQL Server将使用临时表进行处理。逻辑读数近似等于两张表的数据页总和。

6.2　　执行高选择性选取

和merge join执行高选择性选取情况类似，也无法直接执行：

Select * From P_Order A
Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo
Where A.MobileNo=28913

但可以执行这样的结果很少的低选择性脚本：

Select * From P_Order A
Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo
Where A.MobileNo<=28001 （注：最终结果只有2条）

但此情况下，采用netsted loop联接效率更高。

测试总结

本次测试的主要意义在于，通过分析具体的内存变化结合执行计划、IO读取等信息，可以更清楚地了解SQL Server执行SQL 语句过程。

另外，也验证了一些通过分析SQL 语句的IO读取、执行计划曾经得到的经验：

（1）　　　 在执行单表查询时，如果是高选择查询，要建立非聚集索引或者聚集索引（推荐非聚集索引，是独立于数据存放的）。如果是低选择性查询，则需要建立聚集索引。

（2）　　　 在执行联接查询时，如果最终输出结果很少，则适宜使用nested loop join；如果输出结果较多，则通过建立聚集索引，而以merge join方式查询能得到好的性能。对于性能较低的hash join，最好通过转换成merge join或者nested loop join方式提高查询性能。