如何解決InnoDB表中的開銷和有效問題？

Question

問題：

1 - 架空是什麼意思？當我點擊MyISAM表上的「優化表」按鈕時，開銷和有效數據都消失了。我想知道它對我的桌子有什麼影響？

2 - 我是否需要關心實際的開銷和有效值？如何解決InnoDB表中的開銷和有效問題？

Answer 1

修復InnoDB並不像點擊按鈕那麼簡單。 MyISAM是。

引擎蓋下，OPTIMIZE TABLE將做到這一點的MyISAM表稱爲mytb：

• 創建具有相同結構的空臨時表作爲mytb從mytb
• 複製的MyISAM數據到臨時表
• 降表mytb
• 重命名臨時表到mytb
• 運行ANALYZE TABLE對mytb和存儲索引統計信息

租期，提高TABLE不工作的方式與InnoDB的主要有兩個原因：

理由1：InnoDB存儲佈局

默認情況下，InnoDB的有innodb_file_per_table禁用。 InnoDB和它的祖母都在ibdata1。運行OPTIMIZE TABLE執行以下操作來叫mytb一個InnoDB表：

• 創建具有相同的結構mytb
• 從mytb複製InnoDB的數據到臨時表
• DROP TABLE mytb
• 空InnoDB的臨時表重命名臨時表到mytb
• 運行ANALYZE TABLE對mytb和存儲索引統計信息

不幸的是，用於縮小mytb的臨時表被附加到ibdata1。即興增長ibdata1！鑑於此，ibdata1永遠不會縮小。更糟糕的是，ANALYZE TABLE無用（在REASON＃2中解釋）

如果您啓用了innodb_file_per_table，則前四（4）個步驟將工作，因爲數據未存儲在ibdata1中，而是存儲在名爲mytb.ibd。這可能會縮小。

理由2：指數統計數據始終會重新計算

的InnoDB不能有效地存儲索引統計信息。實際上，如果您在mytb上運行ANALYZE TABLE，則會創建並存儲統計信息。不幸的是，通過設計，InnoDB將潛入其索引的BTREE頁面，其中包括猜測關鍵基數，並使用這些數字來準備MySQL查詢優化器。這是一個正在進行的過程。實際上，ANALYZE TABLE是無用的，因爲計算的索引統計信息會被針對該表執行的每個查詢覆蓋。I wrote about this in the DBA StackExchange June 21, 2011。

Percona explained this thoroughly in www.mysqlperformanceblog.com

至於在MyISAM中的開銷，這個數字可以計算出。

對於MyISAM表，開銷表示內部分段。在經歷，插入，更新和刪除的表中，這是非常常見的，特別是如果您有BLOB數據或VARCHAR列。運行OPTIMIZE TABLE通過複製到臨時表（自然不復制空白空間）使這種碎片消失。

回到InnoDB，你如何有效地消除浪費空間？您需要重新構建ibdata1以減少信息。 Withing ibdata1中你有四種類型的數據：

• 表數據頁
• 指數數據頁
• 表的元數據
• MVCC數據進行交易

可以permamnently移動表和索引出ibdata1永遠。 ibdata1中已經包含了哪些數據和索引？

按照我發表於2010年10月29日，InnoDB的清理計劃：Howto: Clean a mysql InnoDB storage engine?

Answer 2

事實上，「OPTIMIZE TABLE」是一個時間上的MyISAM無用的垃圾，因爲如果你必須這樣做，你的數據庫是麪包已經。

它在大型表上花費很長時間，並且阻止對錶的寫入訪問。此外，對MyISAM數據keycache等

因此，在總結

• 小桌子從來不需要「優化表」
• 大表不能用「優化表」（或實際上的MyISAM非常討厭的影響）

在InnoDB中使用不會更改模式的ALTER TABLE語句（通常是ALTER TABLE t ENGINE = InnoDB）可以實現（大致）相同的事情。它並不像MyISAM那麼快，因爲它不會執行各種小表，它適合在內存中進行優化。

MyISAM還使用了一堆索引優化來壓縮索引頁，這通常會導致非常小的索引。 InnoDB也沒有這些。

如果您的數據庫很小，則不需要它。如果它很大，無論如何你都不能真正使用MyISAM（因爲計劃外的關閉會導致表需要重建，這在大型表上需要很長的時間）。如果您需要耐久性，可靠性，事務處理，任何級別的併發性或通常關心穩健性，請不要使用MyISAM。