MySQL大數據優化

咱們考慮的狀況是在你的數據量很大的狀況下，千萬級別的數據量。不要當咱們的請求響應時間已經讓我沒法忍受的時候，再來想起來優化，可能有點遲了。由於可能會丟失不少潛在的價值客戶。因此，在咱們當初設計表，或者由於咱們的業務的變化而致使的狀況下，就要多多考慮去優化咱們的MySQL了。

一、在咱們的開發中，請務必注意咱們的sql書寫，可能你的一個sql致使全站掛掉了。因此要優化好咱們的sql，這其中不得不說，索引。SQL 的優化和索引 密不可分。優化SQL 一部分是業務邏輯的優化，一部分就是索引的優化。至於怎麼優化，網上太多了。也能夠看我其餘文章有介紹。

二、當咱們以爲上面的作的很不錯了，仍是訪問慢，考慮下加緩存把。這裏的緩存能夠是 A文件緩存 B MySQL的buffer C Nginx或者Apace的緩存設置  D客戶端瀏覽器的緩存  E 更重要的是NOSQL類型的緩存，增長memcache 和 redis。確實好，基於內存的讀寫天然比操做硬盤快把

三、咱們的數據量還在增長，咱們就考慮下MySQL的讀寫分離了，進而涉及到主從複製等狀況，不過這裏須要對SQL 語句進行稍微改動下。要不怎麼知道讀哪臺服務器，寫哪臺。

四、接下來，咱們考慮咱們的業務了，隨着併發量不斷增長，老闆這時候開心壞了。這都是錢啊。那就分表把。100萬條記錄的表，分5張 10張都行。不過前提須要按照必定的規則的，比方id爲1的在member1表，2的在member表，一次類推；或者啊id在1-100的在1表，101-200的2表，以此類推。意思就是這樣的。不過須要咱們在sql的時候，寫好讀哪一個表，寫那個表的規則。其實也簡單。

五、區分熱表和冷表。也就是垂直切分表了。顧名思義，熱表表明常常更新的，操做比較頻繁的，冷表，則相反。

 

這其中咱們須要考慮如下問題

 

表引擎的選擇。在幾年前默認就是Mysiam，如今你再看看，默認是innodb類型的。

服務器的配置狀況。