存儲過程執行的效率問題...(內詳,跟蹤過存儲過程執行的過來看看,盡早結貼.)

Question

比如說sql有個半秒執行一次的任務(job)
---------
是不是这个job给存储过程中的用到表加锁了？

Answer 1

希望繼續關注,ls兩拉的問題解答如下..1.是不是这个job给存储过程中的用到表加锁了？
=========================================
應該沒有,由於設計的在系統中不是job.只是一個每隔半秒的簡單語句(select * from table_X where ....)只是每次select ,由系統的另一程序執行...而且這個表table_x跟我這個里面的啥關系都沒有..2.你把job停一下再运行试试看
==============================
這個已試,在測試機上是沒有job的,其餘的都一樣,在測試機上這個時間是符合要求的855
以上步驟的時間分別是
1.31
2.47
3.0
4.31
5.47
6.0
總時間 855   >> 31+47+0+31+47+0=156  還有時間呢,差不多700ms..
這個時間到底去哪了....????

Answer 2

wojila(阳阳) 
===========================================
謝謝,發給我可以試試.問題是這個時間差太大了.別的存儲過程都不曾產生這麼大的時間差..
一般也就0~~10 ms

Answer 3

每执行一次存储过程，系统默认会重新编译该存储过程一次
－－－－－－－－－
不会，除非编写存储过程或者运行时加with RECOMPILE

Answer 4

这个问题还是很头疼的，估计应该和SQL内部的机制有联系，谁叫微软自己都说sql server 2000不可靠呢！！！！  - -！

Answer 5

補充一下....第二步,第五步,是一個關聯更新..
2.
update table_B set col1=3 from table_A,table_B where Table_A.col4=@var and table_A.col5=table_B.col3update table_B set col1=3 from #tmpTable,table_B where tmpTable.col4=@var and tmpTable.col5=table_B.col3嘻嘻,我這proc其實是一個如下的結构
if (aaaa)else if (bbbb)else if (cccc)elsebbb.ccc.else都沒有問題,就是aaaa有問題,不同的是aaaa條件有#tmpTAble其餘的沒有.一會我自已不用#tmpTable試下..不明白的是跟蹤到的#tmpTable產生的時間少也就(50-100ms)不明白為什麼會差這么多.