① 6、什么是存储过程什么是游标，何时使用、何时不用游标
存储过程是一组命名了的sql语句集合，是为了完成特定功能汇集而成的。该集合编译后存放在数据库中，可根据实际情况重新编译，可直接运行，也可远程运行且存储过程直接在服务器端运行。
游标实际上是一种能从包括多条数据记录的结果集（结果集是select查询之后返回的所有行数据的集合）中每次提取一条记录的机制充当指针的作用，遍历结果中的所有行，但他一次只指向一行。
游标在循环处理字段的时候使用
建议：尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写；使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效；与临时表一样，游标并不是不可使用。
② 在MySQL 存储过程中，查询出来的结果集，不用游标还可以怎么遍历
从存储过程返回表类型的值也有二种:
1.存储过程使用浮标参数,即同时指定CURSOR VARYING OUTPUT项.调用者可以使用while及fetch循环遍历该浮标.
2.直接将存储过程返回的结果集插入到表中,即使用insert into 表名 exec 存储过程.此种方式中注意存储过程返回的结果集列与insert的列要完全对应,可以在insert中指定列名来保证对应关系.
------------------------------------------------------------------------------测试:------------------------------------------------------------------------------
----建立测试用的临时表
create table #tmp (colx int,coly int)
insert into #tmp values(1,2)
insert into #tmp values(2,3)
insert into #tmp values(3,4)
select * from #tmpGO----创建返回游标的存储过程
③ 在存储过程中，为了在一个结果集的记录中进行循环，除了用游标还能用其他的方式吗
临时表 或表变量都可以 例如:sqlserver数据库，你的结果集为 T_Table
if object_id('tempdb..#tmp') > 0
drop table #tmp
declare @ID int
select identity(int,1,1) as ID,* from T_Table
select @ID = 1
while Exists(select * from #tmp)
begin
select @变量 = 字段 from #tmp where id = @id
select @ID = @ID + 1
end
将临时表 换成表变量也可以
不用游标可以避免 游标的释放问题和游标重名的问题。
如果只是为了速度 就无所谓了，游标的性能没有大家说的那么差，关键就看你怎么写就是了
没有环境，自己调整一下吧
④ oracle存储过程 除了游标还有什么方法接收结果集
。。不过我有个问题，vc调用这些方法与存储过程内部有什么关系呢 追问： 因为VC调用存储过程 要接收结果集. 但是VC李没有能接收游标的类型. 所以存储过程中不能用游标. 还有什么其他的方法保存结果集嘛? 回答： 我不知道我这样处理行不行，从存储过程里得到的结果用 ，隔开 也就是相当于在存储过程中做了这一步。返回结果用一个字符串来处理？这样不行？ 之后根据这个字符进行分割。。那你要说vc没有数组我就没办法了 追问： 但是效率会降低很多 数据量比较大呵呵。 回答： 数据量大的瓶颈应该是在存储过程上，因为游标本身就慢，想必你也用了类似for循环的东西，那为何不把存储的东西搬出来呢？ 追问： 因为搬出来 sql语句的长度有限 字符太长 会出问题.工作需要 能过程最好过程 哎. 麻烦阿. 回答： 这个你把循环拿出来程序来跑就行了，oracle也就是游标和隐式游标，返回结果集我一般都是自己拼接。不过拼接完后，程序在处理spilt时会慢，这种当然最好实现。要么就是把存储中的需要用游标的地方用程序来实现，这样效率应该会好些，不过可能费事吧。 追问： 恩 这东西已经问了半个月了 -。- 都没什么很好的解决方法 哎。 天要亡我阿。
⑤ SQL Server 优化存储过程的方法有哪些
优化存储过程有很多种方法，下面介绍最常用的7种。
1.使用SET NOCOUNT ON选项
我们使用SELECT语句时，除了返回对应的结果集外，还会返回相应的影响行数。使用SET NOCOUNT ON后，除了数据集就不会返回额外的信息了，减小网络流量。
2.使用确定的Schema
在使用表，存储过程，函数等等时，最好加上确定的Schema。这样可以使SQL Server直接找到对应目标，避免去计划缓存中搜索。而且搜索会导致编译锁定，最终影响性能。比如select * from dbo.TestTable比select * from TestTable要好。from TestTable会在当前Schema下搜索，如果没有，再去dbo下面搜索，影响性能。而且如果你的表是csdn.TestTable的话，那么select * from TestTable会直接报找不到表的错误。所以写上具体的Schema也是一个好习惯。
3.自定义存储过程不要以sp_开头
因为以sp_开头的存储过程默认为系统存储过程，所以首先会去master库中找，然后在当前数据库找。建议使用USP_或者其他标识开头。
4.使用sp_executesql替代exec
原因在Inside Microsoft SQL Server 2005 T-SQL Programming书中的第四章Dynamic SQL里面有具体描述。这里只是简单说明一下：sp_executesql可以使用参数化，从而可以重用执行计划。exec就是纯拼SQL语句。
5.少使用游标
可以参考Inside Microsoft SQL Server 2005 T-SQL Programming书中的第三章Cursors里面有具体描述。总体来说，SQL是个集合语言，对于集合运算具有较高的性能，而Cursors是过程运算。比如对一个100万行的数据进行查询，游标需要读表100万次，而不使用游标只需要少量几次读取。
6.事务越短越好
SQL Server支持并发操作。如果事务过多过长，或是隔离级别过高，都会造成并发操作的阻塞，死锁。此时现象是查询极慢，同时cup占用率极低。
7.使用try-catch来处理错误异常
SQL Server 2005及以上版本提供对try-catch的支持，语法为：
begin try
----your code
end try
begin catch
--error dispose
end catch
一般情况可以将try-catch同事务结合在一起使用。
begin try
begin tran
--select
--update
--delete
--…………
commit
end try
begin catch
--if error
rollback
end catch
====================== 分割线 =======================
‘自己的一些调优经验’
1. 少使用游标是个很好的建议，为此，我自己也遇到过一些事故，是游标所造成的，由于，游标是逐行逐行操作的，当记录较多时，经常会遇到超时的情况。
2. 多表join做查询时，查询的字段尽量不要使用case when then else end的语法，或者使用用户函数，例如：
select (case when fType=1 then '是' else '否' end) as fTypeName, dbo.F_GetFullName(fID) as fFullName from Table1 inner join Table2……
当两个表的数据量非常大时，你可以在查询分析器中明显感觉到：直接查询fType和fID与查询上面两个字段的速度，很可能使用了一个case when then就导致超时。
针对这种情况，可以分两种做法：
第一，把一些简单的转换可以放在程序中完成。
第二，如果需要通过ID查询全名或者全称，类似的，可以创建好视图，直接查视图，或者，先把所有的fFullName查出来放到临时表中，直接join临时表（如果这个数据不是很多的话），获得fFullName。
3. 少使用一些嵌套的查询，用临时表缓存中间数据，例如：
select * from Table1
inner join (
select count(1) as count, Table2.ID2 from Table2 inner join Table3 on ID2=ID3 group by Table2.ID2
) as t1 on t1.ID1 = Table1.ID1
我曾经遇到这样情况，上面的语句是那种情况的简化版本，把其他不影响结果的表格都去掉了，发现一个奇怪的现象：嵌套查询的结果集并不大，大约就200多行，Table1有6w条记录，结果，这个查询语句超时，查询分析器中执行2分钟也得不到结果。
后来，这样一改，就Ok了，3秒出结果：
select count(1) as count, Table2.ID2 into #temp from Table2 inner join Table3 on ID2=ID3 group by Table2.ID2
select * from Table1
inner join #temp as t1 on t1.ID1 = Table1.ID1
这样一改，效率提升了几十倍，猜想：可能是嵌套的查询是动态的，每一行的join可能都需要先执行嵌套的查询，从而导致效率极差。
所以，如果查询足够复杂，join多个表，需要连接多个通过group by求和、求平均数等运算计算出来的中间数据，那么，不妨多使用临时表缓存中间数据。
4. 还有一些是必须遵守的一些默认规则，比如：
先过滤后连接。
查询的字段最要不要用“*”，指定需要用的字段，减少网络流量。
‘总结’
对于性能的追求是没有极限的，做到你所能做到的，这是一个很好的习惯。
有些业务逻辑放在存储过程中处理比较方便，而有些业务逻辑交给程序来处理，同样会提升系统整体的效率，看实际情况而定。
总之，尽可能减少这些容易引发性能问题的隐患，系统就会跑得更稳定更有效率，一切从小细节做起。
⑥ 存储过程，如果不用游标，可以用什么代替
少用游标。尽量用一条sql语句代替。或者用多条SQL语句分批处理。有时间多看看开窗语句，很实用。