① 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語句分批處理。有時間多看看開窗語句，很實用。