前言

我們都知道初創公司一開始都是以單體應用為首要架構，一般都是單體單庫的形式。但是版本以及版本的迭代，資料庫需要承受更多的高併發已經成了 架構設計 需要考慮的點。

那麼解決問題，就得說到方案。但是方案有很多，我們該怎麼選擇呢？

優化與方案

基本上，我們優化要從幾個關鍵字入手： 短距離 ， 少資料 ， 分散壓力 。

短距離

所謂的短距離，指的是從前端到資料庫的路徑要短。

1. 頁面靜態。有些頁面的資料是在某些時段是不變的，那麼這個頁面可以靜態化，這樣可以提高訪問的速度。
2. 使用快取。快取大家都知道，快的原因就是基於記憶體。所以使用基於記憶體的快取的話，可以減少對資料庫的訪問，同時加速訪問速度。
3. 批量讀取。高併發的情況下，可以將多個請求的查詢合在一次進行，以減少對資料庫的訪問速度。
4. 延遲修改。延遲修改的意思高併發的情況西可能是將多次修改資料放在快取中，然後定時將快取中的資料過更新到資料庫；也可以是通過快取的同步策略通過解析非同步同步到資料庫中。
5. 使用索引。這個不用說了，索引有著比較多的型別，例如普通索引/主鍵索引/組合索引/全文索引等。
   

少資料

所謂的少資料，其實是查詢的資料要少。

1. 分表。所謂的分表，其實有水平切分和垂直拆分。玩過單機的小夥伴都知道，往往一些具有歷史性的表單，都會有成百上千萬級別的資料。這樣子對於 MySQL 來說，即使是加了索引，SQL 方面繼續優化，也很難做到更快的查詢速度。那麼我們可以通過分表的操作來實現。例如說最常見的我們可以根據時間的維度來進行表的水平拆分，今年的資料保持下來，而去年的資料可以存在另外一個表裡。
2. 分離活躍資料。其實這個有點類似快取，但是不同之處在於資料還是在 MySQL 上面的。例如一個查詢商品的業務，有一些火爆/經常被搜尋的商品可以存在一張活躍表。查詢的時候先查詢活躍表，沒有的話再查詢總商品表。
3. 分塊。這個分塊有點類似於演算法裡面的“索引順序查詢”。通過資料層面的優化，將資料放在不同的塊中，而我們只需要計算找到對應的塊就行了。
   

分散壓力

所謂的分散壓力，其實是分散不同資料庫伺服器的壓力

1. 叢集。叢集的概念相信大家都很清楚，對於業務伺服器來說其實就是具備相同業務流程的伺服器部署多臺，通過負載均衡或其他方式來將請求分配到不同伺服器。而資料庫也一樣，通過特定的規則策略將資料導向特定的資料庫伺服器上。
2. 分散式。所謂的分散式，其實就是將原本處於同個流程的業務邏輯分配到不同的伺服器上面執行，達到了“併發”執行的效果，加快執行速度。
3. 分庫分表。分庫分表主要是水平拆分和垂直拆分。對於訪問頻率高而資料量巨大的單表，可以減少單表的資料，根據特定的維度進行水平拆分，增加資料庫的吞吐量，這就是 分表水平拆分 ；而對於業務耦合性低的多表來說，可以將不同的表儲存在不同的資料庫上，對資料庫進行垂直拆分，提高資料庫寫的能力，即 分庫的垂直拆分 。
4. 建立主從。建立主從的目的其實就是為了讀寫分離。我們都知道，只要資料庫的事務級別夠高，那麼併發讀是不會影響到資料的混亂，而併發寫則會。所以建立主從一般來說，寫會留在主伺服器上寫，而會在從伺服器上讀。 所以基本上讓主伺服器進行事務性操作，從伺服器進行 select 查詢。這樣子的話，事務性操作（增加/刪除/修改）導致的改變更新同步到叢集中的從資料庫 。
   

結語

以上就是MySQL 如何處理高併發的詳細內容，更多關於MySQL 高併發的資料請關注我們其它相關文章！