原文：
問題：主從伺服器表型別的選擇
一般的共識是主伺服器使用innodb，事務，行鎖等功能是myisam所沒有的，對修改操作而言，它更高效；從伺服器使用myisam，全文檢索功能是innodb所沒有的，對查詢操作而言，它更高效。這樣就可以各盡其能。
問題：主從伺服器字段型別的選擇
字段型別對於分頁等操作有很大影響。主伺服器一般是innodb，因為不涉及查詢，所以可以使用varchar等來儲存字串來節省空間，從伺服器一般是myisam，因為涉及查詢，所以必須在char和varchar之間仔細權衡，沒有varchar, text, blob欄位的表是靜態表，反之是動態表，靜態表的檢索效率要比動態表好若干倍，一般來說，所有涉及大結果集的查詢都應該盡可能保證在靜態表上完成，這裡說乙個例子：比如說常見的articles表有title(varchar), body(text)等字段，在做文章列表的時候，因為不是靜態表，所以查詢不會很快，下面開始重構解決方案：把原來的articles表拆分成subjects表和contents表，title欄位設定為乙個足夠的char型別放在subjects表裡，body欄位還保持是text型別放到contents表裡，subjects和contents表之間的關係是一對多，這樣，順帶著也方便的實現了多頁文章的功能，而且更重要的是在查詢文章列表的時候，操作都是在subjects靜態表裡完成，效率肯定會比前一種方案提公升很多。
強調：myisam裡靜態表和動態表的區別對效能影響極大，但我敢說很大一部分使用者並沒有注意過這一點！如果你就是其中之一，那麼我強烈建議你再次體會一下前面說的articles分解為subjects/contents的過程，相信你熟悉了以後，下乙個應用的速度會有質的提公升。
問題：主從伺服器讀寫分離時讀操作失敗
先重現一下問題：比如說新增一條新資料，新增成功後根據last_insert_id跳轉到新新增資料的瀏覽頁面。在此過程中新增新資料的操作是在主伺服器上完成的，瀏覽新資料的操作實在從伺服器上完成的，不過由於主從伺服器間sql同步存在延遲，所以當使用last_insert_id在從伺服器上查詢的時候，從伺服器很可能還沒有還沒來得及同步到此記錄，所以讀操作失敗。解決思路也不複雜，在**裡加入乙個快取層（可以使用memcached），新新增的資料都順手放到快取層裡乙份，新資料的讀操作也先查詢快取層，這樣就不會再有讀操作失敗的問題了，當然刪除或者更新資料的時候也要順帶著處理好快取資料，可以使用觀察者模式來搞定。不過這樣快取方案只限於讀取單一的記錄，對於讀取列表的記錄的情況，則是無效的。
新版解決方法：
官方的mysql semisynchronous replication：
問題：主從伺服器索引是否有必要保持一致
此外，還有很多優化方式，比如說，從伺服器可以使用
mysql 5.1新功能 －－ 按日期分割槽
partitioning with dates in mysql 5.1
improving database performance with partitioning
MySQL主從伺服器的一些技巧
問題 主從伺服器表型別的選擇 一般的共識是主伺服器使用innodb，從伺服器使用myisam，以便各盡其能。問題 主從伺服器字段型別的選擇 字段型別對於分頁等操作有很大影響。主伺服器一般是innodb，因為不涉及查詢，所以可以使用varchar等來儲存字串來節省空間，從伺服器一般是 myisam，因...
MySQL主從伺服器的一些技巧
問題 主從伺服器表型別的選擇 一般的共識是主伺服器使用innodb，事務，行鎖等功能是myisam所沒有的，對修改操作而言，它更高效 從伺服器使用myisam，全文檢索功能是innodb所沒有的，對查詢操作而言，它更高效。這樣就可以各盡其能。問題 主從伺服器字段型別的選擇 字段型別對於分頁等操作有很...
MySQL主從伺服器的一些技巧
問題 主從伺服器表型別的選擇 一般的共識是主伺服器使用innodb，事務，行鎖等功能是myisam所沒有的，對修改操作而言，它更高效 從伺服器使用myisam，全文檢索功能是innodb所沒有的，對查詢操作而言，它更高效。這樣就可以各盡其能。問題 主從伺服器字段型別的選擇 字段型別對於分頁等操作有很...