sql優化經驗總結

今天將mysql優化的一些經驗和總結整理一下，方便日後做專案優化sql語句做參考。裡面有我自己的經驗也有從網上直接複製貼上的。

1索引問題

在做效能跟蹤分析過程中，經常發現有不少後台程式的效能問題是因為缺少合適索引造成的，有些表甚至乙個索引都沒有。這種情況往往都是因為在設計表時，沒去定義索引，而開發初期，由於表記錄很少，索引建立與否，可能對效能沒啥影響，開發人員因此也未多加重視。然一旦程式發布到生產環境，隨著時間的推移，表記錄越來越多

這時缺少索引，對效能的影響便會越來越大了。

這個問題需要資料庫設計人員和開發人員共同關注

法則：不要在建立的索引的資料列上進行下列操作:

◆避免對索引字段進行計算操作

◆避免在索引欄位上使用not，<>，!=

◆避免在索引列上使用is null和is not null

◆避免在索引列上出現資料型別轉換

◆避免在索引欄位上使用函式

◆避免建立索引的列中使用空值。

2在可以使用union all的語句裡，使用了union

union 因為會將各查詢子集的記錄做比較，故比起union all ，通常速度都會慢上許多。一般來說，如果使用union all能滿足要求的話，務必使用union all。還有一種情況大家可能會忽略掉，就是雖然要求幾個子集的並集需要過濾掉重覆記錄，但由於指令碼的特殊性，不可能存在重覆記錄，這時便應該使用union all，如xx模組的某個查詢程式就曾經存在這種情況，見，由於語句的特殊性，在這個指令碼中幾個子集的記錄絕對不可能重複，故可以改用union all）

3 select語句應該盡量避免使用select * 的形式，盡量只選取自己需要的字段，limit也是不可缺少，只返回自己需要的行。

4 應盡量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃瞄，如：

最好不要給資料庫留null，盡可能的使用 not null填充資料庫.

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

6 應盡量避免在 where 子句中使用 or 來連線條件，如果乙個欄位有索引，乙個字段沒有索引，將導致引擎放棄使用索引而進行全表掃瞄，如：

select id from t where num=
10or name =
'admin
'

可以這樣查詢：

select id from t where num = 
10
union
allselect id from t where name =
'admin
'

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

8 對於多張大資料量（這裡幾百條就算大了）的表join，要先分頁再join，否則邏輯讀會很高，效能很差。

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

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

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

sql優化經驗總結

sql經驗總結

Mysql優化常用經驗總結

總結慢 SQL 問題經驗總結

sql優化經驗總結

sql經驗總結

Mysql優化常用經驗總結

總結 慢 SQL 問題經驗總結

相關推薦

總結慢 SQL 問題經驗總結