sql語句性能

『壹』 如何進行sql性能優化

這里分享下mysql優化的幾種方法。

1、首先在打開的軟體中，需要分別為每一個表創建 InnoDB FILE的文件。

『貳』 sql語句性能如何優化

如何加快查詢速度?
1、升級硬體
2、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。
3、擴大伺服器的內存
4、增加伺服器CPU個數
5、對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能
6、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
7、查詢時不要返回不需要的行、列
8、用select
top
100
/
10
Percent
來限制用戶返回的行數或者SET
ROWCOUNT來限制操作的行
9、在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，減少判斷的次數
10、一般在GROUP
BY
個HAVING字句之前就能剔除多餘的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：
select的Where字句選擇所有合適的行，Group
By用來分組個統計行，Having字句用來剔除多餘的分組。這樣Group
By
個Having的開銷小，查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group
BY的目的不包括計算，只是分組，那麼用Distinct更快
11、一次更新多條記錄比分多次更新每次一條快,就是說批處理好

『叄』 如何寫出高性能SQL語句

優化SQL查詢：如何寫出高性能SQL語句
1、首先要搞明白什麼叫執行計劃？
執行計劃是資料庫根據SQL語句和相關表的統計信息作出的一個查詢方案，這個方案是由查詢優化器自動分析產生欀如一條SQL語句如果用來從一個10萬條記錄的表中查1條記錄，那查詢優化器會選擇「索引查找」方式，如果該表進行了歸檔，當前只剩下5000條記錄了，那查詢優化器就會改變方案，採用 「全表掃描」方式。

可見，執行計劃並不是固定的，它是「個性化的」。產生一個正確的「執行計劃」有兩點很重要：

(1) SQL語句是否清晰地告訴查詢優化器它想干什麼？

(2) 查詢優化器得到的資料庫統計信息是否是最新的、正確的？

2、統一SQL語句的寫法
對於以下兩句SQL語句，程序員認為是相同的，資料庫查詢優化器認為是不同的。

select * from al
select * From al

其實就是大小寫不同，查詢分析器就認為是兩句不同的SQL語句，必須進行兩次解析。生成2個執行計劃。
所以作為程序員，應該保證相同的查詢語句在任何地方都一致，多一個空格都不行！

3、不要把SQL語句寫得太復雜
我經常看到，從資料庫中捕捉到的一條SQL語句列印出來有2張A4紙這么長。一般來說這么復雜的語句通常都是有問題的。我拿著這2頁長的SQL語句去請教原作者，結果他說時間太長，他一時也看不懂了。可想而知，連原作者都有可能看糊塗的SQL語句，資料庫也一樣會看糊塗。

一般，將一個Select語句的結果作為子集，然後從該子集中再進行查詢，這種一層嵌套語句還是比較常見的，但是根據經驗，超過3層嵌套，查詢優化器就很容易給出錯誤的執行計劃。因為它被繞暈了。像這種類似人工智慧的東西，終究比人的分辨力要差些，如果人都看暈了，我可以保證資料庫也會暈的。

另外，執行計劃是可以被重用的，越簡單的SQL語句被重用的可能性越高。而復雜的SQL語句只要有一個字元發生變化就必須重新解析，然後再把這一大堆垃圾塞在內存里。可想而知，資料庫的效率會何等低下。

4、使用「臨時表」暫存中間結果
簡化SQL語句的重要方法就是採用臨時表暫存中間結果，但是，臨時表的好處遠遠不止這些，將臨時結果暫存在臨時表，後面的查詢就在tempdb中了，這可以避免程序中多次掃描主表，也大大減少了程序執行中「共享鎖」阻塞「更新鎖」，減少了阻塞，提高了並發性能。

5、 OLTP系統SQL語句必須採用綁定變數
select * from orderheader where changetime > 』2010-10-20 00:00:01′
select * from orderheader where changetime > 』2010-09-22 00:00:01′

以上兩句語句，查詢優化器認為是不同的SQL語句，需要解析兩次。
如果採用綁定變數

select * from orderheader where changetime > @chgtime

@chgtime變數可以傳入任何值，這樣大量的類似查詢可以重用該執行計劃了，這可以大大降低資料庫解析SQL語句的負擔。一次解析，多次重用，是提高資料庫效率的原則。

6、綁定變數窺測
事物都存在兩面性，綁定變數對大多數OLTP處理是適用的，但是也有例外。
比如在where條件中的欄位是「傾斜欄位」的時候。

「傾斜欄位」指該列中的絕大多數的值都是相同的，一張人口調查表，其中「民族」這列，90%以上都是漢族。那麼如果一個SQL語句要查詢30歲的漢族人口有多少，那「民族」這列必然要被放在where條件中。這個時候如果採用綁定變數@nation會存在很大問題。

