两语句性能对比

skyzcl 2008-06-24 11:44:43
语句一

DECLARE @depot nvarchar(10)
SELECT @depot='00000'
WHILE 1=1
BEGIN
SELECT @depot =depot FROM s_depot WHERE depot > @depot ORDER BY depot desc
IF @@rowcount <1
BREAK
PRINT @depot
END


语句二
DECLARE @depot nvarchar(10)
DECLARE cur1 CURSOR FOR SELECT depot FROM s_depot ORDER BY depot
OPEN cur1
FETCH next FROM cur1 INTO @depot
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT @depot

FETCH next FROM cur1 INTO @depot
END
CLOSE cur1
DEALLOCATE cur1
...全文
303 16 打赏 收藏 举报
写回复
用AI写文章
16 条回复
切换为时间正序
请发表友善的回复…
发表回复
zhiguo2008 2008-07-04
  • 打赏
  • 举报
回复
[Quote=引用 15 楼 perfectaction 的回复:]
引用 13 楼 skyzcl 的回复:
引用 11 楼 perfectaction 的回复:
原则是能不使用游标就尽量别使用,看是否有变通的方式。

象此类查询,应如何变通呢?有没有更有效率的方法


大多是去变通业务了
[/Quote]
nzperfect 2008-06-24
  • 打赏
  • 举报
回复
[Quote=引用楼主 skyzcl 的帖子:]
语句一
SQL codeDECLARE@depotnvarchar(10)SELECT@depot='00000'WHILE1=1BEGINSELECT@depot=depotFROMs_depotWHEREdepot>@depotORDERBYdepotdescIF@@rowcount<1BREAKPRINT@depotEND

语句二
SQL codeDECLARE@depotnvarchar(10)DECLAREcur1CURSORFORSELECTdepotFROMs_depotORDERBYdepotOPENcur1FETCHnextFROMcur1INTO@depotWHILE@@FETCH_STATUS=0BEGINPRINT@depotFETCHnextFROMcur1INTO@depotENDCLOSEcur1DEALLOCATEcur1
[/Quote]

一般数据比较多情况下,仅这两个比较的话,第二个效率要高。
如果几行数据,就不明显了。
原因:
第一个是需要不停的到表里读取数据,不停的读io(或是内存缓存数据),造成大量的io读取,而io操作,是最慢最耗资源的。
第二个是一次性写入游标里,然后进行操作,读到的io相对的第一种是极小的,而游标效率也并非是极差,不然,ms也就不用它了。
yinqi025 2008-06-24
  • 打赏
  • 举报
回复
这个是没咋可比性...
yinqi025 2008-06-24
  • 打赏
  • 举报
回复
第一个应该快很多
Garnett_KG 2008-06-24
  • 打赏
  • 举报
回复
毫无可比性
两条语句的得出来的结果可能都不一样

datahandler2 2008-06-24
  • 打赏
  • 举报
回复
我感觉估计第一个会比较高点。第二个用到游标相当资源比较耗
nzperfect 2008-06-24
  • 打赏
  • 举报
回复
楼主测试的结果呢,说说吧
skyzcl 2008-06-24
  • 打赏
  • 举报
回复
哪个效率高呢?一直很困惑
nzperfect 2008-06-24
  • 打赏
  • 举报
回复
[Quote=引用 13 楼 skyzcl 的回复:]
引用 11 楼 perfectaction 的回复:
原则是能不使用游标就尽量别使用,看是否有变通的方式。

象此类查询,应如何变通呢?有没有更有效率的方法
[/Quote]

大多是去变通业务了
yinqi025 2008-06-24
  • 打赏
  • 举报
回复
[Quote=引用 8 楼 perfectaction 的回复:]
我上面在7楼说的不对,通过测试,发现游标也是需要一次一次的去查里查数据,更正并测试下:


SQL code--生成测试表,10000条数据
create table t_test(id int identity(1,1) primary key,class_a varchar(50),class_b varchar(50),add_dt datetime)
go
declare @i int
select @i = 1
while @i < = 10000
begin
insert into t_test(class_a,class_b,add_dt)
select case @i%2 when 0 then 'class_a' + …
[/Quote]

那我错了...我以为游标很影响速度,帮助很大对我...up
skyzcl 2008-06-24
  • 打赏
  • 举报
回复
[Quote=引用 11 楼 perfectaction 的回复:]
原则是能不使用游标就尽量别使用,看是否有变通的方式。
[/Quote]
象此类查询,应如何变通呢?有没有更有效率的方法
nzperfect 2008-06-24
  • 打赏
  • 举报
