mysql離散查詢 如何寫出高效能的MySQL查詢

2021-10-18 11:48:38 字數 2782 閱讀 2315

想寫這樣一篇文章很久了,但始終沒有下手。最近幫同事看了幾個查詢,而且自己也在考慮乙個索引系統的問題,所以今天就把這個寫了。介紹一下mysql的索引機制,還有一些mysql查詢的優化策略。鄙人才疏學淺,很可能說的不對,請路過的各位大俠批評指正,獻醜了。

首先,說說mysql的索引儲存方式。mysql的索引一般是b-tree的結構儲存的,記憶體表也有hash索引,但是記憶體表的出鏡率似乎已經低到了用「可憐」來形容的程度,所以我們只考慮b-tree索引。

然後說說mysql的聯合索引。聯合索引對於乙個dbms總是非常重要的,因為每一條sql語句的條件子句是單條件的可能性很小,大多數情況下為組合條件,因此對於組合索引的依賴也就很強。mysql對於聯合索引的建立規則通過乙個例子說明:

對於乙個在列:col_a, col_b和col_c上的聯合索引,mysql會建立

index(col_a), index(col_a, col_b)和index(col_a, col_b, col_c)

這樣三個索引。

介紹完一些基本原理,我們來看mysql對於索引的選取規則和索引的建立原則(這些規則都是個人總結的,多**於網際網路,也有自己的經驗)。

對於單個索引,一般來說mysql的查詢優化器總能在若干查詢條件中選取效率較高的乙個使用,所以不必投入太多精力,一般來說查詢容易出現的問題容易出現在聯合索引。這裡以乙個兩列的索引為例,說明一些問題。

例如:idx_a_b (col_a, col_b)

建立做和索引的列進行or組合不可使用索引

例如:有條件

col_a = val_a or col_b = val_b

這個條件,是不可以使用idx_a_b索引的。然而同樣的查詢對於卻可以使用這樣的索引idx_a(col_a)或者idx_b(col_b)的,因此在建立索引的時候就要考慮到出鏡率最高的條件是什麼,建立怎樣的索引。而如果同時存在idx_a和idx_b兩個索引的話,mysql也只會選擇乙個使用,盡可能使用索引把結果集縮小,再在這個結果集中遍歷,使用其他條件篩選。

聯合索引對非字首列不生效

例如:條件col_b = val_b這個條件是不會使用這個索引的,因為索引idx_a_b的字首列是col_a。因此在建索引的時候,就要注意到,是否有很多使用這種條件的查詢,需要為col_b單獨建立索引。

對於組合索引,遇到範圍查詢則放棄使用剩餘部分

例如:條件

col_a = val_a and col_b = val_b

是可以使用整個索引,而對於

col_a between val_a_left and val_a_right and col_b = val_b

這個條件,只會使用索引的col_a這一部分,不會使用整個索引。對於這樣的查詢,我們有乙個優化策略,若col_a是乙個離散變數,則建議使用in代替between,例如,

col_a between 1 and 5 and col_b = val_b

建議寫成

col_a in (1, 2, 3, 4, 5) and col_b = val_b

這樣是可以使用整個idx_a_b的。

現在能想到的對於組合索引的使用就這些,還遠遠不夠全面,不過了解了這些原理,一般的查詢都是可以分析的。接下來介紹幾個策略性的sql優化。

盡量少的選擇列數

選擇你需要的列,不用圖省事就直接寫個select *,一來是為了減少通訊的開銷,再有就是如果你所選的列,都建立索引,那麼這次查詢就不會對錶資料進行任何操作,只查索引,就返回。

減少count(*), group by, distinct這樣的操作

這三種操作將進行大量的計算,對資料庫伺服器造成很大壓力,而且很慢。這樣的查詢能避免就避免,能快取就快取。

對於limit offset,若offset值較大,則採用分割結果集策略

limit offset操作一般用於翻頁,當offset值較小的時候直接使用limit offset效率搞,但當offset值增大到一定程度,這個查詢效率就會驟然降低。建議在大offset的情況下,採取這個策略:快取上一次結果的尾資料,在新的查詢中不使用offset,直接根據快取結果進行查詢。

例如:select * from tb limit 100 offset 500000;

select * from tb where id>id_val order by id limit 100

這條sql的效率將比上一條高很多倍。

策略性的優化也姑且先想到了這麼幾條,很不全面。綜合上面的這些查詢優化策略,我們還有幾個提高效能的系統配置和管理策略。例如:

定期重建索引

一張錶用的時間久了,資料頻繁更新,索引碎片會很多,降低查詢效率,重建索引可以整理這些碎片,大大提高查詢和寫入的效率。

配置恰當的query_buffer

如果你的機器有足夠大的記憶體,那多分給mysql一點吧,在一台8g記憶體的機器上,我們一般會分給mysql 4到6個g,query的快取會給你帶來驚喜的。

選擇恰當的引擎

常用的mysql引擎有innodb和myisam,前者更穩定且支援行級鎖,後者處理一般查詢效率更高。二者各有特點,一般我們會使用主從策略,主innodb,從myisam的做法。

在恰當的時候分表或分庫

mysql很強大,但對於200到300萬以上的資料進行處理,效能就開始有明顯的下降了,因此一般到這個數量級,就建議拆分資料了。

別讓查詢鏈結阻塞

mysql可以配置連線的超時時間,這個時間如果做得太長,甚至到了10min,那麼很可能發生這種情況,3000個鏈結都被佔滿而且sleep在哪,新鏈結進不來,導致無法正常服務。因此這個配置盡量配置乙個符合邏輯的值,60s或者120s等等。

當下能想到的也就是這些~~略顯膚淺,不過就寫到這裡吧,希望可以拋磚引玉,給大家乙個優化mysql的建議。

如何寫出高效能的MySQL查詢

想寫這樣一篇文章很久了,但始終沒有下手。最近幫同事看了幾個查詢,而且自己也在考慮乙個索引系統的問題,所以今天就把這個寫了。介紹一下mysql的索引機制,還有一些mysql查詢的優化策略。鄙人才疏學淺,很可能說的不對,請路過的各位大俠批評指正,獻醜了。jiajun.org 官方分割線 首先,說說mys...

如何寫出高效能的MySQL查詢

想寫這樣一篇文章很久了,但始終沒有下手。最近幫同事看了幾個查詢,而且自己也在考慮乙個索引系統的問題,所以今天就把這個寫了。介紹一下 mysql的索引機制,還有一些mysql查詢的優化策略。鄙人才疏學淺,很可能說的不對,請路過的各位大俠批評指正,獻醜了。首先,說說 mysql的索引儲存方式。mysql...

如何寫出高可用的介面?

如何寫出高可用 魯棒性強的介面呢?我們設計介面的時候需要考慮以下幾點 1.入參校驗 非空校驗,格式校驗 如手機號格式 業務校驗 如充值金額必須大於0 2.短路式寫法,非正常分支判斷前置 3.非查詢類介面都要考慮 重複請求 併發請求,保證介面的冪等性 可能觸發重複請求或消費的場景 1 網路波動 2 分...