如何在具有 16 GB RAM 的 QuadCore 機器上充分利用 MySQL？
我在我的工作站上執行 MySQL 5.5 伺服器以進行科學數據分析，並且想知道如何配置 MySQL 以充分利用它的性能。我通常執行的查詢類型涉及 10-20 個表的連接，並且可以執行很長時間，一到幾分鐘也不例外。只有極少數使用者同時訪問數據庫（最多 5 個）。我將伺服器從具有 2.2 GHz 雙核和 4 GB RAM 的 Lenovo Thinkpad T61 移至以下帶有手工選擇組件的全新機器：
- 英特爾 i7 3770，4x 3.4 GHz（執行 @ 4x3.7 GHz）
- Z77 晶片組
- 16 GB DDR3 1600 記憶體
- Windows 7 教授 64 位
- Windows 和 MySQL 伺服器在 Intel 520 系列 SSD 驅動器上執行。
第一次測試（在兩台機器上執行相同的查詢）顯示新的速度明顯提高，但查詢仍然需要很多時間，我預計會有更多的提升。有問題的查詢得到了相當好的優化，即所有表都有正確的鍵，也被用作“解釋擴展”。
現在回到我目前的 MySQL 設置：首先我應該提到很久以前我從 MyISAM 遷移到 Innodb。
我的一些 my.ini 調整（即偏離預設設置）：
# Maximum size for internal (in-memory) temporary tables. If a table # grows larger than this value, it is automatically converted to disk # based table This limitation is for a single table. There can be many # of them. #tmp_table_size=35M tmp_table_size=4000M max_heap_table_size=4000M # InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and # row data. The bigger you set this the less disk I/O is needed to # access data in tables. On a dedicated database server you may set this # parameter up to 80% of the machine physical memory size. Do not set it # too large, though, because competition of the physical memory may # cause paging in the operating system. Note that on 32bit systems you # might be limited to 2-3.5G of user level memory per process, so do not # set it too high. #innodb_buffer_pool_size=96M innodb_buffer_pool_size=800M general-log expire_logs_days = 60 general_log_file = "F:/my_query_mysql.log" log-output = TABLE optimizer_search_depth = 0 #meant to cure the "statistics state" bug in some queries我想知道是否有人會建議更改上述數字甚至是我不知道的進一步設置。
我將不勝感激任何有用的評論。
史蒂夫
編輯：我有兩個查詢涉及跨 10-20 個表的連接，並在我的聯想筆記本和新 PC 上執行它們。查詢 #1 在新機器上用了 3 分 36 秒，而在筆記型電腦上用了 9 分 11 秒；查詢 #2 在工作站上用了 22.5 秒，而在筆記型電腦上用了 48.5 秒。因此，執行速度大約提高了 2-2.5 倍。在工作站上，甚至沒有使用 50% 的 RAM。四個核心的平均 CPU 負載（由 Windows 任務管理器報告）僅為 13% 左右。每個核心的負載（由 Core Temp 報告）對於 ONE 核心約為 25-40%，而對於其他核心則 <=10%，這表明 MySQL 不會為單個查詢使用多個核心.
由於您執行的是 MySQL 5.5，您可能需要考慮配置 InnoDB 以訪問多個核心
這是您應該使用的設置
innodb_thread_concurrency設置 InnoDB 可以保持打開的並發執行緒數的上限。為此設置的最佳整數是（2 X CPU 數量）+ 磁碟數量。更新：正如我從 Percona NYC 會議中了解到的那樣，您應該將其設置為 0，以提醒 InnoDB 儲存引擎為其執行的環境找到最佳執行緒數。
innodb_concurrency_tickets設置可以不受懲罰地繞過並發檢查的執行緒數。達到該限制後，執行緒並發檢查再次成為常態。
innodb_commit_concurrency設置可以送出的並發事務數。由於預設值為 0，因此不設置它允許同時送出任意數量的事務。
innodb_thread_sleep_delay設置 InnoDB 執行緒在重新進入 InnoDB 隊列之前可以休眠的毫秒數。預設值為 10000（10 秒）。
innodb_read_io_threads和innodb_write_io_threads（都從 MySQL 5.1.38 開始）為讀取和寫入分配指定數量的執行緒。預設值為 4，最大值為 64。
innodb_replication_delay對從屬設備施加執行緒延遲，達到 innodb_thread_concurrency。
這是我過去關於 MySQL 5.5 和為 InnoDB 啟動多核的文章
Jun 01, 2012:我有 16GB 的記憶體，我應該如何配置 MySQL 伺服器？May 07, 2012: MySQL 伺服器性能Apr 26, 2012: CPU 性能與數據庫伺服器有關嗎？Mar 16, 2012:在 Debian 上使用多個核心進行單個 MySQL 查詢Oct 07, 2011:我應該使用 MyISAM 以外的儲存引擎來優化這些表還是應該獲得更好的磁碟？Sep 20, 2011:多核和 MySQL 性能Sep 12, 2011:可以讓 MySQL 使用多個核心嗎？
Percona-領先的 MySQL 顧問提供MySQL 配置嚮導。它允許您
my.cnf/my.ini根據系統配置進行配置。Percona 人還發布了一本名為《高性能 MySQL》的書。第三版最近發布，詳細介紹了調整。