游标中用到order by 子句为什么会很慢

Question

DECLARE cursor_for CURSOR FOR
 select id,tuan_name from t where status=10 order by submit_time desc  
 OPEN cursor_for
 FETCH NEXT FROM cursor_for INTO @id ,@tuanname
  WHILE @@FETCH_STATUS = 0
    BEGIN
          --其它执行语句
          END
  CLOSE cursor_for
 DEALLOCATE cursor_for   为什么加上order by submit_time desc 运行起来就会很慢，去掉就会很快
t表有几十万条数据,但是满足条件的结果也就十几条。

Answer 1

select id,tuan_name 
into 临时表
from t 
where status=10 order by submit_time desc 
把满足条件的数据追加到临时表中，然后对临时表打开游标。

Answer 2

我想知道:为什么加上order by submit_time desc 运行起来就会很慢，去掉就会很快

Answer 3

转自老大的方法：
出问题的时候试试
DBCC   INDEXDEFRAG(数据库名,表名,索引名)  DBCC   INDEXDEFRAG   
  整理指定的表或视图的聚集索引和辅助索引碎片。   
    
  语法   
  DBCC   INDEXDEFRAG   
          (   {   database_name   |   database_id   |   0   }   
                  ,   {   table_name   |   table_id   |   'view_name'   |   view_id   }   
                  ,   {   index_name   |   index_id   }   
          )         [   WITH   NO_INFOMSGS   ]   
    
  参数   
  database_name   |   database_id   |   0   
    
  是对其索引进行碎片整理的数据库。数据库名称必须符合标识符的规则。有关更多信息，请参见使用标识符。如果指定   0，则使用当前数据库。   
    
  table_name   |   table_id   |   'view_name'   |   view_id   
    
  是对其索引进行碎片整理的表或视图。表名和视图名称必须符合标识符规则。   
    
  index_name   |   index_id   
    
  是要进行碎片整理的索引。索引名必须符合标识符的规则。   
    
  WITH   NO_INFOMSGS   
    
  禁止显示所有信息性消息（具有从   0   到   10   的严重级别）。   
    
  注释   
  DBCC   INDEXDEFRAG   可以对表或视图上的索引和非聚集索引进行碎片整理。DBCC   INDEXDEFRAG   对索引的叶级进行碎片整理，以便页的物理顺序与叶节点从左到右的逻辑顺序相匹配，从而提高索引扫描性能。   
    
  DBCC   INDEXDEFRAG   还压缩索引页，并在压缩时考虑创建索引时指定的   FILLFACTOR。此压缩所产生的任何空页都将删除。有关   FILLFACTOR   的更多信息，请参见   CREATE   INDEX。   
    
  如果索引跨越多个文件，则   DBCC   INDEXDEFRAG   一次对一个文件进行碎片整理。页不在文件之间迁移。     
    
  DBCC   INDEXDEFRAG   每隔   5   分钟向用户报告预计完成的百分比。可在进程中的任一点结束   DBCC   INDEXDEFRAG，任何已完成的工作都将保留。   
    
  与   DBCC   DBREINDEX（一般的索引生成操作）不同，DBCC   INDEXDEFRAG   是联机操作。它不长期控制锁，因此不会防碍运行查询或更新。若索引的碎片相对较少，则整理该索引的速度比生成一个新索引要快，这是因为碎片整理所需的时间与碎片的数量有关。对碎片太多的索引进行整理可能要比重建花更多的时间。另外，始终对碎片整理进行完整的日志记录，与数据库恢复模型设置无关（请参见   ALTER   DATABASE）。对碎片太多的索引进行整理所生成的日志记录可能比完全记录的索引创建还要多。然而，若需经常进行日志备份或如果恢复模型设置是   SIMPLE，碎片整理将作为一系列短事务执行，因此不需要大量的日志。     
    
  另外，如果两个索引在磁盘上交叉存取事务，DBCC   INDEXDEFRAG   将没有作用，原因是   INDEXDEFRAG   打乱了已有的页。若要改善页的聚集，请重建索引。   
    
  不支持在系统表上使用   DBCC   INDEXDEFRAG。   
    
  结果集   
  如果没有指定   WITH   NO_INFOMSGS，DBCC   INDEXDEFRAG   将返回以下结果集（值可能会有变化）：   
    
  Pages   Scanned   Pages   Moved   Pages   Removed   
  -------------   -----------   -------------   
  359                       346                   8   
  (1   row(s)   affected)   
    
  DBCC   execution   completed.   If   DBCC   printed   error   messages,   contact   your   system   administrator.   
    
  权限   
  DBCC   INDEXDEFRAG   权限默认授予   sysadmin   固定服务器角色或   db_owner   和   db_ddladmin   固定数据库角色的成员以及表的所有者且不可转让。   
    
  示例   
  DBCC   INDEXDEFRAG   (Northwind,   Orders,   CustomersOrders)   
  GO

Answer 4

语法格式如下：
DECLARE cursor_name [INSENSITIVE] [SCROLL] CURSOR
FOR select_statement
[FOR {READ ONLY | UPDATE [OF column_name [,...n]]}]
其中： 
cursor_name
指游标的名字。 
INSENSITIVE
表明MS SQL SERVER 会将游标定义所选取出来的数据记录存放在一临时表内（建立在tempdb 数据库下）。对该游标的读取操作皆由临时表来应答。因此，对基本表的修改并不影响游标提取的数据，即游标不会随着基本表内容的改变而改变，同时也无法通过
游标来更新基本表。如果不使用该保留字，那么对基本表的更新、删除都会反映到游标中。另外应该指出，当遇到以下情况发生时，游标将自动设定INSENSITIVE 选项。
在SELECT 语句中使用DISTINCT、 GROUP BY、 HAVING UNION 语句；