Mysql 分片。壞到什麼程度？
我為我的公司生產站點執行了一個表狀態，它顯示的數據庫中幾乎每個表都接近“49085939712”，我們有大約 400 個表。
我不是數據庫管理員，我的 mysql 技能在優化方面並不是最好的。對我來說，這看起來很糟糕。但我需要其他人的意見。
我的問題是糟糕到什麼程度太糟糕了。知道何時優化單個表的平均門檻值是多少。
碎片應該對 InnoDB 的性能幾乎沒有影響，它只影響數據文件的大小。因此，如果您的磁碟空間不足，那就是“碎片過多”。
如果您
innodb_file_per_table設置為 OFF，則所有 InnoDB 表都儲存在一個表空間文件中，預設情況下，該文件稱為ibdata1。的值顯示此表空間中所有表
information_schema.tables.data_free的相同值。見http://dev.mysql.com/doc/refman/5.6/en/innodb-file-space.html
當您通過發出 SHOW TABLE STATUS 語句請求表空間中的可用空閒空間時，InnoDB 報告表空間中絕對空閒的範圍。
換句話說，報告的值
data_free不是任何單個表的可用空間量，而是表空間文件中完全可用的擴展區佔用的空間量。一個extent是一個1MB的塊，預設是64頁。您可能會注意到 49085939712 正好是 46812MB。這就是您的表空間文件中有多少未使用的範圍。
但是您可能在其他範圍內也有部分未使用的空間。這不是由
data_free. 獲取這些資訊有點困難，一種方法是使用InnoDB 表空間監視器來報告它。這樣做
OPTIMIZE TABLE不會恢復可用空間，因為您顯然沒有使用innodb_file_per_table. InnoDB 將在進一步擴展表空間文件的大小之前將這些範圍重用於新數據，但是如果您需要立即恢復大約 45GB，不幸的是，您必須以艱難的方式來做：
- 轉儲所有InnoDB 表（或至少暫時將它們轉換為 MyISAM）
- 關閉 mysqld
- rm ibdata1
- 重啟mysqld
- 恢復所有 InnoDB 表。