phper使用MySQL 針對千萬級的大表要怎麼優化？

 有須要學習交流的友人請加入交流羣的我們一塊兒，有問題一塊兒交流，一塊兒進步！前提是你是學技術的。感謝閱讀！

點此加入該羣​jq.qq.com

首先採用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的目的。