多年來我一直在閱讀，當您有大量讀取操作而不是大量插入/更新/洗掉時，MyISAM 是 MySQL/MariaDB 的首選資料庫引擎。對于 SELECT 端很重的表，我堅持使用 MyISAM。
我最近有大約 20 個表中有 5 個損壞了，我無法使用各種修復方法使它們恢復生機。事實證明，每個損壞/死亡的表都是 MyISAM。不記得是否每個 MyISAM 表都已損壞。但是，據我所知，沒有一個 InnoDB 表被損壞。
由于過去幾天我一直在吃 / 呼吸和睡覺 MariaDB，通過恢復和改進我們的資料庫基礎設施（副本、備份等），我注意到 InnoDB 現在是 MariaDB 的默認和首選引擎（并不總是案子）。
我還讀到 InnoDB 表不太可能像我最近那樣死于可怕的死亡。當 InnoDB 表死亡時，它們更容易恢復。
話雖如此，我正在認真考慮將所有剩余的 MyISAM 表轉換為 InnoDB。
我的問題是：
- 我是否應該期望在依賴這些表（網站、移動應用后端等）的實時系統上發生任何事情，還是更有可能在轉換后一切都繼續運行？
- 就性能而言，在 SELECT 方面很重的系統上，它可能會變得更好還是更差？即使性能受到很小的影響，為了表的未來穩定性進行轉換仍然是值得的，我只想知道我在做什么，所以如果需要我可以增加 RAM 和 CPU 資源。
- 轉換這些表是否會以任何方式破壞或更改復制？
- 最后一個問題......這些天我真的有什么好的理由將我的任何表保留在 MyISAM 中嗎？聽起來好像沒有。
提前感謝您對這些專案的任何幫助。
uj5u.com熱心網友回復：
是的，它始終是穩定性和性能之間的權衡。但是，如果您使用 MariaDB，為什么不使用 Aria，它可以為您提供兩全其美的體驗？
我是否應該期望在依賴這些表的實時系統上發生任何事情
是的 - 您應該始終計劃從腐敗、勒索軟體、流星襲擊中恢復。InnoDB 可能比 MyISAM 更具彈性，但它并不能解決所有問題。
在 SELECT 方面很重的系統上，它可能會變得更好還是更糟？
erm....它不會更快。性能是否會明顯下降是一個非常復雜的問題，取決于很多很多因素。如果您正在進行匯出/匯入遷移，那么回傳應該是微不足道的。
轉換這些表是否會以任何方式破壞或更改復制？
僅當您嘗試在同時運行復制的同時進行轉換。
請在遷移之前設定 innodb_file_per_table。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/478057.html