淺談MySQL中優化sql語句查詢經常使用的30種辦法。本站提示廣大學習愛好者：（淺談MySQL中優化sql語句查詢經常使用的30種辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是淺談MySQL中優化sql語句查詢經常使用的30種辦法正文
1.對查詢停止優化，應盡可能防止全表掃描，起首應斟酌在 where 及 order by 觸及的列上樹立索引。
2.應盡可能防止在 where 子句中應用!=或<>操作符，不然將引擎廢棄應用索引而停止全表掃描。
3.應盡可能防止在 where 子句中對字段停止 null 值斷定，不然將招致引擎廢棄應用索引而停止全表掃描，如：
select id from t where num is null
可以在num上設置默許值0，確保表中num列沒有null值，然後如許查詢：
select id from t where num=0
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.上面的查詢也將招致全表掃描：
select id from t where name like '%abc%'
若要進步效力，可以斟酌全文檢索。
6.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
7.假如在 where 子句中應用參數，也會招致全表掃描。由於SQL只要在運轉時才會解析部分變量，但優化法式不克不及將拜訪籌劃的選擇推延到運轉時；它必需在編譯時停止選擇。但是，假如在編譯時樹立拜訪籌劃，變量的值照樣未知的，因此沒法作為索引選擇的輸出項。以下面語句將停止全表掃描：
select id from t where num=@num
可以改成強迫查詢應用索引：
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(select num 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.盡可能防止年夜事務操作，進步體系並發才能。
