mysql設計與優化

普通MySQL運行，數據量和訪問量不大的話，是足夠快的，可是當數據量和訪問量劇增的時候，那麼就會明顯發現MySQL很慢，甚至down掉，那麼就要考慮優化咱們的MySQL了。

優化無非是從三個角度入手：
第一個是從硬件，增長硬件，增長服務器
第二個就是對咱們的MySQL服務器進行優化，增長緩存大小，開多端口，讀寫分開
第三個就是咱們的應用優化，創建索引，優化SQL查詢語句，創建緩存等等

我就簡單的說說SQL查詢語句的優化。由於若是咱們 Web服務器比數據庫服務器多或者性能優良的話，咱們徹底能夠把數據庫的壓力轉嫁到Web服務器上，由於若是單臺MySQL，或者 Master/Slave 架構的數據庫服務器都負擔比較重，那麼就能夠考慮把MySQL的運算放到Web服務器上去進行。固然了，若是你Web服務器比數據庫服務器差，那就把壓力 放在數據庫服務器上吧，呵呵。

若是是把MySQL服務器的壓力放在Web服務器 上，那麼不少運算就須要咱們的程序去執行，好比Web程序中所有交給PHP腳本去處理數據。單臺MySQL服務器，查詢、更新、插入、刪除都在一臺服務器 上的話，訪問量一大，你會明顯發現鎖表現象，當對一個表進行更新刪除操做的時候，就會拒絕其餘操做，這樣就會致使鎖表，解決這個問題最簡單直接的辦法就是 拿兩臺MySQL服務器，一臺負責查詢（select）操做，另一臺負責更改（update/delete/insert），而後進行同步，這樣可以避 免鎖表，若是服務器更多，那麼就更好處理了，能夠採用分佈式數據庫架構和數據的散列存儲，下面咱們會簡單說一下。

1、SQL的優化和注意事項

如今咱們假設咱們只有一臺MySQL服務器，全部的select/update/insert/delete操做都是在這上面進行的，咱們同時有三臺Web服務器，經過DNS輪巡來訪問，那麼咱們如何進行咱們應用程序和SQL的優化。

1. Where條件
在查詢中，WHERE條件也是一個比較重要的因素，儘可能少而且是合理的where條件是很重要的，在寫每個where條件的時候都要仔細考慮，儘可能在多個條件的時候，把會提取儘可能少數據量的條件放在前面，這樣就會減小後一個where條件的查詢時間。
有時候一些where條件會致使索引無效，當使用了Mysql函數的時候，索引將無效，好比：select * from tbl1 where left(name, 4) = 'hylr'，那麼這時候索引無效，還有就是使用LIKE進 行搜索匹配的時候，這樣的語句索引是無效的：select * from tbl1 where name like '%xxx%'，可是這樣索引是有效的：select * from tbl1 where name like 'xxx%'，因此謹慎的寫你的SQL是很重要的。

2. 關聯查詢和子查詢
數據庫一個很重要的特色是關聯查詢，LEFT JOIN 和全關聯，特別是多個表進行關聯，由於每一個關聯表查詢的時候，進行掃描的時候都是一個笛卡爾乘積的數量級，掃描數量很大，若是確實是須要進行關聯操做，請給where或者on的條件進行索引。
關聯操做也是可能交給應用去操做的，看數據量的大小，若是數據量不是很是大，好比10萬條如下，那麼就能夠交給程序去處理（totododo提出筆誤，特此修正），程序分別提取左右兩個表的數據，而後進行循環的掃描處理，返回結果，這個過程一樣很是耗費Web服務器的資源，那麼就須要取決於你願意把壓力放在Web服務器上或者數據庫服務器上了。
子查詢是在mysql5中支持的功能，好比：select * from tbl1 where id in(select id from tbl1)，那樣效率是很是很是低，要儘可能避免使用子查詢，要是我，絕對不用，呵呵。

3.  一些耗費時間和資源的操做
SQL語句中一些浪費的操做，好比 DISTINCT、COUNT、GROUP BY、各類MySQL函數。這些操做都是比較耗資源的，我想應用最多的是count字句吧，若是使用count，儘可能不要count（*），最好count一個字段，好比count（id），或者count(1)，（據totododo測 試效率實際上是同樣的），一樣可以起到統計的做用。若是不是十分必要，儘可能不要使用distinct操做，就是提取惟一值，你徹底能夠把這個操做交給腳本程 序去執行提取惟一值，減小MySQL的負擔。group by 操做也是，確實須要分組的話，請謹慎的操做，若是是小批量的數據，能夠考慮交給腳本程序去作。
至於MySQL的函數，估計不少經常使用，好比有人喜歡把截取字符串也交給MySQL去操做，或者時間轉換操做，使用比較多的函數像 SUBSTR(), CONCAT(), DATE_FORMAT(), TO_DAYS(), MAX(), MIN(), MD5() 等等，這些操做徹底能夠交給腳本程序去作，減輕MySQL的負擔。

