數據千萬級別之多，佔用的存儲空間也比較大，可想而知它不會存儲在一塊連續的物理空間上，而是鏈式存儲在多個碎片的物理空間上。可能對於長字符串的比較，就用更多的時間查找與比較，這就導致用更多的時間。
可以做表拆分，減少單表字段數量，優化表結構。
在保證主鍵有效的情況下，檢查主鍵索引的字段順序，使得查詢語句中條件的字段順序和主鍵索引的字段順序保持一致。
主要兩種拆分 垂直拆分，水平拆分。
垂直分表
根據數據庫裏面數據表的相關性進行拆分。 例如，用戶表中既有用戶的登錄信息又有用戶的基本信息，可以將用戶表拆分成兩個單獨的表，甚至放到單獨的庫做分庫。簡單來說垂直拆分是指數據表列的拆分，把一張列比較多的表拆分爲多張表。
垂直拆分的優點： 可以使得行數據變小，在查詢時減少讀取的Block數，減少I/O次數。此外，垂直分區可以簡化表的結構，易於維護。
垂直拆分的缺點： 主鍵會出現冗餘，需要管理冗餘列，並會引起Join操作，可以通過在應用層進行Join來解決。此外，垂直分區會讓事務變得更加複雜；
水平分表
水平拆分是指數據錶行的拆分，表的行數超過200萬行時，就會變慢，這時可以把一張的表的數據拆成多張表來存放。舉個例子：我們可以將用戶信息表拆分成多個用戶信息表，這樣就可以避免單一表數據量過大對性能造成影響
水平分庫分表
水平拆分可以支持非常大的數據量。需要注意的一點是:分表僅僅是解決了單一表數據過大的問題，但由於表的數據還是在同一臺機器上，其實對於提升MySQL併發能力沒有什麼意義，所以水平拆分最好分庫 。
水平拆分能夠 支持非常大的數據量存儲，應用端改造也少，但 分片事務難以解決 ，跨界點Join性能較差，邏輯複雜。《Java工程師修煉之道》的作者推薦 儘量不要對數據進行分片，因爲拆分會帶來邏輯、部署、運維的各種複雜度 ，一般的數據表在優化得當的情況下支撐千萬以下的數據量是沒有太大問題的。如果實在要分片，儘量選擇客戶端分片架構，這樣可以減少一次和中間件的網絡I/O。
水平分庫分表切分規則
RANGE劃分：RANGE從0到10000一個表，10001到20000一個表；
HASH取模：一個商場系統，一般都是將用戶，訂單作爲主表，然後將和它們相關的作爲附表，這樣不會造成跨庫事務之類的問題。 取用戶id，然後hash取模，分配到不同的數據庫上。
地理區域：比如按照華東，華南，華北這樣來區分業務，七牛雲應該就是如此。
時間：按照時間切分，就是將6個月前，甚至一年前的數據切出去放到另外的一張表，因爲隨着時間流逝，這些表的數據 被查詢的概率變小，所以沒必要和“熱數據”放在一起，這個也是“冷熱數據分離”。
分庫分表後面臨的問題
1.事務支持
分庫分表後，就成了分佈式事務了。如果依賴數據庫本身的分佈式事務管理功能去執行事務，將付出高昂的性能代價； 如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
2.跨庫join
只要是進行切分，跨節點Join的問題是不可避免的。但是良好的設計和切分卻可以減少此類情況的發生。解決這一問題的普遍做法是分兩次查詢實現。在第一次查詢的結果集中找出關聯數據的id,根據這些id發起第二次請求得到關聯數據。
3.跨節點的count,order by,group by以及聚合函數問題
這些是一類問題，因爲它們都需要基於全部數據集合進行計算。多數的代理都不會自動處理合並工作。解決方案：與解決跨節點join問題的類似，分別在各個節點上得到結果後在應用程序端進行合併。和join不同的是每個結點的查詢可以並行執行，因此很多時候它的速度要比單一大表快很多。但如果結果集很大，對應用程序內存的消耗是一個問題。
4.數據遷移，容量規劃，擴容等問題
來自淘寶綜合業務平臺團隊，它利用對2的倍數取餘具有向前兼容的特性（如對4取餘得1的數對2取餘也是1）來分配數據，避免了行級別的數據遷移，但是依然需要進行表級別的遷移，同時對擴容規模和分表數量都有限制。總得來說，這些方案都不是十分的理想，多多少少都存在一些缺點，這也從一個側面反映出了Sharding擴容的難度。
5.ID問題
一旦數據庫被切分到多個物理結點上，我們將不能再依賴數據庫自身的主鍵生成機制。一方面，某個分區數據庫自生成的ID無法保證在全局上是唯一的；另一方面，應用程序在插入數據之前需要先獲得ID,以便進行SQL路由.
下面補充一下數據庫分片的兩種常見方案：
客戶端代理： 分片邏輯在應用端，封裝在jar包中，通過修改或者封裝JDBC層來實現。 噹噹網的Sharding-JDBC 、阿里的TDDL是兩種比較常用的實現。
中間件代理： 在應用和數據中間加了一個代理層。分片邏輯統一維護在中間件服務中。 我們現在談的 Mycat 、360的Atlas、網易的DDB等等都是這種架構的實現。