1、優化SQL語句，SQL語句對查詢速度影響最大
2、對於經常查詢的欄位作索引。
② sql存儲過程耗時太長
多長都有可能，40是很正常的。
1．盡量優化語句，盡量少用游標。
2．修改較為常用的表要注意，最好先在臨時表中作好運算和其它處理，最後在修改這些表，以免較慢的存儲過程長時間鎖定表記錄，影響數據正常使用。
3．將連接超時和命令超時適當擴大，以免超時錯誤。
③ sql語句和存儲過程執行速度的問題
一千萬條數據，數據是一樣的，執行相同的insert語句
也就是 SQL 語句，只分析一次， 然後執行 一千萬次。
理論上 存儲過程的會快一點， 因為 存儲過程 在 sql 調用的時候，只調用 1次， 然後伺服器端 執行 一千萬次 insert 操作。 然後返回一次結果給客戶端。
sql 語句的話， 要在 sql 客戶端 發起 一千萬次調用， 服務端執行 一千萬次 INSERT操作， 然後 返回 一千萬次 執行結果給 客戶端。
④ 存儲過程比SQL語句慢的問題,痛苦中.....
1首先存儲過程是預編譯，按理說應該會比程序運行的語句效率高，如果時間反而長的話，可能是統計信息沒有及時更新導致優化器給存儲過程與單語句生成了不同的查詢計劃，而用片面的統計信息生成的查詢計劃會導致索引利用率低效，試試更新統計信息或者重建/重組索引
2一次提交查詢6、7百次？這樣的系統我還未見過，如果可以的話，現將需要的表數據緩存到伺服器或者本地內存中，在內存中進行數據的操作，當然存儲過程對復雜的查詢會有一定的優化效果的
⑤ sql server存儲過程執行速度慢如何優化
語句拿出來，幫你看一下。
存儲過程，實際上和SQL語句區別不大，就是提前編譯了。
有的時候還不如SQL語句，最起碼語句連在一起算事務，存儲過程需要自己起事務。
⑥ SQL 2005存儲過程莫名慢
你在查詢分析器里，先打開「執行計劃」，然後執行存儲過程，跟蹤看慢在哪裡吧
⑦ SQL Server中，存儲過程執行速度比較慢，有優化的方案嗎
主要有兩種方法
1、優化SQL的邏輯，使得邏輯越簡單越好。
2、使用到的表結構要建索引
⑧ oracle資料庫存儲過程執行慢時如何優化
1 首先看看，先分析慢的原因，一部分是因為循環次數多，一部分是因為查詢數據量大慢。
2 可以從優化查詢入手，比如某次查詢的sql裡面的數據，條件欄位沒有建索引，導致了全表掃描，
是不是 只需要幾個欄位，但是你寫了 select * 等等，總之要優化數據的速度。
2 可以從循環邏輯看起，有些循環可能是不必要的，能不能通過條件查詢來替代循環，總之要從邏輯上優化代碼
⑨ mysql 存儲過程執行太慢怎麼優化
1.當我們請求mysql伺服器的時候,MySQL前端會有一個監聽,請求到了之後,伺服器得到相關的SQL語句,執行之前(虛線部分為執行),還會做許可權的判斷
2.通過許可權之後,SQL就到MySQL內部,他會在查詢緩存中,看該SQL有沒有執行過,如果有查詢過,則把緩存結果返回,說明在MySQL內部,也有一個查詢緩存.但是這個查詢緩存,默認是不開啟的,這個查詢緩存,和我們的Hibernate，Mybatis的查詢緩存是一樣的,因為查詢緩存要求SQL和參數都要一樣,所以這個命中率是非常低的（沒什麼卵用的意思）。
3.如果我們沒有開啟查詢緩存,或者緩存中沒有找到對應的結果,那麼就到了解析器,解析器主要對SQL語法進行解析
4.解析結束後就變成一顆解析樹,這個解析樹其實在Hibernate裡面也是有的,大家回憶一下,在以前做過Hibernate項目的時候,是不是有個一個antlr.jar。這個就是專門做語法解析的工具.因為在Hibernate裡面有HQL，它就是通過這個工具轉換成SQL的,我們編程語言之所以有很多規范、語法,其實就是為了便於這個解析器解析,這個學過編譯原理的應該知道.
5.得到解析樹之後,不能馬上執行,這還需要對這棵樹進行預處理,也就是說,這棵樹,我沒有經過任何優化的樹,預處理器會這這棵樹進行一些預處理,比如常量放在什麼地方,如果有計算的東西,把計算的結果算出來等等...
6.預處理完畢之後,此時得到一棵比較規范的樹,這棵樹就是要拿去馬上做執行的樹,比起之前的那棵樹,這棵得到了一些優化
7.查詢優化器，是MySQL裡面最關鍵的東西,我們寫任何一條SQL,比如SELECT * FROM USER WHERE USERNAME = toby AND PASSWORD = 1,它會怎麼去執行?它是先執行username = toby還是password = 1?每一條SQL的執行順序查詢優化器就是根據MySQL對數據統計表的一些信息,比如索引,比如表一共有多少數據,MySQL都是有緩存起來的,在真正執行SQL之前,他會根據自己的這些數據,進行一個綜合的判定,判斷這一次在多種執行方式裡面,到底選哪一種執行方式,可能運行的最快.這一步是MySQL性能中,最關鍵的核心點,也是我們的優化原則.我們平時所講的優化SQL,其實說白了,就是想讓查詢優化器,按照我們的想法,幫我們選擇最優的執行方案,因為我們比MySQL更懂我們的數據.MySQL看數據,僅僅只是自己收集到的信息,這些信息可能是不準確的,MySQL根據這些信息選了一個它自認為最優的方案,但是這個方案可能和我們想像的不一樣.
8.這里的查詢執行計劃,也就是MySQL查詢中的執行計劃,比如要先執行username = toby還是password = 1
9.這個執行計劃會傳給查詢執行引擎,執行引擎選擇存儲引擎來執行這一份傳過來的計劃,到磁碟中的文件中去查詢,這個時候重點來了,影響這個查詢性能最根本的原因是什麼?就是硬碟的機械運動,也就是我們平時熟悉的IO,所以一條查詢語句是快還是慢,就是根據這個時間的IO來確定的.那怎麼執行IO又是什麼來確定的?就是傳過來的這一份執行計劃.(優化就是制定一個我們認為最快的執行方案,最節省IO,和執行最快)
10.如果開了查詢緩存,則返回結果給客戶端,並且查詢緩存也放一份。
⑩ SQL存儲過程比SQL語句慢，甚至卡死
樓主，你好！這個排版屌爆了%>_<%
USE[HERP_BHYY]
GO
/******對象:StoredProcere[dbo].[sp_]腳本日期:12/03/201308:36:35******/
SETANSI_NULLSON
GO
SETQUOTED_IDENTIFIERON
GO
ALTERPROCEDURE[dbo].[sp_]
@ImpDateasDATETIMEASBEGIN
--SETNOCOUNTON;
DECLARE@ST_DATEASDATETIME
DECLARE@ED_DATEASDATETIME
DECLARE@TEMP_DATEDATETIME
IF@ImpDateisnotnull
begin
SET@ST_DATE=LEFT(@ImpDate,10)
SET@ED_DATE=dateadd(day,1,@ST_DATE)
end
deletehisdb2.dbo.his_charge_acc_o
wherecharge_date>=@ST_DATEandcharge_date<@ed_date
insert=""into=""hisdb2.dbo.his_charge_acc_o=""
select=""invoice_type=""from=""
where=""charge_date="">=@ST_DATEandcharge_date<@ED_DATE
end
這樣不是挺好么？
上面的SQL語句貌似漏了什麼東西，你自己看看