【ROW_NUMBER()】管于ROW_NUMBER()性能有关问题

【ROW_NUMBER()】管于ROW_NUMBER()性能问题
用SQL Profile观察下下面两条SQL语句执行情况，这两条SQL语句几乎一样，前者仅加了个ROW_NUMBER()而已

SQL-A:

 SELECT TOP(6) ID, CompanyName ,HtmlUrl,ROW_NUMBER() OVER (order by NEWID())as RowNumber
 FROM  Company
 WHERE Status>=3 AND CompanyType=1

SQL Profile里面的Reads值：29144
----------------------------
SQL-B:

 SELECT TOP(6) ID, CompanyName ,HtmlUrl
 FROM  Company
 WHERE Status>=3 AND CompanyType=1

SQL Profile里面的Reads值：16
----------------------------
这是不是ROW_NUMBER()引起的性能问题呢？
------最佳解决方案--------------------
你这个语句太多top和order by 了，如果你用到top，那加上order by是有必要的，为了保证顺序，所以不要去掉。我觉得要从业务上重新分析是否有更好的写法
------其他解决方案--------------------

引用:

引用:引用:引用:
你这个语句太多top和order by 了，如果你用到top，那加上order by是有必要的，为了保证顺序，所以不要去掉。我觉得要从业务上重新分析是否有更好的写法
好奇怪，我很多查询语句带了order by 之后，好像会全表扫……

有索引的话可以优化的
你删除了150W  这个表的空间不见得全部释放  建议你重建以下索引  这样可以使未释放的空间释放出来
------其他解决方案--------------------
A应该是引起了表扫描 请贴出执行计划

------其他解决方案--------------------

引用:

引用:两个的执行计划肯定不一样的，贴出来看看
引用:A应该是引起了表扫描 请贴出执行计划

聚集索引扫描，就是把表整个扫了一遍。
看楼下回复，应该是read降下来了，可喜可贺
------其他解决方案--------------------
两个的执行计划肯定不一样的，贴出来看看
------其他解决方案--------------------
小弟弱弱的问一句SQL Profile是啥玩意啊？
------其他解决方案--------------------

引用:

小弟弱弱的问一句SQL Profile是啥玩意啊？

------其他解决方案--------------------

引用:

两个的执行计划肯定不一样的，贴出来看看

引用:

A应该是引起了表扫描 请贴出执行计划

------其他解决方案--------------------
执行计划上方绿色那行字，右键→然后生成那个丢失索引的脚本。因为丢失索引，导致聚集索引扫描，而这个扫描无异于表扫描。所以I/O很大。
------其他解决方案--------------------

引用:

执行计划上方绿色那行字，右键→然后生成那个丢失索引的脚本。因为丢失索引，导致聚集索引扫描，而这个扫描无异于表扫描。所以I/O很大。

他生成这么一段语句，我执行了，如何Reads降下来了

USE [xxx]
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[Company] ([CompanyType],[Status])
INCLUDE ([ID],[CompanyName],[HtmlUrl])

---------------
什么情况下才会导致索引丢失？是不是我使用了ROW_NUMBER()导致索引丢失的呢
------其他解决方案--------------------
row_number的时候里面有order语句。这会导致数据重新排序。丢失索引一般是include索引，也就是你用到的列有很多没有索引在上面，这时要造成扫描表，因为没索引，所以不知道数据在哪，必须通过扫描来做。你执行了那个语句之后，再看看性能，如无意外reads会降恒多
------其他解决方案--------------------

引用:

引用:小弟弱弱的问一句SQL Profile是啥玩意啊？

------其他解决方案--------------------