當MySQL單表記錄數過大時，增刪改查性能都會急劇下降，可以參考以下步驟來優化：
除非單表數據未來會一直不斷上漲，否則不要一開始就考慮拆分，拆分會帶來邏輯、部署、運維的各種復雜度，一般以整型值為主的表在千萬級以下，字符串為主的表在五百萬以下是沒有太大問題的。而事實上很多時候MySQL單表的性能依然有不少優化空間，甚至能正常支撐千萬級以上的數據量：
TINYINT、SMALLINT、MEDIUM_INT作為整數類型而非INT，如果非負則加上UNSIGNEDVARCHAR的長度只分配真正需要的空間TIMESTAMP而非DATETIME，WHERE和ORDER BY命令上涉及的列建立索引，可根據EXPLAIN來查看是否用了索引還是全表掃描WHERE子句中對字段進行NULL值判斷，否則將導致引擎放棄使用索引而進行全表掃描UNIQUE，由程序保證約束SELECT id WHERE age + 1 = 10，任何對列的操作都將導致表掃描，它包括數據庫教程函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊SELECT *OR改寫成IN：OR的效率是n級別，IN的效率是log(n)級別，in的個數建議控制在200以內%xxx式查詢JOIN'123'和'123'比，123和123比WHERE子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描BETWEEN不用IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5LIMIT來分頁，每頁數量也不要太大目前廣泛使用的是MyISAM和InnoDB兩種引擎：
MyISAM引擎是MySQL 5.1及之前版本的默認引擎，它的特點是：
BLOB和TEXT的前500個字符索引，支持全文索引InnoDB在MySQL 5.5后成為默認索引，它的特點是：
總體來講，MyISAM適合SELECT密集型的表，而InnoDB適合INSERT和UPDATE密集型的表
可以使用下面幾個工具來做基準測試：
具體的調優參數內容較多，具體可參考官方文檔，這里介紹一些比較重要的參數：
show status like 'key_read%'，保證key_reads / key_read_requests在0.1%以下最好show status like 'Innodb_buffer_pool_read%'，保證 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests越高越好(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))進行調整，一般不建議太大，256MB可能已經差不多了，大型的配置型靜態數據可適當調大.show status like 'Qcache_%'查看目前系統Query catch使用大小ORDER BY的速度，首先看是否可以讓MySQL使用索引而不是額外的排序階段。如果不能，可以嘗試增加sort_buffer_size變量的大小Scale up，這個不多說了，根據MySQL是CPU密集型還是I/O密集型，通過提升CPU和內存、使用SSD，都能顯著提升MySQL性能
也是目前常用的優化，從庫讀主庫寫，一般不要采用雙主或多主引入很多復雜性，盡量采用文中的其他方案來提高性能。同時目前很多拆分的解決方案同時也兼顧考慮了讀寫分離
緩存可以發生在這些層次：
Persistence ObjectData Transfer Object可以根據實際情況在一個層次或多個層次結合加入緩存。這里重點介紹下服務層的緩存實現，目前主要有兩種方式：
MySQL在5.1版引入的分區是一種簡單的水平拆分，用戶需要在建表的時候加上分區參數，對應用是透明的無需修改代碼
對用戶來說，分區表是一個獨立的邏輯表，但是底層由多個物理子表組成，實現分區的代碼實際上是通過對一組底層表的對象封裝，但對SQL層來說是一個完全封裝底層的黑盒子。MySQL實現分區的方式也意味著索引也是按照分區的子表定義，沒有全局索引
用戶的SQL語句是需要針對分區表做優化，SQL條件中要帶上分區條件的列，從而使查詢定位到少量的分區上，否則就會掃描全部分區，可以通過EXPLAIN PARTITIONS來查看某條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 | +----+-------------+----------------+------------+-------+---------------+---------+---------+------+------+--------------------------+ 1 row 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_A_M和Users_N_Z再拆成Users和UserExtras，這樣一共四張表
水平拆分的優點是:
