MySQL 性能問題
在過去的 3 周里，我們的 MySQL 伺服器一直存在瓶頸問題。我一直在使用 MonYOG 來查看程序列表，試圖掌握這些問題。我們知道我們在程式碼中執行的一些查詢和流程沒有得到優化，但我並不完全相信這是我們問題的主要來源。我覺得我們的伺服器應該能夠克服這些問題。
我們的表是 innodb 和 myISAM 的混合體。我絕不是一名 DBA，也不假裝自己是一名 DBA，所以我不確定在我們目前的環境中哪種引擎是最好的。我們閱讀量很大，但也混合了大量的更新和插入。我看到很多鎖定的表，這讓我認為 innodb 可能會更好，因為它執行行鎖定而不是表鎖定。我將我們的一些表從 MyISAM 轉換為 innodb，以利用一些可用的設置。開發人員也在使用大量複雜的連接。
這是我們在 my.cnf 中執行的內容：
[mysqld] datadir=/var/lib/mysql port=3306 socket=/var/lib/mysql/mysql.sock user=mysql key_buffer_size=512M innodb_file_per_table innodb_buffer_pool_size=6GB #the following line is causing some odd errors when doing db dump #innodb_log_file_size=128M innodb_log_buffer_size=8M innodb_additional_mem_pool_size=32M max_allowed_packet=16M join_buffer_size=8M sort_buffer_size=8M max_connections=500 wait_timeout=500 skip-name-resolve thread_cache=256 table_cache=256 tmp_table_size=48M max_heap_table_size=48M query_cache_size=64M #logging of slow queries log-slow-queries=/var/log/mysql-slow-query.log # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). #old_passwords=1 # Disabling symbolic-links is recommended to prevent assorted security risks; # to do so, uncomment this line: # symbolic-links=0 [mysqld_safe] log-error=/var/log/mysqld.log #pid-file=/var/run/mysqld/mysqld.pid上週我將目前的“innodb_buffer_pool_size”更改為 6GB，這極大地改善了瓶頸。實際上，我們今天才真正開始再次看到問題。自從學校開學和足球賽季開始以來，本週的交通量有所增加。
如果需要，我可以提供各種統計資訊。我不確定目前還可以提供什麼。
如果我無法弄清楚這一點，我將被迫請來顧問。我希望有人能夠幫助我處理其中的一些設置。
提前致謝。
- 編輯 - - - - - - - - - -
以下是要求的一些附加資訊：
MySQL 版本 - 5.0.95
作業系統版本 - CentOS 5.6（將在未來幾周升級到 6.4）
伺服器 - Dell PowerEdge R710
CPU - 雙四核 2.8GHz
RAM - 12GB
這是一台專用機器。這個盒子上唯一執行的是 MySQL
表鎖定
MyISAM可能是一個殺手，遷移到InnoDB可能是您可以做的最好的事情之一，以繼續提高可伸縮性。當然，您對 的更改innodb_buffer_pool_size不會影響不是InnoDB.然而，一個問題是 MySQL 5.0 中的 InnoDB 版本與後來的版本相比仍然相當原始，尤其是在多核機器和內部擴展方面。這在High-Performance MySQL中進行了詳細討論，最後一次更新是一年多前，但仍然非常有用，儘管由於當時的發布狀態，MySQL 5.6 以現在時和未來時態的混合形式進行了討論. 我與這本書或其作者沒有任何從屬關係，我只是認為這是一個很好的參考。如果您沒有它，我會推薦它，因為它詳細介紹了該做什麼、不該做什麼以及為什麼。
但是，如果正在考慮的系統是我的系統，我會計劃至少升級到 MySQL 5.5，並且可能升級到 MySQL 5.6，因為 InnoDB 和其他地方的內部結構有了顯著改進。
查看您的配置，當您查看性能問題時，始終需要考慮查詢記憶體。較大的記憶體可能會有所幫助（可能是 128M 到 256M），但較小或禁用的查詢記憶體也可能是有益的，因為它確實代表了每個
SELECT查詢都必須通過的全域阻塞點。適當的設置幾乎完全是特定於工作負載的。在你的配置中沒有什麼特別次優的，但我想補充一點，如果你想使用你在網上找到的任何調整“腳本”……試著抵制這種誘惑。“調整”只有您有特定理由調整的內容，並且一次只能調整一個參數。成功升級後，嘗試刪除盡可能多的自定義值（除了
innodb_buffer_pool_size），並讓新版本的行為及其預設值決定需要調整的內容。跨版本升級時，官方推薦的路徑始終是從舊版本執行完整的 mysqldump，並在新安裝上恢復，儘管可以進行“二進制”升級，您只需針對舊版本啟動新版本程式碼
datadir和做mysql_upgrade。官方路徑是從 5.0 到 5.1，然後從 5.1 到 5.5。http://dev.mysql.com/doc/refman/5.1/en/upgrading-from-previous-series.html http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html
有很多東西要消化，但底線是 5.0 已經結束生命週期，一年多來還沒有發布這麼多的錯誤修復……而較新的版本代表了一個大幅改進的產品，不應該需要對您的應用程序進行重大更改。