日期:2014-05-17  浏览次数:20646 次

-----------下午问问题的人少,我来问问:今天帖子说道【游标】慢!有多慢?可否代替?------------
之前做过平台的二次开发,主要就是写写SQL,也曾用到过游标,确实是慢些。
有什么好的方法替代游标么?
前端程序可以用代码替代,这样会比SQL处理的快么?
没试验过!
求真相~~

为啥我就能给100分!?
大神们都秒答,我这测试数据还没敲完......

------解决方案--------------------
具体问题具体分析,CTE、临时表、函数、CLR都能实现大部分游标功能,我个人常用的是在数据库管理方面,比如遍历实例上的所有库、所有表,这种情况下,游标不错,我以前公司,有个开发写的报表,看了一下代码,直接between and 就可以查到数据,但是她尽然使用游标遍历全表,一上线,只运行了3次,产生6600万次逻辑读,服务器卡得要命,后来我改了一下between and,从2个多小时降到1秒钟。很多时候不是游标有问题,而是他们用错了,根深蒂固的面线过程或者面向对象写法,伤害了SQL Server的性能,最终你得到的答复是:没办法啊,我只会这样写
------解决方案--------------------
那个贴的重点是:因为存储过程使用游标,性能低,所以用T-SQL,这种悖论,不是某个技术。这个悖论让我一下子想到了组织的日常行为,罪过罪过
------解决方案--------------------
具体需看代码才知道喔.
存在即合理,游标还是有其不可替代的地方的.
执行慢也不一定就是游标的问题.
------解决方案--------------------
就好像while循环,很多人认为一定存在性能问题,我一开始也是,后来有个报表不得不改,我才认真研究执行计划,发现它慢不是在while循环,而是每次循环都很慢,后来我把循环中的处理改了一下,但是保留循环,速度也从超时级别降到9秒。
------解决方案--------------------
引用:
SQL优化需要什么工具么?
我之前找了个语句,如下:

SELECT creation_time  N'语句编译时间'
        ,last_execution_time  N'上次执行时间'
        ,total_physical_reads N'物理读取总次数'
        ,total_logical_reads/execution_count N'每次逻辑读次数'
        ,total_logical_reads  N'逻辑读取总次数'
        ,total_logical_writes N'逻辑写入总次数'
        ,execution_count  N'执行次数'
        ,total_worker_time/1000 N'所用的CPU总时间ms'
        ,total_elapsed_time/1000  N'总花费时间ms'
        ,(total_elapsed_time / execution_count)/1000  N'平均时间ms'
        ,SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
         ((CASE statement_end_offset 
          WHEN -1 THEN DATALENGTH(st.text)
          ELSE qs.statement_end_offset END 
            - qs.statement_start_offset)/2) + 1) N'执行语句'
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
where SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
         ((CASE statement_