回复
可以把数据插入到一个@t table变理中,这个@t table设置一个自增长列
去循环这个内存表,在你服务器内存足够大时,或许性能好于游标。
nzperfect 2008-06-24
  • 打赏
  • 举报
回复
原则是能不使用游标就尽量别使用,看是否有变通的方式。
skyzcl 2008-06-24
  • 打赏
  • 举报
回复
象此类查询,有没有比游标更有效率的方法呢?请教
skyzcl 2008-06-24
  • 打赏
  • 举报
回复
原来原理是这样啊,一直以为游标慢,看来还是有适用的地方!谢谢LS的
nzperfect 2008-06-24
  • 打赏
  • 举报
回复
我上面在7楼说的不对,通过测试,发现游标也是需要一次一次的去查里查数据,更正并测试下:

--生成测试表,10000条数据
create table t_test(id int identity(1,1) primary key,class_a varchar(50),class_b varchar(50),add_dt datetime)
go
declare @i int
select @i = 1
while @i < = 10000
begin
insert into t_test(class_a,class_b,add_dt)
select case @i%2 when 0 then 'class_a' + cast(@i as varchar) else cast(@i as varchar) end,
case @i%5 when 0 then 'class_b' + cast(@i as varchar) else cast(@i as varchar) end, getdate()
select @i = @i + 1
end


--测试第一种所需时间
declare @t1 datetime,@t2 datetime
declare @a int,@b int
select @t1 = getdate()
declare @depot nvarchar(10)
select @depot='2'
while 1=1
begin
select @depot =id from t_test where id > @depot order by id desc
if @@rowcount <1
break
print @depot
end
select @t2 = getdate()
select cast(datediff(ms,@t1,@t2) as varchar)+'ms'
--结果:
30983ms


--测试第二种:
declare @t1 datetime,@t2 datetime
declare @a int,@b int
select @t1 = getdate()
declare @depot nvarchar(10)
declare cur1 cursor for select id from t_test where id between 3 and 10000 order by id
open cur1
fetch next from cur1 into @depot
while @@fetch_status = 0
begin
print @depot

fetch next from cur1 into @depot
end
close cur1
deallocate cur1
select @t2 = getdate()
select cast(datediff(ms,@t1,@t2) as varchar)+'ms'
--结果:
623ms


通过查看io读:
set statistics io on

发现这两个的区别在于:
第一个查询执行时是:select id from t_test where id > 30 order by id desc
而第二个查询是直接取某一行:select id from t_test where id = 30

也就是说楼主的:
SELECT @depot =depot FROM s_depot WHERE depot > @depot ORDER BY depot desc

在while时,每次要读取depot > @depot的所有数据页,而游标的则只读取一条记录的数据页。