試想如果@nation傳入的第一個值是「漢族」，那整個執行計劃必然會選擇表掃描。然後，第二個值傳入的是「布依族」，按理說「布依族」占的比例可能只有萬分之一，應該採用索引查找。但是，由於重用了第一次解析的「漢族」的那個執行計劃，那麼第二次也將採用表掃描方式。這個問題就是著名的「綁定變數窺測」，建議對於「傾斜欄位」不要採用綁定變數。

7、 只在必要的情況下才使用begin tran
SQL Server中一句SQL語句默認就是一個事務，在該語句執行完成後也是默認commit的。其實，這就是begin tran的一個最小化的形式，好比在每句語句開頭隱含了一個begin tran，結束時隱含了一個commit。

有些情況下，我們需要顯式聲明begin tran，比如做「插、刪、改」操作需要同時修改幾個表，要求要麼幾個表都修改成功，要麼都不成功。begin tran 可以起到這樣的作用，它可以把若干SQL語句套在一起執行，最後再一起commit。好處是保證了數據的一致性，但任何事情都不是完美無缺的。Begin tran付出的代價是在提交之前，所有SQL語句鎖住的資源都不能釋放，直到commit掉。

可見，如果Begin tran套住的SQL語句太多，那資料庫的性能就糟糕了。在該大事務提交之前，必然會阻塞別的語句，造成block很多。

Begin tran使用的原則是，在保證數據一致性的前提下，begin tran 套住的SQL語句越少越好！有些情況下可以採用觸發器同步數據，不一定要用begin tran。

8、一些SQL查詢語句應加上nolock
在SQL語句中加nolock是提高SQL Server並發性能的重要手段，在oracle中並不需要這樣做，因為oracle的結構更為合理，有undo表空間保存「數據前影」，該數據如果在修改中還未commit，那麼你讀到的是它修改之前的副本，該副本放在undo表空間中。這樣，oracle的讀、寫可以做到互不影響，這也是oracle 廣受稱贊的地方。

SQL Server 的讀、寫是會相互阻塞的，為了提高並發性能，對於一些查詢，可以加上nolock，這樣讀的時候可以允許寫，但缺點是可能讀到未提交的臟數據。
使用 nolock有3條原則。

(1) 查詢的結果用於「插、刪、改」的不能加nolock ！

(2) 查詢的表屬於頻繁發生頁分裂的，慎用nolock ！

(3) 使用臨時表一樣可以保存「數據前影」，起到類似oracle的undo表空間的功能，

能採用臨時表提高並發性能的，不要用nolock 。

9、聚集索引沒有建在表的順序欄位上，該表容易發生頁分裂
比如訂單表，有訂單編號orderid，也有客戶編號contactid，那麼聚集索引應該加在哪個欄位上呢？對於該表，訂單編號是順序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，這樣不容易經常產生頁分裂。然而，由於大多數查詢都是根據客戶編號來查的，因此，將聚集索引加在contactid上才有意義。而contactid對於訂單表而言，並非順序欄位。

比如「張三」的「contactid」是001，那麼「張三」的訂單信息必須都放在這張表的第一個數據頁上，如果今天「張三」新下了一個訂單，那該訂單信息不能放在表的最後一頁，而是第一頁！如果第一頁放滿了呢？很抱歉，該表所有數據都要往後移動為這條記錄騰地方。

SQL Server的索引和Oracle的索引是不同的，SQL Server的聚集索引實際上是對表按照聚集索引欄位的順序進行了排序，相當於oracle的索引組織表。SQL Server的聚集索引就是表本身的一種組織形式，所以它的效率是非常高的。也正因為此，插入一條記錄，它的位置不是隨便放的，而是要按照順序放在該放的數據頁，如果那個數據頁沒有空間了，就引起了頁分裂。所以很顯然，聚集索引沒有建在表的順序欄位上，該表容易發生頁分裂。

曾經碰到過一個情況，一位哥們的某張表重建索引後，插入的效率大幅下降了。估計情況大概是這樣的。該表的聚集索引可能沒有建在表的順序欄位上，該表經常被歸檔，所以該表的數據是以一種稀疏狀態存在的。比如張三下過20張訂單，而最近3個月的訂單只有5張，歸檔策略是保留3個月數據，那麼張三過去的 15張訂單已經被歸檔，留下15個空位，可以在insert發生時重新被利用。在這種情況下由於有空位可以利用，就不會發生頁分裂。但是查詢性能會比較低，因為查詢時必須掃描那些沒有數據的空位。

重建聚集索引後情況改變了，因為重建聚集索引就是把表中的數據重新排列一遍，原來的空位沒有了，而頁的填充率又很高，插入數據經常要發生頁分裂，所以性能大幅下降。

