我們大多數的客戶系統都執行mysql。這樣很好。但是大部分客戶的mysql引擎都是使用myisam。這樣很糟糕。幾乎所有的系統資料都應該只使用innodb；這樣會很簡單，當然下面也會討論一些例外。
mysql 有兩種通常的資料儲存引擎：myisam和innodb。 直到5.1版本（包括5.1），myisam還是預設和最常見的引擎，但同時也是現在很久未被更新的過時系統。它在許多情況下執行都比較緩慢，並且有在系統崩潰時破壞資料的壞特性，外加沒有事務處理機制和完整性參照機制（網際網路系統很少使用），以及其他一些高階的功能。
這主要是因為myisam只有表級鎖而沒有像現代化系統一樣的行級鎖。這就意味著當乙個使用者/客戶端在資料庫中進行操作時，整張資料表都會被鎖住（被鎖的資料可能是幾百萬行），而且其他的所有使用者只有等待。你可以想象，這樣不能很好的擴充套件到大型的系統。最近有些例外的sql、insert語句和其他一些東西，但是在實際系統中 myisam的表現還是相當差的。
此外，它沒有事務日誌和分類，因此它只將資料寫入linux檔案快取並希望能最終寫入磁碟。如果系統在這個過程中崩潰或者丟失一些資料，myisam表會經常出現無法啟動或者警告你需要修復表；它恢復資料的方法有限並且經常會丟失資料。另外，myisam也很難正確的備份，備份的時候通常需要鎖住整個系統的資料，這就意味著每天**都要死機或者無法使用15，30，60分鐘或者更多。
相比之下，innodb是乙個更現代化的系統，並正在茁壯地發展，在innodb成員之中有多個版本可供選擇，從最基礎的引擎外掛程式到高階的增強版本，比如 xtradb等。為了有更好的cpu和io效能，更好的備份和鎖表機制，提高統計和除錯效率和更多優勢，每個人都在用innodb。
另外，作為乙個系統，innodb支援多種關鍵功能，其中最重要的是事務日誌和行級鎖。事務日誌記錄真正的資料庫事務，但更重要的是資料崩潰恢復和回滾。基於 inoodb方式的io，能給予更安全資料保護和更好效能表現。另外，在大多數的情況下，行級鎖可以提供更高的併發效能，因為使用者只鎖定他們正在寫的資料，而讀資料永遠不會被阻塞 。最近的效能測試顯示，較myisam，innodb有著好的效能表現，尤其是在高負載的環境下。
通常來說，innodb表更塊，更安全，功能更強大並且正變的越來越好。你應該總是使用它，除非有一些特殊的原因。
哪些特殊的原因可能會使你不用innodb表呢？ 至少有兩種，首先是count(*)行為。在myisam表中，select count(*)在沒有where條件時是很快速的。而innodb必須確切的計算出行數，這樣就會變慢。當然，經常使用count(*)對程式來說不是乙個很好的方法（首先使用乙個索引列會更快，比如：count(id) 並且很少會有乙個好的語句不包括where子句。
再則，myisam表允許在定期列中進行全文檢索，而innodb不支援。通常在像lucene或者solr（或者在新版本mysql中的sphinx）系統中，真正的查詢是在mysql之外被完成的；在這種情況下，你可能需要使用myisam的文字表。
總體而言，簡單的說就是每張表都應該使用innodb，只有很少的例外。
非常好的參考文章(出自tag1)：
為什麼要選擇MySQL資料庫
什麼是mysql？mysql是乙個多使用者 多執行緒的sql資料庫，是乙個客戶機 伺服器結構的應用，它由乙個伺服器守護程式mysqld和很多不同的客戶程式和庫組成。sql structured query language結構化查詢語言 是目前使用最廣的並且是標準的資料庫語言。sql語言使得訪問或更...
為什麼使用資料庫
儘管檔案系統可以解決不少問題，有些問題是檔案系統所無法 解決的，如果給檔案系統加上這些特性，那麼檔案系統也就成 為了乙個資料庫。1.資料的冗餘與資料不一致 重複資料多，而且對於分布式，有可能出現 資料無法同步的問題。2.資料訪問困難，資料孤立 因為資料儲存沒有採取同樣的格式，使得使 用統一的介面訪問...
為什麼Mysql 資料庫盡量避免NULL？
在mysql中很多表都包含可為null 空值 的列，即使應用程式並不需要儲存null也是如此，這是因為可為null是列的預設屬性。但我們常在一些mysql效能優化的書或者一些部落格中看到觀點 在資料列中，盡量不要用null 值，使用0，1或者其他特殊標識替換null值，除非真的需要儲存null值，那...