本博文旨在結合自己看書理解，並藉此圖進行說明，如有謬誤，望大家指正，以共同探討爲目的，交流學習。
首先介紹一下架構圖的由來:最近看關於mysql方面書籍的一點心得，把文字轉化成圖片而得，方便理解。
我主要從讀、寫、底層磁盤三方面進行闡述：
1、讀操作：
我們知道數據在讀取的時候，需要從磁盤讀到內存中，然後再做相應的操作，而在優化讀操作的時候，主要想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; 當然這是程序控制，創建使用完後再刪除，由程序控制了。
以上是讀操作的一些介紹，接下來是寫操作方面的。
2、寫操作：
寫操作分爲熱門數據和普通數據，簡而言之就是按照頻繁程度進行劃分的。然頻繁修改的數據可以和非頻繁的數據進行分開。
舉個例子:
- 比如我網站每天PV 1000w,而在PV統計的表中，我每次訪問就會插入一條數據，一天下來1000w，當然這還不可能是分攤在24小時，就按照10個小時的中高峯期來說，每個小時也是100w條數據，如果我的網站其他表中的跟新的數據每天2w條，相對1000w來說，就是太少了，但是這2w條數據有事比較重要的數據，如果是用戶註冊、客戶購買商品下的訂單，他可比記錄PV信息更重要吧，這時候問題就出現了：我的熱門數據究竟是什麼？是PV統計還是訂單、註冊用戶，不言而喻，當然其中一個還是重點數據了，所以爲了不讓記錄PV的數據來影響更重要的數據的更新，我們可以把他分開，如果後面還有主從同步的話，分開後，同步的負載也會降低很多，這樣就可以只同步2w條數據，而不用考慮那1000w條數據了，進而主數據庫的負載也會降低。
現在是把熱門數據和普通數據分開了，但是對於高併發的數據庫服務器來說，如何抗併發，這到成了一個重要的問題，當然高配服務器，集羣用上，包括Nosql也用上可一解決這樣的問題，如果在設計的時候能使用隊列機制，這樣不就更好了嘛！（地鐵上看到一句廣告語：有序方能通暢！）
當然你可能有更好的方法，可以共同交流。
3、底層磁盤規劃：
- 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，在性能上發揮巨大的優勢。
以上均個人見解，如有疑問，可共同交流學習！