首先感谢一下“DBA_Huangzj”昨天不厌其烦的回答了我好多问题。
不过优化路漫漫，所以还是有一些疑问，所以再发一贴，请教各位数据库方面的大佬，不甚感激！
经过昨天的纠结得出两个结论：
1、用“SET STATISTICS IO ON”开启IO信息，如果 logical reads 数值越小，表示效率越高。
2、看执行计划，如果“预估IO开销”和“预估CPU开销”越小越好。
不知道这两点结论是否站得住脚？
现在问题来了，同一条sql语句，在有索引和无索引的情况下，执行计划显示的步骤有多有少的，如下图：
未建额外索引：
建立索引：create index test_index on dbo.Building_Queue(TileID)
从两张图中可以看出：将各不走开销百分比加起来都是 100%，
但是当将鼠标移到有开销的步骤上去，将各种情况下有开销的“IO开销”和“cpu开销”分别加起来这个是有差别的，那是不是说：将有开销的步骤的“io开销”和“cpu开销”分别累加起来，数值越小效率越高呢？
当然，还得看看 logical reads 的数值。
------解决方案--------------------
最好这样，你把两个语句，放到一起执行，会显示 这2个查询，分别占用了 多少开销，比如这样：
------解决方案--------------------
1、SET STATISTICS IO ON
2、看执行计划，如果“预估IO开销”和“预估CPU开销”越小越好。
为什么要开启SET STATISTICS IO ON？因为通过开启它我们可以看看执行某条语句时是否做了过多的I/O读取。
如果一条居于需要访问的数据页没有事先缓存在内存里，那么在执行过程中就必须从磁盘读到内存里。这个也就是说的physical reads和read-ahead reads.
一个查询语句从磁盘读取页数就是physical reads+read-ahead reads的结果。这个结果越小越好，毕竟每次查询都从磁盘读数据是很昂贵的。
logical reads也就是所谓的逻辑读取。他是从数据缓存读取的数据的页数。如果一个查询logical reads的结果越大，说明内存消耗量也就越大，查询也就越昂贵。这个时候可以考虑调整索引，较小扫描次数，缩小扫描范围