phper優化MySQL千萬級大表的方法詳解

首先採用Mysql儲存千億級的數據，確實是一項非常大的挑戰。 Mysql單表確實可以儲存10億級的數據，只是這個時候效能非常差，專案中大量的實驗證明，Mysql單表容量在500萬左右，效能處於最佳狀態。

針對大表的最佳化，主要是透過資料庫分庫分錶來解決，目前比較普遍的方案有三個：分區，分庫分錶， NoSql/NewSql。實際專案中，這三種方案是結合的，目前絕大部分系統的核心資料都是以RDBMS儲存為主，NoSql/NewSql儲存為輔。

分割區

首先來了解分割區方案。

分區表是由多個相關的底層表實現的。這些底層表也是由句柄物件表示，所以我們也可以直接存取各個分區，儲存引擎管理分區的各個底層表和管理普通表一樣（所有的底層表都必須使用相同的儲存引擎），分區表的索引只是在各個底層表上各自加上一個相同的索引。這個方案對使用者屏蔽了sharding的細節，即使查詢條件沒有sharding column，它也能正常運作（只是這時候效能一般）。

不過它的缺點很明顯：很多的資源都受到單機的限制，例如連線數，網路吞吐等。如何進行分區，在實際應用上是一個非常關鍵的要素之一。

以下開始舉例：以客戶資訊為例，客戶資料量5000萬加，專案背景要求保存客戶的銀行卡綁定關係，客戶的證件綁定關係，以及客戶綁定的業務資訊。

此業務背景下，該如何設計資料庫呢。在專案一期的時候，我們建立了一張客戶業務綁定關係表，裡面冗餘了每位客戶綁定的業務資訊。

基本結構大致如下：

 

# 

查詢時，對銀行卡做索引，業務編號做索引，證件號碼做索引。隨著需求大增多，這張表的索引會達到10個以上。而且客戶解約再簽約，裡面會保存兩條數據，但綁定的狀態不同。

假設我們有5千萬的客戶，5個業務類型，每位客戶平均2張卡，那麼這張表的數據量將會達到驚人的5億，事實上我們系統用戶量還沒有過百萬時就已經不行了。這樣的設計絕對是不行的，無論是插入，還是查詢，都會讓系統崩潰。

 mysql資料庫中的資料是以檔案的形勢存在磁碟上的，預設放在/mysql/data下面（可以透過my.cnf中的datadir來檢視）， 一張表主要對應三個文件，一個是frm存放表結構的，一個是myd存放表資料的，一個是myi存表索引的。這三個文件都非常的龐大，尤其是.myd文件，快5個G了。下面進行第一次分區優化，Mysql支援的分區方式有四種：

在我們的專案中，range分區和list分區沒有使用場景，如果基於綁定號做range或list分區，綁定編號沒有實際的業務意義，無法透過它進行查詢，因此，我們就剩下HASH 分區和KEY 分區了，HASH分區僅支援int類型列的分區，且是其中的一列。

KEY 分割區倒是可以支援多列，但也要求其中的一列必須是int型別；看我們的函式庫表結構，發現沒有哪一列是int型別的，如何做分割區呢？增加一列，綁定時間列，將此列設定為int類型，然後依照綁定時間進行分區，將每一天綁定的使用者分到同一個區裡面去。

這次優化之後，我們的插入快了許多，但是查詢依然很慢，為什麼？

因為在做查詢的時候，我們也只是根據銀行卡或證件號碼來查詢，並沒有根據時間查詢，相當於每次查詢，mysql都會把所有的分區表查詢一遍。

進行第二次方案最佳化，既然 HASH 分區和 KEY分區要求其中的一列必須是int型別的，那麼創造出一個int型別的列出來分區是否可以？