4. 合理的創建索引
索引的提高速度的一個很是重要的手段，索引在對一些常常進行select操做，而且值比較惟一的字段是至關有效的，好比主鍵的id字段，惟一的名字name字段等等。
但 是索引對於惟一值比較少的字段，好比性別gender字段，寥寥無幾的類別字段等，意義不大，由於性別是50%的概率，索引幾乎沒有意義。對於 update/delete/insert很是頻繁的表，創建索引要慎重考慮，由於這些頻繁的操做一樣對於索引的維護工做量也是很大的，最後反而得不償 失，這個須要本身仔細考慮。索引一樣不是越多越好，適當的索引會起到很關鍵的做用，不適當的索引，反而減低效率維護，增長維護索引的負擔。

5. 監控sql執行效率
在select語句前面使用EXPLAIN字句可以查看當前這個select字句的執行狀況，包括使用了什麼操做、返回多少概率、對索引的使用狀況如何等等，可以有效分析SQL語句的執行效率和合理程度。
另外使用MySQL中自己的慢查詢日誌：slow-log，一樣可以記錄查詢中花費時間比較多的SQL語句，好對相應的語句進行優化和改寫。
另外在MySQL終端下，使用show processlist命令可以有效的查看當前MySQL在進行的線程，包括線程的狀態，是否鎖表等等，能夠實時的查看SQL執行狀況，同時對一些鎖表操做進行優化。

2、數據庫服務器的架構和分佈想法

對於服務器的架構設計，這個實際上是比較重要的，一個合理的設計，可以讓應用更好的運行。固然，架構的設計，取決於你的應用和你硬件的實際狀況。我就簡單的說說幾種不一樣的數據庫架構設計方式，權當是一個我的的想法，但願可以有幫助。

1. 單臺服務器開多進程和端口
單臺MySQL服務器，若是使用長連接等等都沒法解決負載太大，鏈接太多的問題，不凡考慮採用一臺MySQL上使用多個端口開啓多個MySQL守護進程的方法來緩解壓力。固然，前提是你的應用必須支持多端口，而且你的cpu和內存足夠運行多個守護進程。
優勢 是可以很好的緩解暫時服務器的壓力，把不一樣的操做放在不一樣的端口，或者把不一樣的項目模塊放在不一樣的端口去操做，良好的分擔單個守護進程的壓力。
缺點 是數據可能會產生紊亂，同時可能會致使不少未知的莫名錯誤。呵呵

2. 使用Master/Slave的服務器結構
Mysql 自己具備同步功能，徹底能夠利用這個功能。構建 Master/Slave 的主從服務器結構，最少只須要兩臺MySQL服務器，咱們能夠把 Master 服務器用戶更新操做，包括 update/delete/insert，把Slave服務器用於查詢操做，包括 select 操做，而後兩機進行同步。
優勢 是合理的把更新和查詢的壓力分擔，而且可以避免鎖表的問題。
缺點 是更新部實時，若是網絡繁忙，可能會存在延遲的問題，而且任何一臺服務器down掉了都很麻煩。

3. 使用分佈式的散列存儲
這 種結構適合大數據量，而且負載比較大，而後服務器比較充足的狀況。分佈式存儲結構，簡單的能夠是多臺服務器，每臺服務器功能是相似的，可是存儲的數據不一 樣，好比作一個用戶系統，那麼把用戶ID在1-10萬之內的存儲在A服務器，用戶ID在10-20萬存儲在B服務器，20-3-萬存儲在C服務器，以此類 推。若是每一個用戶訪問的服務器不足，能夠構建組服務器，就是每組用戶擁有多臺服務器，好比能夠在某用戶組創建兩臺MySQL服務器，一臺Master，一 臺Slave，一樣分離他們的更新和查詢操做，或者能夠設計成雙向同步。同時，你的應用程序必須支持跨數據庫和跨服務器的操做能力。
優勢 是服務器的負載合理的被平攤，每臺服務器都是負責一部分用戶，若是一臺服務器down掉了，不會影響其餘用戶ID的用戶正常訪問。同時添加節點比較容易，若是又增長了10萬用戶，那麼又能夠增長一個節點服務器，升級很方便。
缺點 是任何一臺數據庫服務器down掉或者數據丟失，那麼這部分服務器的用戶將很鬱悶，數據都沒了，固然，這個須要良好的備份機制。