對於聚集索引沒有建在順序欄位上的表，是否要給與比較低的頁填充率？是否要避免重建聚集索引？是一個值得考慮的問題！

10、加nolock後查詢經常發生頁分裂的表，容易產生跳讀或重復讀
加nolock後可以在「插、刪、改」的同時進行查詢，但是由於同時發生「插、刪、改」，在某些情況下，一旦該數據頁滿了，那麼頁分裂不可避免，而此時nolock的查詢正在發生，比如在第100頁已經讀過的記錄，可能會因為頁分裂而分到第101頁，這有可能使得nolock查詢在讀101頁時重復讀到該條數據，產生「重復讀」。同理，如果在100頁上的數據還沒被讀到就分到99頁去了，那nolock查詢有可能會漏過該記錄，產生「跳讀」。

上面提到的哥們，在加了nolock後一些操作出現報錯，估計有可能因為nolock查詢產生了重復讀，2條相同的記錄去插入別的表，當然會發生主鍵沖突。

11、使用like進行模糊查詢時應注意
有的時候會需要進行一些模糊查詢比如

select * from contact where username like 『%yue%』

關鍵詞%yue%，由於yue前面用到了「%」，因此該查詢必然走全表掃描，除非必要，否則不要在關鍵詞前加%，

12、數據類型的隱式轉換對查詢效率的影響
sql server2000的資料庫一的程序在提交sql語句的時候，沒有使用強類型提交這個欄位的值，由sql server 2000自動轉換數據類型，會導致傳入的參數與主鍵欄位類型不一致，這個時候sql server 2000可能就會使用全表掃描。Sql2005上沒有發現這種問題，但是還是應該注意一下。

13、SQL Server 表連接的三種方式
(1) Merge Join

(2) Nested Loop Join

(3) Hash Join

SQL Server 2000隻有一種join方式——Nested Loop Join，如果A結果集較小，那就默認作為外表，A中每條記錄都要去B中掃描一遍，實際掃過的行數相當於A結果集行數x B結果集行數。所以如果兩個結果集都很大，那Join的結果很糟糕。

SQL Server 2005新增了Merge Join，如果A表和B表的連接欄位正好是聚集索引所在欄位，那麼表的順序已經排好，只要兩邊拼上去就行了，這種join的開銷相當於A表的結果集行數加上B表的結果集行數，一個是加，一個是乘，可見merge join 的效果要比Nested Loop Join好多了。

如果連接的欄位上沒有索引，那SQL2000的效率是相當低的，而SQL2005提供了Hash join，相當於臨時給A，B表的結果集加上索引，因此SQL2005的效率比SQL2000有很大提高，我認為，這是一個重要的原因。

總結一下，在表連接時要注意以下幾點：

(1) 連接欄位盡量選擇聚集索引所在的欄位

(2) 仔細考慮where條件，盡量減小A、B表的結果集

(3) 如果很多join的連接欄位都缺少索引，而你還在用SQL Server 2000，趕緊升級吧。

『肆』 測試sql語句性能

有時候我們經常為我們的sql語句執行效率低下發愁 反復優化後 可還是得不到提高

那麼你就用這條語句找出你sql到底是在哪裡慢了

示例

SET STATISTICS io ON SET STATISTICS time ON go 你要測試的sql語句 select top * from TBL_Cot_RecStaticList go SET STATISTICS profile OFF SET STATISTICS io OFF SET STATISTICS time OFF

顯示信息

SQL Server 分析和編譯時間: CPU 時間 = 毫秒 佔用時間 = 毫秒

( 行受影響) 表 TBL_Cot_RecStaticList 掃描計數 邏輯讀取 次 物理讀取 次 預讀 次 lob 邏輯讀取 次 lob 物理讀取 次 lob 預讀 次

SQL Server 執行時間: CPU 時間 = 毫秒 佔用時間 = 毫秒 SQL Server 分析和編譯時間: CPU 時間 = 毫秒 佔用時間 = 毫秒

SQL Server 執行時間: CPU 時間 = 毫秒 佔用時間 = 毫秒

『伍』 優化SQL 查詢：如何寫出高性能SQL語句

