我們正在運行一個社交網站，記錄每個成員的行爲（包括訪問其他成員的網頁）;這涉及到很多寫入數據庫。這些操作存儲在MyISAM表中，並且由於開始對CPU徵稅，我首先想到的是MyISAM的表鎖定導致了CPU的壓力。將MyISAM轉換爲InnoDB。有利？後果是什麼？
儘管在其他線程（MyISAM versus InnoDB）中討論過使用它的任何優點/缺點，但遷移是一個不平凡的過程。
考慮
您將無疑需要在大型軟件平臺上進行更改;這是可以的，但看到你（希望）有很多自動測試覆蓋，改變應該是可以接受的。 PS：如果「某物開始對CPU徵稅」，那麼你應該a）在非生產環境中找出什麼，b）在非生產環境中嘗試各種減少它的選項。當你沒有完全分析問題時，你不應該盲目地開始做重大事情，比如更改數據庫引擎。
所有的性能測試都應該在非生產環境中進行，具有類似生產的數據和生產級硬件。否則，很難正確解釋結果。
非常感謝這個信息。你能否詳細說明「不同的語義」？ – stef 2010-01-05 14:12:14
我認爲很有可能切換到InnoDB會提高性能，但根據我的經驗，在嘗試之前無法確定。如果我是你，我會在同一臺服務器上建立一個測試環境，轉換成InnoDB並運行基準測試。
至於其他潛在的遷移問題：
1）空間 - InnoDB表往往需要更多的磁盤空間，但對於InnoDB的新版本梭子魚的文件格式已經縮小差別。通過轉換表格的最近備份並比較大小，您可以瞭解這一點。使用「顯示錶狀態」來比較數據長度。
2）全文搜索 - 僅在MyISAM數據
3）GIS /空間數據類型 - 只在MyISAM數據
性能，因爲其他的答案和參考答案表明，它取決於你的工作量。 MyISAM的全表掃描速度要快得多。 InnoDB對於高度併發訪問往往要快得多。如果您的查詢基於主鍵，InnoDB也可以更快。
另一個性能問題是MyISAM總是可以保持行計數，因爲它只進行表級鎖定。因此，如果您經常嘗試獲取非常大的表的行數，那麼InnoDB可能會慢很多。搜索互聯網，如果你需要解決這個問題，我已經看到了幾個提議。
根據表的大小，您可能還需要更新您的MySQL配置文件。至少，您可能希望將字節從key_buffer轉移到innodb_buffer_pool_size。如果您將數據庫保留爲針對MyISAM進行優化，則不會得到公平的比較結果。閱讀所有innodb_ *配置屬性。
根據我的經驗，MyISAM表格僅適用於需要在大文本上進行搜索時具有良好性能的文本索引，但您仍然不需要像Solr或ElasticSearch這樣的完全成熟的搜索引擎。
如果你想切換到InnoDB的，但要保持索引的MyISAM表你的文字，我建議你先在這看看：http://blog.lavoie.sl/2013/05/converting-myisam-to-innodb-keeping-fulltext.html
另外：InnoDB支持使用innobackupex來自Percona的活原子備份。在處理生產服務器時，這是上帝。
http://stackoverflow.com/questions/20148/myisam-versus-innodb – Bozho 2010-01-05 13:01:13
這不是上述的重複，因爲它涉及遷移而不是本身的好處。 – MarkR 2010-01-05 13:33:20
您還可以使用混合表格，使MyISAM保留用於讀取繁重的表格和InnoDB的日誌。不過，我個人今天不會使用MyISAM（真的只有全文searchbait）。 – bobince 2010-01-05 13:56:44