優化 Percona MySQL InnoDB 3.2TB 數據庫
（在你稱我為白痴或開始大笑之前，請記住這是我的一個真正的交易，我不能取消這個任務，因為它是一個更大項目的一部分）
我有一個非常大的數據庫伺服器，並且在瘋狂的小型伺服器上執行，即。32GB 記憶體，24 核。在周末，我們將向機器添加 18GB 的 RAM，以使其功能更強大（白天的伺服器負載平均上升到 80 ！！），直到我們將使用該數據庫解決應用程序的性能問題。
我懷疑負載是由於缺少可用 RAM（SWAP 中總是大約 5GB）而導致 DB 正在交換。
這個數據庫有多個小型表和一個巨大的表，它以大約 350,000 條記錄/小時的速率接收 GPS 和 IO 數據，並且該表按分區/月進行分區。
Mysqltuner 建議在所有表上執行優化表，但我已經讀過在 InnoDB 表上這樣做是沒用的，而且需要很長時間。
這是腳本輸出的一個片段：
General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Reduce your overall MySQL memory footprint for system stability Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Increase table_cache gradually to avoid file descriptor limits Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** query_cache_limit (> 16M, or use smaller result sets) join_buffer_size (> 2.0M, or always use indexes with joins) tmp_table_size (> 16M) max_heap_table_size (> 16M) table_cache (> 4096) innodb_buffer_pool_size (>= 1726G)我應該盲目相信它還是有其他方法可以做到這一點？
我知道第一件事是在升級後重新配置數據庫，我還應該注意什麼以及我應該嘗試什麼？停機時間應該盡可能短，所以我真的不想執行一個連續執行 5 小時的查詢。
忘記 mysqltuner 並檢查人工建議。該工具會告訴您一般性建議，這些建議在某些情況下可能無用甚至有害。優化表可能沒用，但它會鎖定您的表以進行寫入。從長遠來看，顧問可以為您節省時間和金錢。
對於 MySQL 來說，交換應該是不行的。確保調整你的innodb_buffer_pool_size以最大化記憶體使用而不交換。請確保您了解可能還有其他使用記憶體的東西：文件系統記憶體，日誌記錄和其他操作所需的，以及每個客戶端使用的記憶體，例如連接緩衝區和排序緩衝區。加起來應該少於可用的物理記憶體，因為 MySQL/InnoDB 有自己的緩衝方式，如果它使用虛擬記憶體，而實際上它在磁碟上，那麼你將度過一段糟糕的時光。
如果不對您的伺服器進行全面審查，就很難提供萬無一失的“一般建議”。但根據我的經驗，90% 的問題出在查詢和數據庫設計上，而不是伺服器配置上。
然而，在這裡你有一個很好的人（Peter Zaitsev）**對 MySQL/Innodb 配置優化的一個很好的介紹。**希望能幫助到你。