源码链接: https://pan.quark.cn/s/a4b39357ea24 双系统引导修复机制是为那些在个人计算机上部署了两个操作系统(例如Windows与Linux、Windows的不同版本组合等)的用户群体量身定制的辅助程序。在常规操作过程中,由于某些因素的影响,比如系统更新、驱动程序安装或意外操作,可能会导致双系统的启动选择界面出现故障,无法正常选择需要启动的操作系统。在此情形下,需要一款操作极为简便的双系统启动菜单自动修正工具来处理这一挑战。 标题中所指的“双系统引导修复机制”指的是这一工具的核心作用,它专门致力于修复引导区域或MBR(主引导记录),而这两个部分是计算机在启动时用来加载操作系统的核心组件。引导修复过程通常包括对BIOS或UEFI设置进行校准,以及修复或重建BCD(启动配置数据)存储,这在Windows操作系统环境中显得尤为重要。 描述中提及的“操作简便修复”表明该工具在设计上非常注重易用性,无需用户拥有专业的计算机技术背景。用户只需遵循基础的步骤指引,即可自动完成启动菜单的修正任务,显著简化了故障诊断的流程。 标签“双系统启动菜单自动修复工具”进一步突出了该软件的主要职能,即解决因各种原因引发的双系统启动菜单失效状况。此类工具通常会对已安装的操作系统进行扫描,识别出所有可用的启动选项,并重新构建准确的引导菜单,使用户能够在启动阶段自由选择要执行的系统。 关于压缩文件内的“bootitng”文件,很可能是一个用于实施引导修复流程的程序组件。BootIt Next Generation(BING)是一个广为人知的引导管理解决方案,其部分模块可能以“bootitng”命名,负责处理启动项的管理与修复工作。该文件在执行修复过程中具有核...
内容概要:本文围绕2026年“华为杯”全国研究生数学建模竞赛B题——氢燃料电池低温冷启动建模与控制策略研究,提供系统性的解题思路、MATLAB与Python代码实现及论文撰写支持。内容涵盖一维单电池瞬态自冷启动模型构建、电堆自冷启动策略优化、辅助冷启动建模以及动态加热控制策略的设计与求解,深入分析多物理场耦合关系与模型基础,针对关键难点提出有效的求解路径。资源持续更新,包含详细的运行结果展示与参考文献,旨在为参赛者提供全面的技术指导与实战支持。; 适合人群:参加“华为杯”全国研究生数学建模竞赛,具备一定数学建模能力、编程基础(MATLAB/Python)和控制理论知识的高校学生或科研人员;特别适合对新能源系统建模、低温环境下能量管理与优化控制策略感兴趣的研究者。; 使用场景及目标:①用于高效备战2026年“华为杯”数学建模竞赛B题,快速掌握氢燃料电池在低温条件下的启动过程建模方法与求解技巧;②深入理解燃料电池系统在极端环境中的动态行为特性,开展冷启动过程中的热管理、能量分配与控制策略优化研究;③借助提供的完整代码框架与论文写作模板,完成高质量的仿真验证、结果分析与学术成果输出。; 阅读建议:建议结合文中提供的目录结构,按照问题分解的逻辑顺序逐步学习,重点关注模型构建的理论依据与代码实现的细节逻辑,动手运行并调试程序以加深对算法和控制策略的理解;同时参照配套的论文写作要点,将技术实现过程与学术规范表达有机结合,全面提升竞赛作品的技术深度与呈现质量。
内容概要:本文针对2026年华为杯数学建模竞赛D题“山区洪涝灾害下无人机运输与通信协同优化”,提出了一套完整的解决方案。该方案聚焦于灾后应急救援场景,综合运用多目标优化建模、智能优化算法与仿真技术,系统解决了多无人机在复杂地形下的物资运输路径规划、任务分配与通信中继部署等关键问题。通过构建融合地形障碍、无人机续航、载荷能力、通信覆盖范围及任务优先级的多目标优化模型,并采用改进灰狼优化算法(GWO)、多种群协同进化算法等先进智能算法进行高效求解,实现了对多个受灾点的快速响应、精准投送与持续通信保障。文中配套提供了详尽的Matlab代码实现、仿真结果分析与论文撰写框架,验证了所提方法在时效性、鲁棒性与实用性方面的显著优势。; 适合人群:具备一定数学建模、运筹学基础及Matlab编程能力的研究生、科研人员,以及准备参加全国研究生数学建模竞赛、华为杯、高教社杯等赛事的高年级本科生和硕士生。; 使用场景及目标:①应用于自然灾害应急救援中无人机集群的任务规划与协同控制;②解决多无人机系统在运输与通信双重任务下的联合优化难题;③为相关领域的科研人员提供算法复现、性能对比与模型改进的完整实例参考; 阅读建议:此资源不仅提供了从问题分析、模型构建到算法求解的全流程指导,还包含了可运行的代码与论文写作模板,建议读者在学习过程中结合代码进行调试与结果可视化,深入理解算法核心逻辑,并尝试在不同参数设置和场景假设下进行对比实验,以全面提升解决复杂工程优化问题的能力。
内容概要:本文围绕同步电机与构网型变流器的频率稳定特性及其在多时间尺度下的交互机理展开深入研究,基于Simulink平台构建电力系统仿真模型,系统分析两者在动态响应过程中的耦合行为与稳定性表现。研究重点揭示了构网型变流器在模拟同步电机惯量响应和一次调频特性方面的控制机理,探讨其在高比例电力电子设备接入背景下对系统频率稳定的影响。通过设置不同扰动场景进行仿真对比,评估传统同步电机与新型变流器的频率响应差异,进一步剖析多时间尺度下动态过程的交互机制,并提出提升新型电力系统稳定性的优化控制策略。; 适合人群:具备电力系统、自动控制或电气工程等相关专业背景,熟悉Simulink仿真工具,从事新能源并网、微电网控制、电力系统稳定性分析等方向研究的研发人员及研究生。; 使用场景及目标:①深入理解构网型变流器如何模拟同步电机的惯量与一次调频特性;②分析高渗透率电力电子设备接入带来的频率稳定挑战,掌握多时间尺度动态交互的建模与分析方法;③为新型电力系统中变流器控制策略的设计、优化与仿真验证提供理论依据和技术支持。; 阅读建议:建议读者结合提供的Simulink模型文件同步操作,重点观察不同控制参数和扰动条件下系统的频率响应曲线变化,深入理解多时间尺度动态过程的仿真设置、关键模块建模方法及结果分析技巧,以提升对系统稳定机理的认知与仿真能力。

22,298

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