4、下面截图是步骤3中的执行计划，关注一下SalesOrdDemo表上有聚集索引扫描，这是合理的，因为没有WHERE子句在使用SalesOrderID列。而SalesOrderDetails表有非聚集索引扫描。还可以看到实际行数和估计行数有很大差异。
5、现在是时候在新表的DueDate上创建统计信息，因为在查询中这个列并不包含在索引里面。
| CREATE STATISTICS st_SaledOrdDemo_DueDate ON SalesOrdDemo(DueDate) GO |
6、再次执行步骤3的脚本，不需要任何改动：
| SELECT s.salesorderid , so.SalesOrderDetailID FROM salesordDemo AS s INNER JOIN Sales.SalesOrderDetail AS so ON s.salesorderid = so.SalesOrderID WHERE s.duedate = '2005-09-19 00:00:00.000' |
7、对比上面的执行计划，此时在SalesOrderDetails表上已经从非聚集索引扫描变成了聚集索引查找，且开销只有2%，更总要的是实际行数和预估行数相差无几：
分析：
如果优化器可以获得谓词上列的统计信息，那么相会知道将要返回的行数，并且帮助优化器选择最佳的执行方式。
相关链接：
