MySQL 5.1 中，在復制(Replication)方面的改進就是引進了新的複制技術：基於行的複制。 簡言之，這種新技術就是關注表中發生變化的記錄，而非以前的照抄 binlog 模式。 從 MySQL 5.1.12 開始，可以用以下三種模式來實現：基於SQL語句的複制(statement-based replication, SBR)，基於行的複制(row-based replication, RBR)，混合模式複制(mixed-based replication, MBR)。 相應地，binlog的格式也有三種：STATEMENT，ROW，MIXED。MBR 模式中，SBR 模式是默認的。
在運行時可以動態低改變binlog的格式，除了以下幾種情況：
#BEGIN CONFIG INFO
#DESCR: 4GB RAM,只使用InnoDB, ACID,少量的連接,隊列負載大
網路上有很多人提供MySQL的負載方式，例如：Master Slave架構、MySQL MMM架構、DRBD、Cluster、HeartBeat…等一堆MySQL負載平衡的架構，一直MySQL負載平衡的架構，到底要選擇那一個方式才是最好的？
丫忠認為符合自己個人(公司)需求的架構最好，再來是穩定及簡單好維護；如果只是單純的公司形象網站或者是一般個人的Blog，總不能想著要架構Master + Slave，外加MySQL Proxy做讀寫分流，再替Master做個HeartBeat的備援，再後再加幾台memcached來加快搜尋速度….等，如果只是為了測試架構倒是可以玩一玩，如果是要用在運作中的主機的話，那丫忠勸您要3思 再3思了，不要搞到後來出問題時找不到問題，或者資料不一致時，到時候拜再多的神也沒用囉…
MySQL資料庫5.0的my.cnf配置選項概述:
參數的調整可以通過修改 /etc/my.cnf 文件並重啟 MySQL實現。這是一個比較謹慎的工作，上面的結果也僅僅是我的一些看法，你可以根據你自己主機的硬件情況（特別是內存大小）進一步修改。
同時在線訪問量繼續增大 對於1G內存的服務器明顯感覺到吃力嚴重時甚至每天都會死機或者時不時的服務器卡一下 這個問題曾經困擾了我半個多月MySQL使用是很具伸縮性的算法，因此你通常能用很少的內存運行或給MySQL更多的被存以得到更好的性能。
mysql複製和臨時表temporary table 當你創建臨時表的時候，你可以使用temporary關鍵字。 如：
create temporary table tmp_table(name varchar(10) not null,passwd char(6) not null)
在做資料庫的 SELECT 動作時 有時候會一次要用到許多個 TABLE 造成語法過長 閱讀及維護也不方便
通常這時候會建立一個暫存的 TABLE 在將要用到的資料一筆一筆丟進去
