當MySQL單表記錄數過大時，增刪改查性能都會急劇下降，可以參考以下步驟來優化：
單表優化
除非單表數據未來會一直不斷上漲，否則不要一開始就考慮拆分，拆分會帶來邏輯、部署、運維的各種復雜度，一般以整型值為主的表在千萬級以下，字符串為主的表在五百萬以下是沒有太大問題的。而事實上很多時候MySQL單表的性能依然有不少優化空間，甚至能正常支撐千萬級以上的數據量：
字段
索引
查詢SQL
引擎
目前廣泛使用的是和兩種引擎：
引擎是MySQL 5.1及之前版本的默認引擎，它的特點是：
系統調優參數
可以使用下面幾個工具來做基準測試：
具體的調優參數內容較多，具體可參考官方文檔，這里介紹一些比較重要的參數：
升級硬件
Scale up，這個不多說了，根據MySQL是CPU密集型還是I/O密集型監控mysql表的數據變化，通過提升CPU和內存、使用SSD，都能顯著提升MySQL性能
讀寫分離
也是目前常用的優化，從庫讀主庫寫，一般不要采用雙主或多主引入很多復雜性，盡量采用文中的其他方案來提高性能。同時目前很多拆分的解決方案同時也兼顧考慮了讀寫分離
緩存
緩存可以發生在這些層次：
可以根據實際情況在一個層次或多個層次結合加入緩存。這里重點介紹下服務層的緩存實現，目前主要有兩種方式：
表分區
MySQL在5.1版引入的分區是一種簡單的水平拆分，用戶需要在建表的時候加上分區參數，對應用是透明的無需修改代碼。
對用戶來說，分區表是一個獨立的邏輯表，但是底層由多個物理子表組成，實現分區的代碼實際上是通過對一組底層表的對象封裝，但對SQL層來說是一個完全封裝底層的黑盒子。MySQL實現分區的方式也意味著索引也是按照分區的子表定義，沒有全局索引。
用戶的SQL語句是需要針對分區表做優化，SQL條件中要帶上分區條件的列，從而使查詢定位到少量的分區上，否則就會掃描全部分區，可以通過 來查看某條SQL語句會落在那些分區上，從而進行SQL優化，如下圖5條記錄落在兩個分區上：
mysql> explain partitions select count(1) from user_partition where id in (1,2,3,4,5);+----+-------------+----------------+------------+-------+---------------+---------+---------+------+------+--------------------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+----------------+------------+-------+---------------+---------+---------+------+------+--------------------------+| 1 | SIMPLE | user_partition | p1,p4 | range | PRIMARY | PRIMARY | 8 | NULL | 5 | Using where; Using index |+----+-------------+----------------+------------+-------+---------------+---------+---------+------+------+--------------------------+1row in set (0.00 sec)分區的好處是：
分區的限制和缺點：
分區的類型：
最適合的場景數據的時間序列性比較強，則可以按時間來分區，如下所示：
CREATE TABLE members ( firstname VARCHAR(25) NOT NULL, lastname VARCHAR(25) NOT NULL, username VARCHAR(16) NOT NULL, email VARCHAR(35), joined DATE NOT NULL)PARTITION BY RANGE( YEAR(joined) ) ( PARTITION p0 VALUES LESS THAN (1960), PARTITION p1 VALUES LESS THAN (1970), PARTITION p2 VALUES LESS THAN (1980), PARTITION p3 VALUES LESS THAN (1990), PARTITION p4 VALUES LESS THAN MAXVALUE);
查詢時加上時間范圍條件效率會非常高，同時對于不需要的歷史數據能很容的批量刪除。
另外MySQL有一種早期的簡單的分區實現 - 合并表（merge table），限制較多且缺乏優化，不建議使用，應該用新的分區機制來替代
垂直拆分
垂直分庫是根據數據庫里面的數據表的相關性進行拆分，比如：一個數據庫里面既存在用戶數據，又存在訂單數據，那么垂直拆分可以把用戶數據放到用戶庫、把訂單數據放到訂單庫。垂直分表是對數據表進行垂直拆分的一種方式，常見的是把一個多字段的大表按常用字段和非常用字段進行拆分，每個表里面的數據記錄數一般情況下是相同的，只是字段不一樣，使用主鍵關聯
比如原始的用戶表是：
垂直拆分的優點是：
缺點是：
水平拆分
概述
水平拆分是通過某種策略將數據分片來存儲，分庫內分表和分庫兩部分，每片數據會分散到不同的MySQL表或庫，達到分布式的效果，能夠支持非常大的數據量。前面的表分區本質上也是一種特殊的庫內分表 庫內分表，僅僅是單純的解決了單一表數據過大的問題，由于沒有把表的數據分布到不同的機器上，因此對于減輕MySQL服務器的壓力來說，并沒有太大的作用，大家還是競爭同一個物理機上的IO、CPU、網絡，這個就要通過分庫來解決
前面垂直拆分的用戶表如果進行水平拆分。
實際情況中往往會是垂直拆分和水平拆分的結合，即將和再拆成Users和，這樣一共四張表
水平拆分的優點是:
缺點是：
分片原則
這里特別強調一下分片規則的選擇問題，如果某個表的數據有明顯的時間特征，比如訂單、交易記錄等，則他們通常比較合適用時間范圍分片，因為具有時效性的數據，我們往往關注其近期的數據，查詢條件中往往帶有時間字段進行過濾，比較好的方案是，當前活躍的數據，采用跨度比較短的時間段進行分片，而歷史性的數據，則采用比較長的跨度存儲。
總體上來說，分片的選擇是取決于最頻繁的查詢SQL的條件，因為不帶任何Where語句的查詢SQL，會遍歷所有的分片，性能相對最差，因此這種SQL越多，對系統的影響越大，所以我們要盡量避免這種SQL的產生。
解決方案
由于水平拆分牽涉的邏輯比較復雜，當前也有了不少比較成熟的解決方案。這些方案分為兩大類：客戶端架構和代理架構。
客戶端架構
通過修改數據訪問層，如JDBC、Data 、，通過配置來管理多個數據源，直連數據庫，并在模塊內完成數據的分片整合，一般以Jar包的方式呈現 這是一個客戶端架構的
客戶端架構的優點是：
缺點是：
代理架構
通過獨立的中間件來統一管理所有數據源和數據分片整合，后端數據庫集群對前端應用程序透明，需要獨立部署和運維代理組件
這是一個代理架構的例子：
代理組件為了分流和防止單點，一般以集群形式存在監控mysql表的數據變化，同時可能需要之類的服務組件來管理
代理架構的優點是：
缺點是：