對於一個千萬級的大表，現在可能更多的是億級數據量，很多人第一反應是各種切分，可結果總是事半功倍，或許正是我們優化順序的不正確。下面我們來談談怎樣的優化順序可以讓效果更好。

MySQL數據庫一般都是按照下面的步驟去演化，成本也是由低到高:

1/ SQL優化

1. 避免使用select *

• 返回結果過多，降低查詢的速度；

• 過多的返回結果，增加數據傳輸量；

2. 可確定返回記錄數的，盡量增加limit n；

3. 盡量少用like查詢，會導致索引失效；

2/ 軟件優化

1. 選擇合理的引擎

• MyISAM索引順序訪問方法，支持全文索引，非事務安全，不支持外鍵，會加表級鎖；

• InnoDB事務型存儲引擎，加行鎖，支持回滾，崩潰恢復，ACID事務控制；

2. 正確使用索引

• 結合適的列表建立索引；

• 索引值應該不相同，唯一值時效果最好，大量重復效果很差；

• 不能濫用索引，索引占用空間；

• 使用短索引，存的索引多，消耗IO更小，能提高查找速度；

3. 字段盡量設置成NOT NULL

• NULL占空間，對於Java和OC強類型的，容易千萬APP閃退；

4. MySQL分區表

3/ 硬件優化

1. Linux內核用內存開緩存存儲數據；

2. 增加應用緩存，例如Memcached、Redis讀寫性能非常高；

3. 用SSD代替機械硬盤

• 日誌和數據分開存儲，日誌順序讀寫 - 機械硬盤，數據隨機讀寫 - SSD；

4. SSD+SATA混合存儲，對熱數據緩存，例如：FlashCache；

4/ 架構優化

1. 讀寫分離

• 可以把數據庫讀和寫拆開，對應主從服務器，主服務器寫操作、從服務器是讀操作；

• 讀是一些機器，寫是一些機器，二進制文件的主從復制，延遲解決方案；

• 主服務器寫操作的同時，同步到從服務器，保持數據完整性——主從復制；

2. 垂直拆分

• 根據模塊的耦合度，將一個大的系統分為多個小的系統，也就是分布式系統；

• 字段分成多個表；

3. 水平拆分

• 分表：數據分成多個表，拆分後的每張表的表頭相同；

• 分庫：類型方案有Cobar（阿裏開源，無更新）、MyCat（基於Cobar）；

總結

盡我們所能去優化SQL吧！它成本最低，卻又是一項費時費力的活，需要在技術與業務都熟悉的情況下，用心去優化才能做到最優，優化後效果也是立竿見影的！

千萬級的大表！MySQL這樣優化更好