@@--我真的不明白：为什么大部分人认为使用游标速度会很慢！--@@-MS-SQLServer/疑难问题-mssql-电脑编程网@@--我真的不明白：为什么大部分人认为使用游标速度会很慢！--@@-MS-SQLServer/疑难问题作者：luoyoumou　和相关&&@@--我真的不明白：为什么大部分人认为使用游标速度会很慢！--@@----真的如大家所说的吗？举例来看........------回答---------------其他回答（5分）---------SF------其他回答（5分）---------哦 学习------其他回答（5分）---------确实比较慢，尽量少用或不用。例如更新表中所有记录某一字段，用一条Update非常快，而如果用游标一条一条操作则慢很多。------其他回答（5分）---------会慢很多吧，因为每次都得应用程序和进行交互， 开销很大的。如果只写一条语句更新所有，所有的操作都交给去处理，会快很多。------其他回答（5分）---------------其他回答（5分）---------慢不慢 自己试试不就知道了..------其他回答（5分）---------引用 7 楼 luoyoumou 的回复:引用 6 楼 dap570 的回复:慢不慢 自己试试不就知道了..---http://topic.csdn.net/u//dbe5ac2a-a006-46a3-811e-1b4f.html?9074---说“慢”的同志，我还是想求大家去测试一下！---如果游标真的很慢：为什么还要用呢？方便程序的编写，如果速度在可接受的范围内，又有什么不可以呢。如果要构建一个多记录更新的SQL语句，有时候是很困难的。另外如果有些程序的外部依赖的话，可能只能用游标实现了。------其他回答（5分）---------楼主是个很认真的人，喜欢用结果说话，所以理论的东西不用说了光是为了比较而比较其实没什么意义，要看具体的应用，有些功能，是必须使用游标来做的（具体是什么样的功能就不举例了）我个人对游标也没什么好感，不是因为它的效率，是因为在并发数量很大时，容易产生了大量的死锁，也许是我们没用好，也许是我们不会用，总之，结果就是导致死锁越来越多，程序出现假死，后来不得不SET了一个LOCK_TIMEOUT来缓解，但是，大家都知道，这是治标不治本的东西。------其他回答（5分）---------静态(STATIC)游标创建将由该游标使用的数据的临时复本。对游标的所有请求都从tempdb 中的这一临时表中得到应答；因此，在对该游标进行提取操作时返回的数据中不反映对基表所做的修改，并且该游标不允许修改动态(DYNAMIC) 游标会反映在滚动游标时对结果集内的各行所做的所有数据更改。行的数据值、顺序和成员身份在每次提取时都会更改。动态游标不支持ABSOLUTE 提取选项。不指定STATIC 关键字的时候, 默认定义的游标是动态(DYNAMIC) 的如果很在意游标的类型, 应该在定义游标的时候, 加上游标类型定义的关键字, 并加上TYPE_WARNING 关键字, 以便在游标类型不是预期的情况下, 收到警告信息------其他回答（5分）---------定义静态游标，速度是很快的DECLARE CUR_tb CURSOR LOCAL FORWARD_ONLY READ_ONLY TYPE_WARNING STATIC& 有兴趣的朋友可参考：SQL游标的执行效率,静态游标的高效率执行http://blog.csdn.net/XGJ889/archive//4511104.x------其他回答（4分）---------存在即合理------其他回答（4分）---------SQL code
说几点：
1.游标和关系模型是有冲突的 一个是基于集合的 游标是更偏向于逻辑。
2.游标的解决方案基本上都是强制优化器去执行固定的执行计划的,没有基于集合那样 优化器会出来很多解决方法 然后挑选比较合适的。
3. 游标涉及大量行操作的开销。 这个你可以用一个简单的查询扫描表来比较。
4. 它还需要开发和维护代码的成本。一般的游标代码比较长 。
适合游标使用的地方：
严格按照顺序访问数据的一些地方比较适合游标
a.连续的聚合.
b.排名计算(2005有了OVER之后 这个优势就没了)
C.时间性问题.
------其他回答（4分）---------假设影响1000条记录用游标来做，相当于独立地做1000遍用sql直接做，相当于遍历这1000条时一起做掉――这是关系数据库系统所最擅长的除非是任务无法“遍历这1000条时一起做掉”的，才不得不用游标游标的做法像过程语言，有些sql语言不好实现的，它倒可以------其他回答（4分）---------学习------其他回答（4分）---------游标真的是不可或缺，用处非常大。游标无非就是一条条的取数据，而且是在端的，如果说这个就是慢，我觉得也慢不了多少，关键看你怎么写。14楼的朋友就说的很好，恰当的定义游标类型，会让速度加快不少。当然大数据量的并发操作，容易造成死锁，这也是不争的事实，即使不使用游标也会造成死锁的，这个和游标关系不大。另外，尽量不适用游标不=不要使用游标，游标的作用还是无人能替代的，我们的系统里就用了很多游标，而且一些ERP厂商在触发器里都用到游标，这也从一个角度说明游标的重要性！------其他回答（4分）---------游标的功能是强大，无法代替，但能不行的时候尽量避免------其他回答（4分）---------这也是我想说的引用 15 楼 navy887 的回复:存在即合理------其他回答（3分）---------同样更新1000W条数据，游标占的IO是查询的N倍。。。。我觉得有点像游标就像步行，查询就像开车，平常生活中走路和开车都是必要的，如果路不是很远，而且确实很绕的时候可以走，但走花费的成本是开车的N倍，所以我们出行都会尽量选择开车（这里不讨论环境和健康问题- -），如果有个地方只能通过走来到达，那只能说明城市规划有问题，该修路了。。。。。------其他回答（3分）---------工作中用的少之有少------其他回答（3分）---------数据量较小，处理简单速度较快的循环，考虑用游标，其他时候不建议。游标造成数据库进程思索的现象非常普遍，所以大部分人用的时候都有点怕。该用的时候用，效果就会很理想。------其他回答（3分）---------因为它占用内存大，你自已测测上千条的游标，就知人家为什么会认为它慢了------其他回答（5分）---------尽可能的使用游标类型为: LOCAL + FORWARD_ONLY + READ_ONLY , 这样的只能向前滚动类型的游标检索数据的效率是很高.不推荐使用游标来写数据, 比如update和delete, 效率低下的原因是dbms不知道怎么给优化成批处理, 通过SQL来实现, dbms会给优化批处理.至于游标对内存和死锁的影响, 没研究过, 因此不是很清楚.& 不过我下面的2个小例子相当的有意思, 闲着无聊的人可以试运行下, 主要对比每次select出来的结果.一SQL code
declare @
declare @tb table(
ID int not null,
VARCHAR(20) not null,
STATUS int not null
insert into @tb(ID ,NAME ,STATUS)
select 1
union all
select 3
union all
select 4
union all
select 5
union all
select 6
union all
select 7
print N'初始数据'
SELECT * FROM @
declare c1 CURSOR
LOCAL FAST_FORWARD
FOR(SELECT ID FROM @tb WHERE STATUS=1);
OPEN c1;
FETCH NEXT FROM c1 INTO @
WHILE @@FETCH_STATUS = 0
BEGIN
if exists(select * from @tb where ID=(@id+1))
update @tb set STATUS=1 where ID=(@id+1);
SELECT * FROM @
FETCH NEXT FROM c1 INTO @
end
CLOSE c1;
DEALLOCATE c1;
二SQL code
declare @
declare @tb table(
ID int not null,
VARCHAR(20) not null,
STATUS int not null
insert into @tb(ID ,NAME ,STATUS)
select 1
union all
select 3
union all
select 4
union all
select 5
union all
select 6
union all
select 7
print N'初始数据'
SELECT * FROM @
declare c1 CURSOR
LOCAL FAST_FORWARD
FOR(SELECT ID FROM @tb WHERE STATUS=1);
OPEN c1;
FETCH NEXT FROM c1 INTO @
WHILE @@FETCH_STATUS = 0
BEGIN
if exists(select * from @tb where ID=(@id+1))
update @tb set STATUS=1 where ID=1;
update @tb set STATUS=1 where ID=(@id+1);
SELECT * FROM @
FETCH NEXT FROM c1 INTO @
end
CLOSE c1;
DEALLOCATE c1;
------其他回答（2分）---------新手，学习!------其他回答（2分）---------学习------其他回答（1分）---------谢谢楼主提出讨论相关资料：｜｜｜｜｜｜｜@@--我真的不明白：为什么大部分人认为使用游标速度会很慢！--@@-MS-SQLServer/疑难问题来源网络，如有侵权请告知，即处理！编程Tags：　　　　　　　　　　　　　　　　&　　　　　　　　　　　　　　　　　　　　提高数据库查询效率的一些建议_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
提高数据库查询效率的一些建议
工​作​过​程​中​总​结​出​来​提​高​数​据​库​查​询​效​率​的​一​些​方​法​。
阅读已结束，如果下载本文需要使用
想免费下载本文？
你可能喜欢ljh0242 的BLOG
用户名：ljh0242
文章数：443
评论数：91
访问量：977631
注册日期：
阅读量：3351
阅读量：6643
阅读量：2233
阅读量：2574
51CTO推荐博文
通常我们获取游标数据是用 fetch some_cursor into var1, var2 的形式，当游标中的记录数不多时不打紧。然而自 Oracle 8i 起，Oracle 为我们提供了 fetch bulk collect&来批量取游标中的数据，存中即是合理的。它能在读取游标中大量数据的时候提升效率，就像 SNMP 协议中，V2 版比 V1 版新加了 GET-BULK PDU 一样，也是用来更高效的批量取设备上的节点值（原来做过网管软件开发，故联想到此）。 fetch bulk collect into 的使用格式是：fetch some_cursor collect into col1, col2 limit xxx。col1、col2 是声明的集合类型变量，xxx 为每次取数据块的大小（记录数），相当于缓冲区的大小，可以不指定 limit xxx 大小。下面以实际的例子来说明它的使用，并与逐条取记录的 fetch into 执行效率上进行比较。测试环境是 Oracle 10g& 10.2.1.0，查询的联系人表 sr_contacts 中有记录数 1802983 条，游标中以 rownum 限定返回的记录数。使用 fetch bulk collect into 获取游标数据
declare&& &&
&&type&id_type&is&table&of&sr_contacts.sr_contact_id%&&& &&
&&v_id&id_&&& &&
&&type&phone_type&is&table&of&sr_contacts.contact_phone%&&& &&
&&v_phone&phone_&&& &&
&&type&remark_type&is&table&of&sr_contacts.remark%&&& &&
&&v_remark&remark_&&& &&
&&cursor&all_contacts_cur&is&&&
&&&&&select&sr_contact_id,contact_phone,remark&from&sr_contacts&where&rownum&&=&100000;&&& &&
begin&& &&
&&&&&&& &&
&&&&open&all_contacts_&&& &&
&&&&loop&&& &&
&&&&&&&&fetch&all_contacts_cur&bulk&collect&into&v_id,v_phone,v_remark&limit&256;&&& &&
&&&&&&&&for&i&in&1..v_id.count&loop&&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&null;&&&
&&&&&&&&end&&&& &&
&&&&&&&&exit&when&all_contacts_cur%&&&
&&&&end&&&& &&
&&&&close&all_contacts_&&& &&
end;&&&&declare
--声明需要集合类型及变量，参照字段的 type 来声明类型
type id_type is table of sr_contacts.sr_contact_id%
type phone_type is table of sr_contacts.contact_phone%
v_phone phone_
type remark_type is table of sr_contacts.remark%
v_remark remark_
cursor all_contacts_cur is --用 rownum 来限定取出的记录数来测试
select sr_contact_id,contact_phone,remark from sr_contacts where rownum &= 100000;
open all_contacts_
fetch all_contacts_cur bulk collect into v_id,v_phone,v_remark limit 256;
for i in 1..v_id.count loop --遍历集合
--用 v_id(i)/v_phone(i)/v_remark(i) 取出字段值来执行你的业务逻辑
--这里只放置一个空操作，只为测试循环取数的效率
exit when all_contacts_cur% --exit 不能紧接 fetch 了，不然会漏记录
close all_contacts_
使用 fetch into 逐行获取游标数据
&&v_id&sr_contacts.sr_contact_id% &&
&&v_phone&sr_contacts.contact_phone% &&
&&v_remark&sr_contacts.remark% &&
&&cursor&all_contacts_cur&is&&&&
&&&&&select&sr_contact_id,contact_phone,remark&from&sr_contacts&where&rownum&&=&100000; &&
&&&&open&all_contacts_ &&
&&&&loop &&
&&&&&&&&fetch&all_contacts_cur&into&v_id,v_phone,v_ &&
&&&&&&&&exit&when&all_contacts_cur%&&&& &&
&&&&&&&&&&
&&&&&&&&null;&&&
&&&&end& &&
&&&&close&all_contacts_ &&
end;&&declare
--声明变量，参照字段的 type 来声明类型
v_id sr_contacts.sr_contact_id%
v_phone sr_contacts.contact_phone%
v_remark sr_contacts.remark%
cursor all_contacts_cur is
--用 rownum 来限定取出的记录数来测试
select sr_contact_id,contact_phone,remark from sr_contacts where rownum &= 100000;
open all_contacts_
fetch all_contacts_cur into v_id,v_phone,v_
exit when all_contacts_cur%
--用 v_id/v_phone/v_remark 取出字段值来执行你的业务逻辑
--这里只放置一个空操作，只为测试循环取数的效率
close all_contacts_
执行性能比较看看测试的结果，分别执行五次所耗费的秒数：当 rownum &= 100000 时：fetch bulk collect into 耗时：0.125秒, 0.125秒, 0.125秒, 0.125秒, 0.141秒fetch into 耗时：&&&&&&&&&&&&&&&& 1.266秒, 1.250秒, 1.250秒, 1.250秒, 1.250秒当 rownum &= 1000000 时：fetch bulk collect into 耗时：1.157秒, 1.157秒, 1.156秒, 1.156秒, 1.171秒fetch into 耗时：&&&&&&&&&&&&&&12.128秒, 12.125秒, 12.125秒, 12.109秒, 12.141秒当 rownum &= 10000 时：fetch bulk collect into 耗时：0.031秒, 0.031秒, 0.016秒, 0.015秒, 0.015秒fetch into 耗时：&&&&&&&&&&&&&&&& 0.141秒, 0.140秒, 0.125秒, 0.141秒, 0.125秒当 rownum &= 1000 时：fetch bulk collect into 耗时：0.016秒, 0.015秒, 0.016秒, 0.016秒, 0.015秒fetch into 耗时：&&&&&&&&&&&&&&&&&0.016秒, 0.031秒, 0.031秒, 0.032秒, 0.015秒从测试结果来看游标的记录数越大时，用 fetch bulk collect into 的效率很明显示，趋于很小时就差不多了。注意了没有，前面使用 fetch bulk collect into 时前为每一个查询列都定义了一个集合，这样有些繁琐。我们之前也许用过表的 %rowtype 类型，同样的我们也可以定义表的 %rowtype 的集合类型。看下面的例子，同时在这个例子中，我们借助于集合的 first、last 属性来代替使用 count& 属性来进行遍历。
&&type&contacts_type&is&table&of&sr_contacts% &&
&&v_contacts&contacts_ &&
&&cursor&all_contacts_cur&is&&&
&&&&&select&*&from&sr_contacts&where&rownum&&=&10000; &&
&&&&open&all_contacts_ &&
&&&&loop &&
&&&&&&&&fetch&all_contacts_cur&bulk&collect&into&v_contacts&limit&256; &&
&&&&&&&&for&i&in&v_contacts.first&..&v_contacts.last&loop&&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&null;&&&
&&&&&&&&end& &&
&&&&&&&&exit&when&all_contacts_cur% &&
&&&&end& &&
&&&&close&all_contacts_ &&
end;&&declare
--声明需要集合类型及变量，参照字段的 type 来声明类型
type contacts_type is table of sr_contacts%
v_contacts contacts_
cursor all_contacts_cur is --用 rownum 来限定取出的记录数来测试
select * from sr_contacts where rownum &= 10000;
open all_contacts_
fetch all_contacts_cur bulk collect into v_contacts limit 256;
for i in v_contacts.first .. v_contacts.last loop --遍历集合
--用 v_contacts(i).sr_contact_id/v_contacts(i).contact_phone/v_contacts(i).remark
--的形式来取出各字段值来执行你的业务逻辑
--这里只放置一个空操作，只为测试循环取数的效率
exit when all_contacts_cur%
close all_contacts_
关于 limit 参数你可以根据你的实际来调整 limit 参数的大小，来达到你最优的性能。limit 参数会影响到 pga 的使用率。而且也可以在 fetch bulk 中省略 limit 参数，写成fetch all_contacts_cur bulk collect into v_有些资料中是说，如果不写 limit 参数，将会以数据库的 arraysize& 参数值作为默认值。在 sqlplus 中用 show arraysize& 可以看到该值默认为 15，set arraysize 256 可以更改该值。而实际上我测试不带 limit 参数时，外层循环只执行了一轮，好像不是 limit 15，所以不写 limit 参数时，可以去除外层循环，begin-end 部分可写成：
&&&&open&all_contacts_ &&
&&&&fetch&all_contacts_cur&bulk&collect&into&v_ &&
&&&&for&i&in&v_contacts.first&..&v_contacts.last&loop&&&
&&&&&&&&&&
&&&&&&&&&&
&&&&&&&&null;&&&
&&&&&&&&dbms_output.put_line(2000); &&
&&&&end& &&
&&&&close&all_contacts_ &&
end;&&begin
open all_contacts_
fetch all_contacts_cur bulk collect into v_
for i in v_contacts.first .. v_contacts.last loop --遍历集合
--用 v_contacts(i).sr_contact_id/v_contacts(i).contact_phone/v_contacts(i).remark
--的形式来取出各字段值来执行你的业务逻辑
--这里只放置一个空操作，只为测试循环取数的效率
dbms_output.put_line(2000);
close all_contacts_
bulk collect 的其他用法(总是针对集合)select into 语句中，如：SELECT sr_contact_id,contact_phone BULK COLLECT INTO v_id,v_phone&&&& FROM sr_contacts WHERE ROWNUM &= 100;dbms_output.put_line('Count:'||v_id.count||', First:'||v_id(1)||'|'||v_phone(1));returning into 语句中，如：DELETE FROM sr_contacts WHERE sr_contact_id & 30&&& RETURNING sr_contact_id, contact_phone BULK COLLECT INTO v_id, v_dbms_output.put_line('Count:'||v_id.count||', First:'||v_id(1)||'|'||v_phone(1));forall 的 bulk dml 操作，它大大优于 for 集合后的操作fetch all_contacts_cur bulk collect into v_forall i in 1 .. v_contacts.count--forall i in v_contacts.first .. v_contacts.last&& --forall i in indices of v_contacts --10g以上,可以是非连续的集合&& insert into sr_contacts(sr_contact_id,contact_phone,remark) &&& values(v_contacts(i).sr_contact_id,v_contacts(i).contact_phone,v_contacts(i).remark); &&& --或者是单条的 delete/update 操作参考：1. &&&&&&& 2. &&&&&&& 3. &&&&&&& 4. &&&&&& &5. &&&&&&& 6. &&&&&&& 7. &&&&&&& 8.
了这篇文章
类别：┆阅读(0)┆评论(0)关于mysql处理百万级以上的数据时如何提高其查询速度的方法
关于mysql处理百万级以上的数据时如何提高其查询速度的方法
最近一段时间由于工作需要，开始关注针对Mysql的select查询语句的相关优化方法。&
& & & 由于在参与的实际项目中发现当表的数据量达到百万级时，普通SQL查询效率呈直线下降，而且如果where中的查询条件较多时，其查询速度简直无法容忍。曾经测试对一个包含400多万条记录（有索引）的表执行一条条件查询，其查询时间竟然高达40几秒，相信这么高的查询延时，任何用户都会抓狂。因此如何提高sql语句查询效率，显得十分重要。以下是网上流传比较广泛的30种SQL查询语句优化方法：&
1、应尽量避免在 where 子句中使用!=或&&操作符，否则将引擎放弃使用索引而进行全表扫描。&
2、对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。&
3、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：&
& & &select id from t where num is null&
& & &可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：&
& & &select id from t where num=0&
4、尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：&
& & &select id from t where num=10 or num=20&
& & &可以这样查询：&
& & &select id from t where num=10&
& & &union all&
& & &select id from t where num=20&
5、下面的查询也将导致全表扫描：(不能前置百分号)&
& & &select id from t where name like &%c%&&
& & 若要提高效率，可以考虑全文检索。&
6、in 和 not in 也要慎用，否则会导致全表扫描，如：&
& & &select id from t where num in(1,2,3)&
& & &对于连续的数值，能用 between 就不要用 in 了：&
& & &select id from t where num between 1 and 3&
7、如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：&
& & &select id from t where num=@num&
& & &可以改为强制查询使用索引：&
& & &select id from t with(index(索引名)) where num=@num&
8、应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：&
& & &select id from t where num/2=100&
& & &应改为:&
& & &select id from t where num=100*2&
9、应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：&
& & &select id from t where substring(name,1,3)=&abc&&name以abc开头的id&
& & &select id from t where datediff(day,createdate,&&)=0&&&生成的id&
& & &应改为:&
& & &select id from t where name like &abc%&&
& & &select id from t where createdate&=&& and createdate&&&&
10、不要在 where 子句中的&=&左边进行函数、算术运算或其他表达式运算，否则将可能无法正确使用索引。&
11、在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使 用，并且应尽可能的让字段顺序与索引顺序相一致。&
12、不要写一些没有意义的查询，如需要生成一个空表结构：&
& & &select col1,col2 into #t from t where 1=0&
& & &这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：&
& & &create table #t(&)&
13、很多时候用 exists 代替 in 是一个好的选择：&
& & &select num from a where num in(select num from b)&
& & &用下面的语句替换：&
& & &select num from a where exists(select 1 from b where num=a.num)&
14、并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段 sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。&
15、索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有 必要。&
16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。&
17、尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会 逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。&
18、尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。&
19、任何地方都不要使用 select * from t ，用具体的字段列表代替&*&，不要返回用不到的任何字段。&
20、尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。&
21、避免频繁创建和删除临时表，以减少系统表资源的消耗。&
22、临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使 用导出表。&
23、在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。&
24、如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。&
25、尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。&
26、使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。&
27、与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括&合计&的例程通常要比使用游标执行的速度快。如果开发时 间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。&
28、在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。&
29、尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。&
30、尽量避免大事务操作，提高系统并发能力。
您对本文章有什么意见或着疑问吗？请到您的关注和建议是我们前行的参考和动力&&
您的浏览器不支持嵌入式框架，或者当前配置为不显示嵌入式框架。