分析發現，銀行卡的那串數字有秘密。銀行卡一般是16位到19位不等的數字串，我們取其中的某一位拿出來作為表分區是否可行呢，透過分析發現，在這串數字中，其中確實有一位是0到9隨機產生的，我們基於銀行卡號隨機位元進行KEY分區，每次查詢的時候，透過計算截取出這位隨機位數字，再加上卡號，聯合查詢，達到了分區查詢的目的，需要說明的是，分區之後，建立的索引，也必須是分區列，否則Mysql還是會在所有的分區表中查詢資料。

透過銀行卡號查詢綁定關係的問題解決了，那麼證件號碼呢，如何透過證件號碼來查詢綁定關係。

前面已經講過，做索引一定是要在分區健上進行，否則會造成全表掃描。我們再創建了一張新表，保存客戶的證件號綁定關係，每位客戶的證件號都是唯一的，新的證件號綁定關係表裡，證件號作為了主鍵，那麼如何來計算這個分區健呢，客戶的證件資料比較龐雜，有身分證號，港澳台通行證，機動車駕駛證等等，如何在無序的證件號裡找到分區健。

為了解決這個問題，我們將證件號綁定關係表一分為二，其中的一張表專用於保存身分證類型的證件號，另一張表則保存其他證件類型的證件號，在身分證類型的證件綁定關係表中，我們將身分證號中的月數拆分出來作為了分區健，將同一個月出生的客戶證件號保存在同一個區，這樣分成了12個區，其他證件類型的證件號，資料量不超過10萬，就沒有必要進行分區了。

這樣每次查詢時，先透過證件類型決定要去查詢哪張表，再計算分區健進行查詢。作了分區設計之後，保存2000萬用戶資料時銀行卡表的資料保存文件就分成了10個小文件，證件表的資料保存文件分成了12個小文件，解決了這兩個查詢的問題，還剩下一個問題：業務編號怎麼辦？

一個客戶有多個簽約業務，如何進行保存？這時候，採用分區的方案就不太適合了，它需要用到分錶的方案。

 分錶

我們前面有提到對於mysql，其資料檔案是以檔案形式儲存在磁碟上的。當一個資料檔案過大時，作業系統對大文件的操作就會比較麻煩耗時，且有的作業系統就不支援大文件，這個時候就必須分錶了。

另外對於mysql常用的儲存引擎是Innodb，它的底層資料結構是B 樹。當其資料檔案過大的時候，查詢一個節點可能會查詢很多層次，而這必定會導致多次IO操作進行裝載進內存，肯定會耗時的。

除此之外還有Innodb對於B 樹的鎖定機制。對每個節點進行加鎖，那麼當更改表結構的時候，這時候就會樹進行加鎖，當表檔案大的時候，這可以認為是不可實現的。所以綜上我們就必須進行分錶與分庫的操作。

如何進行分庫分錶，目前網路上有許多的版本，比較知名的一些方案：阿里的TDDL，DRDS和cobar，京東金融的sharding-jdbc；民間組織的MyCAT；360的Atlas ；美團的zebra；其他如網易，58，京東等公司都有自研的中間件。

這麼多的分庫分錶中間件方案歸總起來，就兩類：client模式和proxy模式。

 

 

#client模式

 

################################ #########proxy模式#########無論是client模式，或是proxy模式。幾個核心的步驟是一樣的：SQL解析，重寫，路由，執行，結果歸併。個人比較傾向於採用client模式，它架構簡單，效能損耗也比較小，維運成本低。 ######如何對業務類型進行分庫分錶。分庫分錶最重要的一步，即sharding column的選取，sharding column選擇的好壞將直接決定整個分庫分錶方案最終是否成功。而sharding column的選取跟業務強相關。 ######在我們的專案場景中，sharding column無疑最好的選擇是業務編號。透過業務編號，將客戶不同的綁定簽約業務保存到不同的表裡面去，根據業務編號路由到相應的表中進行查詢，達到進一步優化sql的目的。 ######更多相關php知識，請造訪###php教學###！ ###

以上是phper優化MySQL千萬級大表的方法詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！