日期:2014-05-18  浏览次数:20746 次

存儲過程執行的效率問題...(內詳,跟蹤過存儲過程執行的過來看看,盡早結貼.)
我有一存儲儲過程.執行要求在1秒內完成...(可先看問題)

結構如下:
    proc   up_test
1.語句一         insert   into   Table_C   select   from   Table_A
2.語句二         update   Table_B  
3.語句三         select   *   into   #tmpTable   select   *   from   Table_A
4.語句四         insert   into   table_C   from   #tmpTable
5.語句五         update   table_B
5.語句六         drop   table   #tmpTable

我打開跟蹤分析器(sql)執行的時間如下.
              時間                   select/insert/update出來的條數       原始的記錄數
1.           34                       1000                                                             30W
2.           67                       1000                                                             1500
3.           172                     1000                                                             30W
4.           110                     1000                                                             1000
5.           170                     500                                                               1500
6.           0

從上面很容易看到這個過程執行的時間是
34+67+172+110+170=   553               多次試驗這加起來的數字是     610,775.....等,不超過1秒.是符合要求的...

但是最后存儲過程的總時間是SP:complete   :1230         rpc:complete   1231
這個時間就不一樣了.跟前面加起來的總值不一樣..這個就不合要求了超過一秒...

跟蹤中發現建立臨時表sql會做一些動作,,這個時間加起來也就是100ms左右..加上這個時間也跟最後的總執行時間有大的出入啊....

        請問:1.分步的執行時間加起來為什麼會不等于總的執行時間...(即使是加上臨時表處理跟蹤到的時間)
                  2.存儲過程執行時間跟sql的負荷有關么...(比如說sql有個半秒執行一次的任務(job),分析器會不會把這個任務的時間算在我這個存儲過程頭上?     或者說sql執行up_test的時間會把等待這個任務完成的時間也算在里面,但跟蹤器就不會跟蹤到這個時間.正好,總時間減去單步時間的總和就正好是.up_test的等待時間..

      希望能解決.給點思路也不錯..先謝謝了..盡早結貼..:)

------解决方案--------------------
比如說sql有個半秒執行一次的任務(job)
---------
是不是这个job给存储过程中的用到表加锁了?
------解决方案--------------------
我们上课的时候 老师好像曾经说过 每执行