淺談MySQL學習及思考

 本博文旨在結合本身看書理解，並藉此圖進行說明，若有謬誤，望你們指正，以共同探討爲目的，交流學習。

首先介紹一下架構圖的由來:最近看關於mysql方面書籍的一點心得，把文字轉化成圖片而得，方便理解。

 

我主要從讀、寫、底層磁盤三方面進行闡述：

一、讀操做：

  咱們知道數據在讀取的時候，須要從磁盤讀到內存中，而後再作相應的操做，而在優化讀操做的時候，主要想buffer，cache這些進行優化：

key_buffer_size
這個對MyIsam表來講是一個比較重要的參數，通常能夠把他設置成內存的30%-40%，固然這還要根據具體狀況，MyISAM表會使用操做系統的緩存來緩存數據，所以須要留出部份內存給它們，不少狀況下數據比索引大多了。

innodb_buffer_pool_size
這個對InnoDB來講是一個比較重要的參數，而InnoDB對緩衝更爲敏感，MyISAM能夠在默認的 key_buffer_size 設置下運行的能夠，然而Innodb在默認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。因爲Innodb把數據和索引都緩存起來，無需留給操做系統太多的內存，所以若是隻須要用Innodb的話則能夠設置它高達 70-80% 的可用內存。一些應用於 key_buffer 的規則有 — 若是你的數據量不大，而且不會暴增，那麼無需把 innodb_buffer_pool_size 設置的太大了。

table_cache
表的緩存，這個佔用系統的資源和內存，由於每個現成都須要打開一個臨時表，因此當鏈接數大的時候能夠加大此值。

thread-cache
線程的緩存，線程的建立和銷燬開銷可能會很大，因此每一個線程的鏈接和斷開須要，若是程序中活躍的併發鏈接數和Thread-Created的值比較大，能夠稍微設置大一點此值。

query-cache
若是應用程序中有大量的讀，能夠設置大一點此值，可是也不要太大，由於維護它也須要很多的開銷。通常設置32M-512M便可。

sort_buffer_size
這個是connection級的參數，在每一個connection第一次須要使用這個buffer的時候，一次性分配設置的內存，此值不是越大越好，若是設置過大，碰上高併發的狀況下就會使性能下降，sort_buffer_size 超過2KB的時候，就會使用mmap()而不是 malloc() 來進行內存分配，致使效率下降。

mysql臨時表 當工做在很是大的表上時，你可能偶爾須要運行不少查詢得到一個大量數據的小的子集，不是對整個表運行這些查詢，而是讓MySQL每次找出所需的少數記錄，將記錄選擇到一個臨時表可能更快些，而後多這些表運行查詢。 mysql服務器會自動建立內部臨時表：該臨時表能夠是隻存在於內存的memory臨時表，或者是存儲於硬盤的myisam臨時表；並且初始建立的memory臨時表因爲表的增大可能會轉變爲myisam臨時表——其轉化臨界點由max_heap_table_size和tmp_table_size系統變量的較小值決定的！注意：max_heap_table_size系統變量應用於全部的memory引擎的表，不論是用戶臨時表、正常表、或者內部臨時表。固然程序也能夠建立臨時表：create temporary table XX; 固然這是程序控制，建立使用完後再刪除，由程序控制了。

  以上是讀操做的一些介紹，接下來是寫操做方面的。

二、寫操做：

  寫操做分爲熱門數據和普通數據，簡而言之就是按照頻繁程度進行劃分的。然頻繁修改的數據能夠和非頻繁的數據進行分開。

舉個例子:

