我們的數據庫很有趣，因為我們有大量的表佔用了相應的大量空間，但是當我們對所述數據庫進行 MySQL 轉儲時，它非常小。

具體來說，數據庫大約 50GB，包含大約​​ 50k 個表。轉儲時，它佔用大約 5GB。（這些數字並不准確，但它們足夠接近我們在這裡的討論）。對我來說特別奇怪的是，“二進制”數據庫比 SQL 轉儲數據庫佔用的空間多得多。

絕大多數表（如 49990）是相對較小的 Wordpress 多站點表。這些是很少使用的網站，內容很少。

如果相關，我們正在使用 innodb_file_per_table。

最小化數據庫大小的最佳方法是什麼？最小化數據庫的大小是否會以降低性能為代價？最終，我想減小數據庫的大小以提高性能（例如，關於執行備份/恢復操作）。

---

更新：表格的結構基本上只是預設的 Wordpress 多站點佈局：http ://pastie.org/private/iufzw8z9zlyidqw8b7wggw 請注意，我查看了一些更準確的數字，看起來我們總共有大約 9k 多站點實例近 80k 表。較大的數字部分是由於我們的服務不斷增長並增加了新客戶。

“最小化數據庫大小是否會以降低性能為代價？”

通常，數據庫是 IO 受限的，除非它們定期重新計算報告樣式查詢。（在這種情況下，可以添加預先計算的視圖以再次將 cpu 轉移到 IO。）

最小化數據庫的大小通常會最小化磁碟所需的 IO，因為更高百分比的所有數據可以在記憶體中。

壓縮儲存在這裡也有幫助；如果 1 個磁碟 iop 可以檢索更多行，那麼這也可以提高性能，而無需在邏輯上重新排列數據。（許多壓縮方案的 cpu 效率足夠高，由於必須處理更少的數據頁，因此實際上可以看到 cpu 使用率的下降。）

因此，一般而言，最小化數據庫的大小確實會提高性能，但始終進行基準測試，因為像這樣的任何通用語句都有許多反例（注意，RolandoMySQLDBA 的答案列出了與記憶體壓力有關的壓縮的一些缺點）。

http://dev.mysql.com/doc/refman/5.5/en/innodb-compression-internals.html#innodb-compression-internals-storage列出了由於數據壓縮而導致的一些權衡

方面 #1：BIGINT 的使用

BIGINT 佔用 8 個字節。您應該更改整個架構以使用INT UNSIGNED

為了驗證這一點，讓我們選擇一張桌子：wp_1234_term_taxonomy

執行此查詢

SELECT term_taxonomy_id,term_id,parent FROM wp_1234_term_taxonomy PROCEDURE ANALYSE();

這不會溢出所有行。PROCEDURE ANALYSE()所做的是掃描數據並為每列推薦適當的類型以及最小值、最大值等。

較小的 INT 列肯定會提高讀寫性能。

我曾多次建議使用PROCEDURE ANALYSE()

• Nov 13, 2014:我應該對錶 id 列使用數據類型 SERIAL 嗎？
• Aug 27, 2014:為什麼 InnoDB 上的簡單 SELECT 比 MyISAM 慢 100 倍？
• Jun 13, 2012:數據類型的變化？
• Dec 10, 2011:我有重複的鍵索引嗎？
• Aug 12, 2011:哪個 DBMS 適合超快速讀取和簡單的資料結構？
• Jun 07, 2011:我應該如何優化這個表的儲存？
• May 10, 2011：在固定大小的欄位上使用 CHAR 與 VARCHAR 對性能有何影響？
• Mar 25, 2011: MySQL VARCHAR 大小的性能影響

方面#2：冗餘索引

您會驚訝於在 WordPress、Drupal、Magento 和類似產品中使用重複列模式創建了多少索引。

請下載 Percona 工具包。然後，使用pt-duplicate-key-checker。輸出將告訴您可以刪除哪些索引，並且仍然保持您的所有搜尋需求。表的載入速度必須更快，而且要填充和管理的索引更少。相信我，在減少數據庫大小和保持可搜尋性方面，我為我的內部 Magento 客戶獲得了很好的結果。

ASCECT #3：InnoDB 緩衝池

這是 InnoDB 的圖形表示（來自 Percona CTO Vadim Tkachenko）

注意左上角的 InnoDB Buffer Pool

大多數人沒有意識到高達 25% 的緩衝池（稱為插入緩衝區）專門用於處理對非唯一索引的更改。這些被寫入系統表空間（ibdata1）中的插入緩衝區。由於 InnoDB 緩衝池中的可用記憶體非常寶貴，較小的 INT 將允許更多的數據和索引頁面適合緩衝池。

方面 #4：數據壓縮

有些人受益於使用梭子魚儲存格式壓縮數據以進行儲存，但如果您沒有足夠的 RAM，則可能會降低性能。為什麼 ？

回來Mar 02, 2012，我寫了我對innodb_file_format Barracuda的回答。詳細解釋如下： 當一個壓縮頁面被訪問時，InnoDB Buffer 互動會解壓這個壓縮頁面。這會使緩衝池膨脹。因此，如果您不能顯著增加innodb_buffer_pool_size以容納壓縮和未壓縮的頁面，那麼使用梭子魚不適合您。

即使你有足夠的 RAM，如果除了對舊頁面進行正常的LRU 修剪之外，還有很多頁面要解壓縮，性能仍然會受到一點影響。

簡短的回答：不要這樣做！

引用自：https://dba.stackexchange.com/questions/86825