1、深入理解資料庫的工作原理和數據存儲的方式，不同的資料庫的工作原理是不同的，mysql oracle db2等等都是不同的，更不要說一些nosql資料庫和newsql資料庫了。
2、理解sql語句檢索數據的方式。
3、理解索引，知道怎樣的欄位建立怎樣的索引，索引能做什麼，不能做什麼，合理的建立欄位。
4、合理的拆分和合並表，數據放在一張表裡面查詢肯定比放在多張表裡面級聯查詢要快。
5、會查看執行任務，任何資料庫都有查看執行任務的方法，包括nosql資料庫和newsql資料庫已經一些大數據資料庫；同時還要會分析執行任務，分析主要是所以的使用效率和欄位數據的檢索方式。
6、sql語句只是性能優化的簡單方面，性能優化是從整體應用架構開始體現的，優化sql並不能夠解決根本問題，當數據量達到一定級別以後，數據就不能使用關系型資料庫，而要使用大數據資料庫，這樣sql就無用了。
7、不要刻意專注sql本身，sql只是一種查詢語言，它本身與性能無關，性能優化的本質在於對存儲方式和查詢檢索過程的深入理解。
8、任何系統功能業務的准確性至上，首先保證功能的正確性再考慮性能優化，如果功能就是數據量大，業務復雜，必須要用到低性能sql的檢索方式，那麼你只能妥協，否則就要棄用sql和關系型資料庫另尋它路。

『陸』 sql語句性能如何優化

如何加快查詢速度?
1、升級硬體
2、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。
3、擴大伺服器的內存
4、增加伺服器CPU個數
5、對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能
6、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
7、查詢時不要返回不需要的行、列
8、用select top 100 / 10 Percent 來限制用戶返回的行數或者SET ROWCOUNT來限制操作的行
9、在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，減少判斷的次數
10、一般在GROUP BY 個HAVING字句之前就能剔除多餘的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：
select的Where字句選擇所有合適的行，Group By用來分組個統計行，Having字句用來剔除多餘的分組。這樣Group By 個Having的開銷小，查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group BY的目的不包括計算，只是分組，那麼用Distinct更快
11、一次更新多條記錄比分多次更新每次一條快,就是說批處理好

『柒』 SQL查詢語句性能優化建議

1對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：

select id from t where num is null

可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：

select id from t where num=0

3.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。

4.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：

select id from t where num=10 or num=20

可以這樣查詢：

select id from t where num=10

union all

select id from t where num=20

5.in 和 not in 也要慎用，否則會導致全表掃描，如：

select id from t where num in(1,2,3)

對於連續的數值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

6.下面的查詢也將導致全表掃描：

select id from t where name like '«c%'

若要提高效率，可以考慮全文檢索。

7.如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時;它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：

select id可以改為強制查詢使用索引：

select id from t with(index(索引名)) where num=@num

8.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：

select id from t where num/2=100

應改為:

select id from t where num=100*2

9.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：

select id from t where substring(name,1,3)='abc'--name以abc開頭的id

select id from t where datediff(day,createdate,'2005-11-30')=0--『2005-11-30』生成的id

應改為:

select id from t where name like 'abc%'

select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'

10.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。

11.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致
12.不要寫一些沒有意義的查詢，如需要生成一個空表結構：

select col1,col2 into #t from t where 1=0

這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：

create table #t(...)

13.很多時候用 exists 代替 in 是一個好的選擇：

select num from a where num in(selectnum from b)

用下面的語句替換：

select num from a where exists(select 1 from b where num=a.num)

14.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。

15.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。

16.應盡可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那麼需要考慮是否應將該索引建為 clustered 索引。

17.盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。

18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。

19.任何地方都不要使用 select * from t ，用具體的欄位列表代替「*」，不要返回用不到的任何欄位。

20.盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限(只有主鍵索引)。

21.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。

22.臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。

23.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度;如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。

24.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。

25.盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那麼就應該考慮改寫。

26.使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。

27.與臨時表一樣，游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括「合計」的常式通常要比使用游標執行的速度快。如果開發時間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。

28.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。

29.盡量避免大事務操作，提高系統並發能力。

30.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。

『捌』 如何測試sql語句性能，提高執行效率

有時候我們經常為我們的sql語句執行效率低下發愁，反復優化後，可還是得不到提高

那麼你就用這條語句找出你sql到底是在哪裡慢了

示例：
SET STATISTICS io ON
SET STATISTICS time
ON
go
---你要測試的sql語句
select top 100 * from
TBL_Cot_RecStaticList
go
SET STATISTICS profile
OFF
SET STATISTICS io OFF
SET STATISTICS time OFF
顯示信息：

SQL Server 分析和編譯時間:

CPU 時間 = 0 毫秒，佔用時間 = 59 毫秒。

(100 行受影響) 表 'TBL_Cot_RecStaticList'。掃描計數 1，邏輯讀取 14 次，物理讀取 2
次，預讀 992 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。

SQL Server 執行時間: CPU 時間 = 0 毫秒，佔用時間 = 306 毫秒。

SQL Server 分析和編譯時間: CPU 時間 = 0 毫秒，佔用時間 = 1 毫秒。

SQL Server 執行時間: CPU 時間 = 0 毫秒，佔用時間 = 1 毫秒。

SQL Server 執行時間: CPU 時間 = 0 毫秒，佔用時間 = 1 毫秒。