MySQL主從服務器的一些技巧

qfmaomao11

問題：主從服務器表類型的選擇

一般的共識是主服務器使用innodb，從服務器使用myisam，以便各盡其能。

問題：主從服務器字段類型的選擇

字段類型對于分頁等操作有很大影響。主服務器一般是innodb，因為不涉及查詢，所以可以使用varchar等來存儲字符串來節(jié)省空間，從服務器一般是 myisam，因為涉及查詢，所以必須在char和varchar之間仔細權(quán)衡，沒有varchar, text, blob字段的表是靜態(tài)表，反之是動態(tài)表，靜態(tài)表的檢索效率要比動態(tài)表好若干倍，一般來說，所有涉及大結(jié)果集的查詢都應該盡可能保證在靜態(tài)表上完成，這里說一個例子：比如說常見的articles表有title(varchar), body(text)等字段，在做文章列表的時候，因為不是靜態(tài)表，所以查詢不會很快，下面開始重構(gòu)解決方案：把原來的articles表拆分成 subjects表和contents表，title字段設(shè)置為一個足夠的char類型放在subjects表里，body字段還保持是text類型放到 contents表里，subjects和contents表之間的關(guān)系是一對多，這樣，順帶著也方便的實現(xiàn)了多頁文章的功能，而且更重要的是在查詢文章列表的時候，操作都是在subjects靜態(tài)表里完成，效率肯定會比前一種方案提升很多。

問題：主從服務器NOW()函數(shù)造成數(shù)據(jù)不一致

假設(shè)在主服務器上執(zhí)行一條INSERT …. VALUES ( …, NOW())，那么在從服務器上也會同樣執(zhí)行一條的SQL語句，但是一來主從服務器各自的時間設(shè)置可能就不一致，二來主從服務器間的SQL同步也可能存在時間上的的延遲，這樣，NOW()在兩臺服務器上的結(jié)果就可能不一致。解決方法是顯而易見的，就是不要使用NOW()，時間的計算在應用程序里完成。這里介紹一個額外的小技巧：在PHP里如果想獲得當前時間的時間戳，不要用time()，而應該使用$_SERVER[‘REQUEST_TIME’] （PHP版本大于5.1有效），這樣少做了一次系統(tǒng)調(diào)用，更有效率。

問題：主從服務器讀寫分離時讀操作失敗

先重現(xiàn)一下問題：比如說添加一條新數(shù)據(jù)，添加成功后根據(jù)last_insert_id跳轉(zhuǎn)到新添加數(shù)據(jù)的瀏覽頁面。在此過程中添加新數(shù)據(jù)的操作是在主服務器上完成的，瀏覽新數(shù)據(jù)的操作實在從服務器上完成的，不過由于主從服務器間SQL同步存在延遲，所以當使用last_insert_id在從服務器上查詢的時候，從服務器很可能還沒有還沒來得及同步到此記錄，所以讀操作失敗。解決思路也不復雜，在代碼里加入一個緩存層（可以使用memcached），新添加的數(shù)據(jù)都順手放到緩存層里一份，新數(shù)據(jù)的讀操作也先查詢緩存層，這樣就不會再有讀操作失敗的問題了，當然刪除或者更新數(shù)據(jù)的時候也要順帶著處理好緩存數(shù)據(jù)，可以使用觀察者模式來搞定。不過這樣緩存方案只限于讀取單一的記錄，對于讀取列表的記錄的情況，則是無效的。

問題：主從服務器索引是否有必要保持一致

一般都是利用主從服務器完成讀寫分離，從服務器上進行讀操作，主服務器進行寫操作，這樣的話，主服務器上僅保留主鍵，外鍵，唯一索引等必要的索引即可，以 便保持數(shù)據(jù)合法性，而對于那些原本用于優(yōu)化SELECT操作的索引，可以全部刪除，如此的話主服務器的寫操作效率會提升很多。

轉(zhuǎn)自：http://hi.baidu.com/thinkinginla ... b1885fd0090633.html

pcghost_cu

這些技巧挺不錯的:wink: