建站
咨詢
售后
建站咨詢
新聞中心
本篇內容主要講解“怎么優(yōu)化MySQL中的千萬級數據”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“怎么優(yōu)化MySQL中的千萬級數據”吧!
首先采用Mysql存儲千億級的數據，確實是一項非常大的挑戰(zhàn)。Mysql單表確實可以存儲10億級的數據，只是這個時候性能非常差，項目中大量的實驗證明，Mysql單表容量在500萬左右，性能處于很好狀態(tài)。
針對大表的優(yōu)化，主要是通過數據庫分庫分表來解決，目前比較普遍的方案有三個：分區(qū)，分庫分表，NoSql/NewSql。實際項目中，這三種方案是結合的，目前絕大部分系統(tǒng)的核心數據都是以RDBMS存儲為主，NoSql/NewSql存儲為輔。
分區(qū)
首先來了解一下分區(qū)方案。
分區(qū)表是由多個相關的底層表實現的。這些底層表也是由句柄對象表示，所以我們也可以直接訪問各個分區(qū)，存儲引擎管理分區(qū)的各個底層表和管理普通表一樣（所有的底層表都必須使用相同的存儲引擎），分區(qū)表的索引只是在各個底層表上各自加上一個相同的索引。這個方案對用戶屏蔽了sharding的細節(jié)，即使查詢條件沒有sharding column，它也能正常工作（只是這時候性能一般）。
不過它的缺點很明顯：很多的資源都受到單機的限制，例如連接數，網絡吞吐等。如何進行分區(qū)，在實際應用中是一個非常關鍵的要素之一。
下面開始舉例：以客戶信息為例，客戶數據量5000萬加，項目背景要求保存客戶的銀行卡綁定關系，客戶的證件綁定關系，以及客戶綁定的業(yè)務信息。
此業(yè)務背景下，該如何設計數據庫呢。項目一期的時候，我們建立了一張客戶業(yè)務綁定關系表，里面冗余了每一位客戶綁定的業(yè)務信息。
基本結構大致如下：
查詢時，對銀行卡做索引，業(yè)務編號做索引，證件號做索引。隨著需求大增多，這張表的索引會達到10個以上。而且客戶解約再簽約，里面會保存兩條數據，只是綁定的狀態(tài)不同。
假設我們有5千萬的客戶，5個業(yè)務類型，每位客戶平均2張卡，那么這張表的數據量將會達到驚人的5億，事實上我們系統(tǒng)用戶量還沒有過百萬時就已經不行了。這樣的設計絕對是不行的，無論是插入，還是查詢，都會讓系統(tǒng)崩潰。
mysql數據庫中的數據是以文件的形勢存在磁盤上的，默認放在/mysql/data下面（可以通過my.cnf中的datadir來查看）， 一張表主要對應著三個文件，一個是frm存放表結構的，一個是myd存放表數據的，一個是myi存表索引的。這三個文件都非常的龐大，尤其是.myd文件，快5個G了。下面進行第一次分區(qū)優(yōu)化，Mysql支持的分區(qū)方式有四種：
在我們的項目中，range分區(qū)和list分區(qū)沒有使用場景，如果基于綁定編號做range或者list分區(qū)，綁定編號沒有實際的業(yè)務含義，無法通過它進行查詢，因此，我們就剩下 HASH 分區(qū)和 KEY 分區(qū)了，HASH分區(qū)僅支持int類型列的分區(qū)，且是其中的一列。
KEY 分區(qū)倒是可以支持多列，但也要求其中的一列必須是int類型；看我們的庫表結構，發(fā)現沒有哪一列是int類型的，如何做分區(qū)呢？增加一列，綁定時間列，將此列設置為int類型，然后按照綁定時間進行分區(qū)，將每一天綁定的用戶分到同一個區(qū)里面去。
這次優(yōu)化之后，我們的插入快了許多，但是查詢依然很慢，為什么？
因為在做查詢的時候，我們也只是根據銀行卡或者證件號進行查詢，并沒有根據時間查詢，相當于每次查詢，mysql都會將所有的分區(qū)表查詢一遍。
進行第二次方案優(yōu)化，既然 HASH 分區(qū)和 KEY分區(qū)要求其中的一列必須是int類型的，那么創(chuàng)造出一個int類型的列出來分區(qū)是否可以？
分析發(fā)現，銀行卡的那串數字有秘密。銀行卡一般是16位到19位不等的數字串，我們取其中的某一位拿出來作為表分區(qū)是否可行呢，通過分析發(fā)現，在這串數字中，其中確實有一位是0到9隨機生成的，我們基于銀行卡號+隨機位進行KEY分區(qū)，每次查詢的時候，通過計算截取出這位隨機位數字，再加上卡號，聯合查詢，達到了分區(qū)查詢的目的，需要說明的是，分區(qū)后，建立的索引，也必須是分區(qū)列，否則Mysql還是會在所有的分區(qū)表中查詢數據。
通過銀行卡號查詢綁定關系的問題解決了，那么證件號呢，如何通過證件號來查詢綁定關系。
前面已經講過，做索引一定是要在分區(qū)健上進行，否則會引起全表掃描。我們再創(chuàng)建了一張新表，保存客戶的證件號綁定關系，每位客戶的證件號都是的，新的證件號綁定關系表里，證件號作為了主鍵，那么如何來計算這個分區(qū)健呢，客戶的證件信息比較龐雜，有身份證號，港澳臺通行證，機動車駕駛證等等，如何在無序的證件號里找到分區(qū)健。
為了解決這個問題，我們將證件號綁定關系表一分為二，其中的一張表專用于保存身份證類型的證件號，另一張表則保存其他證件類型的證件號，在身份證類型的證件綁定關系表中，我們將身份證號中的月數拆分出來作為了分區(qū)健，將同一個月出生的客戶證件號保存在同一個區(qū)，這樣分成了12個區(qū)，其他證件類型的證件號，數據量不超過10萬，就沒有必要進行分區(qū)了。
這樣每次查詢時，首先通過證件類型確定要去查詢哪張表，再計算分區(qū)健進行查詢。作了分區(qū)設計之后，保存2000萬用戶數據時銀行卡表的數據保存文件就分成了10個小文件，證件表的數據保存文件分成了12個小文件，解決了這兩個查詢的問題，還剩下一個問題：業(yè)務編號怎么辦？
一個客戶有多個簽約業(yè)務，如何進行保存？這時候，采用分區(qū)的方案就不太合適了，它需要用到分表的方案。
分表
我們前面有提到過對于mysql，其數據文件是以文件形式存儲在磁盤上的。當一個數據文件過大時，操作系統(tǒng)對大文件的操作就會比較麻煩耗時，且有的操作系統(tǒng)就不支持大文件，這個時候就必須分表了。
另外對于mysql常用的存儲引擎是Innodb，它的底層數據結構是B+樹。當其數據文件過大的時候，查詢一個節(jié)點可能會查詢很多層次，而這必定會導致多次IO操作進行裝載進內存，肯定會耗時的。
除此之外還有Innodb對于B+樹的鎖機制。對每個節(jié)點進行加鎖，那么當更改表結構的時候，這時候就會樹進行加鎖，當表文件大的時候，這可以認為是不可實現的。所以綜上我們就必須進行分表與分庫的操作。
如何進行分庫分表，目前互聯網上有許多的版本，比較知名的一些方案：阿里的TDDL，DRDS和cobar，京東金融的sharding-jdbc；民間組織的MyCAT；360的Atlas；美團的zebra；其他比如網易，58，京東等公司都有自研的中間件。
這么多的分庫分表中間件方案歸總起來，就兩類：client模式和proxy模式。
client模式
proxy模式
無論是client模式，還是proxy模式。幾個核心的步驟是一樣的：SQL解析，重寫，路由，執(zhí)行，結果歸并。個人比較傾向于采用client模式，它架構簡單，性能損耗也比較小，運維成本低。
如何對業(yè)務類型進行分庫分表。分庫分表最重要的一步，即sharding column的選取，sharding column選擇的好壞將直接決定整個分庫分表方案最終是否成功。而sharding column的選取跟業(yè)務強相關。
在我們的項目場景中，sharding column無疑好的選擇是業(yè)務編號。通過業(yè)務編號，將客戶不同的綁定簽約業(yè)務保存到不同的表里面去，根據業(yè)務編號路由到相應的表中進行查詢，達到進一步優(yōu)化sql的目的。
到此，相信大家對“怎么優(yōu)化MySQL中的千萬級數據”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯建站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！
網頁標題：怎么優(yōu)化MySQL中的千萬級數據-創(chuàng)新互聯
文章URL：http://fisionsoft.com.cn/article/cesjij.html