好比我網站天天PV 1000w,而在PV統計的表中，我每次訪問就會插入一條數據，一天下來1000w，固然這還不多是分攤在24小時，就按照10個小時的中高峯期來講，每一個小時也是100w條數據，若是個人網站其餘表中的跟新的數據天天2w條，相對1000w來講，就是太少了，可是這2w條數據有事比較重要的數據，若是是用戶註冊、客戶購買商品下的訂單，他可比記錄PV信息更重要吧，這時候問題就出現了：個人熱門數據到底是什麼？是PV統計仍是訂單、註冊用戶，不言而喻，固然其中一個仍是重點數據了，因此爲了避免讓記錄PV的數據來影響更重要的數據的更新，咱們能夠把他分開，若是後面還有主從同步的話，分開後，同步的負載也會下降不少，這樣就能夠只同步2w條數據，而不用考慮那1000w條數據了，進而主數據庫的負載也會下降。

  如今是把熱門數據和普通數據分開了，可是對於高併發的數據庫服務器來講，如何抗併發，這到成了一個重要的問題，固然高配服務器，集羣用上，包括Nosql也用上可一解決這樣的問題，若是在設計的時候能使用隊列機制，這樣不就更好了嘛！（地鐵上看到一句廣告語：有序方能通暢！）

  固然你可能有更好的方法，能夠共同交流。

三、底層磁盤規劃：

RAID0:
連續以位或字節爲單位分割數據，並行讀/寫於多個磁盤上，所以具備很高的數據傳輸率，但它沒有數據冗餘，所以並不能算是真正的RAID結構。RAID0只是單純地提升性能，並無爲數據的可靠性提供保證，並且其中的一個磁盤失效將影響到全部數據。所以，RAID 0不能應用於數據安全性要求高的場合。
RAID1：
它是經過磁盤數據鏡像實現數據冗餘，在成對的獨立磁盤上產生互爲備份的數據。當原始數據繁忙時，可直接從鏡像拷貝中讀取數據，所以RAID1：
能夠提升讀取性能。RAID1是磁盤陣列中單位成本最高的，但提供了很高的數據安全性和可用性。當一個磁盤失效時，系統能夠自動切換到鏡像磁盤上讀寫，而不須要重組失效的數據。
RAID0+1：
也被稱爲RAID10標準，實際是將RAID0和RAID1標準結合的產物，在連續地以位或字節爲單位分割數據而且並行讀/寫多個磁盤的同時，爲每一塊磁盤做磁盤鏡像進行冗餘。它的優勢是同時擁有RAID 0的超凡速度和RAID 1的數據高可靠性，可是CPU佔用率一樣也更高，並且磁盤的利用率比較低。
RAID5：
不單獨指定的奇偶盤，而是在全部磁盤上交叉地存取數據及奇偶校驗信息。在RAID5上，讀/寫指針可同時對陣列設備進行操做，提供了更高的數據流量。RAID5更適合於小數據塊和隨機讀寫的數據。RAID3與RAID5相比，最主要的區別在於RAID3每進行一次數據傳輸就需涉及到全部的陣列盤；而對於RAID5來講，大部分數據傳輸只對一塊磁盤操做，並可進行並行操做。在RAID5中有「寫損失」，即每一次寫操做將產生四個實際的讀/寫操做，其中兩次讀舊的數據及奇偶信息，兩次寫新的數據及奇偶信息。
RAID6：
RADI6技術是在RAID5基礎上，爲了進一步增強數據保護而設計的一種RAID方式，其實是一種擴展RAID5等級。與RAID5的不一樣之處於除了每一個硬盤上都有同級數據XOR校驗區外，還有一個針對每一個數據塊的XOR校驗區。固然，當前盤數據塊的校驗數據不可能存在當前盤而是交錯存儲的，具體形式見圖。這樣一來，等於每一個數據塊有了兩個校驗保護屏障（一個分層校驗，一個是整體校驗），所以RAID6的數據冗餘性能至關好。可是，因爲增長了一個校驗，因此寫入的效率較RAID5還差，並且控制系統的設計也更爲複雜，第二塊的校驗區也減小了有效存儲空間。

  而對於熱門數據可使用RAID10，這樣他的性能和安全性會提升不少；而普通數據能夠採用RAID5，主要提供安全性，像臨時表這樣的使用RAID0，在性能上發揮巨大的優點。

以上均我的看法，若有疑問，可共同交流學習！