-下午问有关问题的人少，小弟我来问问：今天帖子说道【游标】慢！有多慢？可否代替？

2013-12-11

-----------下午问问题的人少，我来问问：今天帖子说道【游标】慢！有多慢？可否代替？------------之前做过平台

-----------下午问问题的人少，我来问问：今天帖子说道【游标】慢！有多慢？可否代替？------------
之前做过平台的二次开发，主要就是写写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_end_offset 
          WHEN -1 THEN DATALENGTH(st.text)
          ELSE qs.statement_end_offset END 
            - qs.statement_start_offset)/2) + 1) not like '%fetch%'
ORDER BY  total_elapsed_time / execution_count DESC

看什么东西？

1、执行计划。2、等待信息。3、扎实的理论。4、丰富的经验。慢慢学慢慢练吧，这东西几本书都说不完
[解决办法]
还有一个例子，别人都说sqlserver垃圾，看看他们的代码，我会回复：我能说脏话吗？
如果你不懂优化，oracle一样是垃圾
[解决办法]

引用:

Quote: 引用:

还有一个例子，别人都说sqlserver垃圾，看看他们的代码，我会回复：我能说脏话吗？
如果你不懂优化，oracle一样是垃圾

1、执行计划。2、等待信息。
在哪看？

执行计划：ctrl+m/l，然后执行查询。
等待信息：
sys.dm_os_waiting_tasks/sys.dm_os_wait_stats
这些部分扩展出来非常巨大，一下子说不清楚，你到网上搜搜吧
[解决办法]

引用:

1、执行计划。2、等待信息。
在哪看？

建议LZ系统的学习一下SQL Server性能优化方面的书,这些问题就迎刃而解了.
[解决办法]
游标慢的原因我觉得最主要是它背离了数据库操作的本质，数据库操作的强势就在于它对于集合的操作，而游标却要剑走偏锋，将集合操作变为了一项项操作，至于循环，只是大家觉得游标可以用在循环上，但游标却不是为循环而生的，就如1楼说的，能够循环的方式有很多，为什么非要选择游标呢。
所以我们应该将优化放在存储过程的执行效率上，无论数据存储、中间数据、数据预处理，还是在逻辑层面，存储过程的每一块的SQL语句的优化，总之从数据存储、逻辑处理、表结构设计等等多方面去考虑。
[解决办法]
一般的逻辑，不需要用到游标，普通的sql代码，或者t-sql就能完成。

但如果是复杂到一定程度，那么可以考虑游标，就是一次处理1行数据，然后循环到下一行，再处理一行数据，这样的处理方式，不像sql的集合处理方式那么有效，这个是慢的原因。

但如果你的逻辑真是复杂到sql都用不了了，那么就考虑用游标吧，不是游标不好，而是你的知道在什么情况下用游标。

不到万不得已，最好不要用游标。
[解决办法]
分情况，有些数据计算（极偏少）的处理前端更快
如果你仔细去搞懂数据库是如何处理数据的，和前端是如何处理数据的，那么答案就清晰了
如果只是哦哦然，那即使一次“猜”对了，也是不知其所以然

热点排行