Information_Schema.Tables 在 MySQL 5.5 和 MySQL 5.7 中報告不同的結果
information_schema.tables我已經開始測試一些 MySQL 5.7 數據庫來替換我們老化的 5.5 數據庫，並且表格記錄數據大小的方式似乎發生了重大變化。我執行以下查詢：
SELECT table_schema AS table_schema, table_name AS table_name, (data_length + index_length + data_free) AS table_size, ROUND((data_length + index_length + data_free)/POWER(1024,3),2) AS table_sizeGB, t.data_length, t.index_length, t.data_free FROM information_schema.TABLES t WHERE table_schema = 'myDb' ORDER BY table_size DESC, table_name LIMIT 10;這給了我 10 個最大的表。我每天執行它來記錄隨時間的增長。在 MySQL 5.5 上需要大約 5 秒，在 MySQL 5.7 上是即時的。
在 MySQL 5.5 上，我得到最大表的以下結果：
myDb | myTable | 319383535616 | 297.45 | 319116279808 | 262012928 | 5242880在 MySQL 5.7 上，我得到：
myDB | myTable | 270051115008 | 251.50 | 269824819200 | 226295808 | 0兩個數據庫都是相隔幾天創建的。5.7 數據庫是 5.5 數據庫的從屬。兩者都不是活動的（只是作為活動系統的奴隸）。
如果我在伺服器上查看，表 .ibd 文件在 5.5 數據庫上為 302GB，在 5.7 數據庫上為 292GB。
我預計會有一個小的差異（一個是使用 Antelope，一個是梭子魚文件格式 - 兩者都是 innodb）。數據不斷地添加到數據庫中，並且很少（如果有的話）被刪除。
在 MySQL 5.5 數據庫上，我可以看到每次執行查詢時數字都會增加，即使相隔幾秒鐘。但是在 MySQL 5.7 上，自從我一周前開始查看它以來，這些數字並沒有改變。
這是正確的行為嗎？在我錯過的 MySQL 5.7 中是否有更好的方法來監控它？
–更新於 2018-10-16
三週後，查詢結果在 MySQL 5.7 上仍然幾乎相同：
5.5 -- myDb | myTable | 327890632704 | 305.37 | 327616036864 | 268304384 |6291456 5.7 -- myDb | myTable | 270055309312 | 251.51 | 269824819200 | 226295808 | 4194304伺服器上的物理大小在 MySQL 5.5 上為 310GB，在 MySQL 5.7 上為 300GB。
兩個表的創建方式相同。
兩個數據庫都沒有處於活動狀態，因此唯一執行的查詢（除了我的測試）來自複制。
兩個數據庫都使用
innodb_file_per_table.MySQL 5.5 是使用 mysqldump 從活動從屬設備複製的。
使用 mysqldump + mysql_upgrade 從 MySQL 5.5 數據庫複製 5.7 數據庫。
從未在這些表上執行優化表。
簡短的回答：數字很接近；不用擔心。
長答案：
有很多解釋。
- 好吧，我猜梭子魚比羚羊小 15%。（這可能是造成差異的主要原因。不過，許多其他事情也會導致差異。）
- 他們是不同的
ROW_FORMAT。SELECTs可能會導致鎖定導致插入/更新/刪除的額外碎片。- 是
innodb_file_per_table一樣的嗎？- Slave 數據是如何從 Master 上複製出來的？
- 你有沒有
OPTIMIZE TABLE在任何一台機器上做過。（幾乎沒有理由每個人都這樣做。）- 5.7 與 5.5 相比有很多程式碼更改，但我想不出任何其他可能直接出現在這些數字中的問題。
- 不太可能存在任何數據差異。Percona 有一個工具可以檢查。
- 有沒有“更好的監控方式”？——監視什麼？
還，
- 當 InnoDB 塊由於更新/刪除而縮小時，會嘗試將該塊與相鄰塊合併。可能是 5.7 比 5.5 做得更好，因此隨著時間的推移導致表的增長變慢。（這在索引 BTree 中似乎更成問題。）
- “Data_free”僅包含一小部分可重用空間。它不應該被信任太多。