有需要學習交流的友人請加入交流群的咱們一起，群內都是1-7年的開發者，希望可以一起交流，探討PHP,swoole這塊的技術 或者有其他問題 也可以問，獲取swoole或者php進階相關資料私聊管理即可
點此加入該群?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的目的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/94434.html
標籤：MySQL