對於單台運行的WEB服務器,建議加上:
skip-locking
skip-name-resolve
skip-networking
在PHP鏈接數據庫時使用”LOCALHOST”.這樣 MySQL客戶端庫將覆蓋之並嘗試連接到本地套接字. (
我們可以從PHP.INI中
代碼:
; Default socket name for local MySQL connects.If empty, uses the built- in ; MySQL defaults. mysql.default_socket = /tmp/mysql.sock
看出默認情況下UNIX 將訪問/tmp/mysql.sock)
以下是部分選項解釋:
my.cnf默認是不存在的.你可以在/usr/local/share/mysql/下看到:
my-huge.cnf
my-innodb-heavy-4G.cnf
my-large.cnf
my-medium.cnf
my-small.cnf
等文件.將其中合適你機器配置的文件拷貝到/etc/my.cnf或mysql data目錄/my.cnf(/var/db/mysql)下或~/.my.cnf.文件內都有詳細的說明
比如我是在freebsd下用ports裝的,copy其中一個文件到/usr/local/etc 這個目錄下即可
————————————–
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
#避免MySQL的外部鎖定，減少出錯機率增強穩定性。
skip-name-resolve
禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！
back_log = 384
指定MySQL可能的連接數量。當MySQL主線程在很短的時間內接收到非常多的連接請求，該參數生效，主線程花費很短的時間檢查連接並且啟動一個新線程。
back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自己的限制。
試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。
key_buffer_size = 256M
# key_buffer_size指定用於索引的緩衝區大小，增加它可得到更好的索引處理性能。
對於內存在4GB左右的服務器該參數可設置為256M或384M。
注意：該參數值設置的過大反而會是服務器整體效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的服務器推薦設置為6-8M。
read_buffer_size = 4M
讀查詢操作所能使用的緩衝區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
join_buffer_size = 8M
聯合查詢操作所能使用的緩衝區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
指定MySQL查詢緩衝區的大小。可以通過在MySQL控制台執行以下命令觀察：
代碼:
# > SHOW VARIABLES LIKE '%query_cache%' ; # > SHOW STATUS LIKE 'Qcache%' ;
如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況；
如果Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝；Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多。
tmp_table_size = 256M
max_connections = 768
指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提示，則需要增大該參數值。
max_connect_errors = 10000000
wait_timeout = 10
指定一個請求的最大連接時間，對於4GB左右內存的服務器可以設置為5-10。
thread_concurrency = 8
該參數取值為服務器邏輯CPU數量×2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持HT超線程，所以實際取值為4 × 2 ＝ 8
skip- networking
開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項！否則將無法正常連接！
———————–
update:
記錄兩個,今天在cu上看到有兩個人問起bsd下mysq的安裝問題,make install 後無法啟動mysql,如下:
1.在mysql的log裡看到如下的錯誤:
[ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
解決辦法如下:
#/usr/local/bin/mysql_install_db2.在log裡發現如下:
/usr/local/libexec/mysqld: Can't find file: './mysql/host.frm'
出現這個問題是執行mysql_install_db後權限的問題,解決辦法如下:
# chown -R mysql:mysql /var/db/mysql/之後就可以用mysqld_safe來啟動了,不過首先記得給root加密碼
摘自：http://dev.firnow.com/course/7_databases/mysql/Mysqljs/2008829/138802.html
2010年5月26日 星期三
百萬記錄級MySQL數據庫及Discuz!論壇優化
Discuz MYSQL 數據庫 性能：
最近，幫一個朋友優化一個擁有20萬主題，100萬帖子，3萬多會員，平均在線人數2000人的Discuz!論壇，採用 Linux2.6+Apache2+mod_php5+MySQL5，服務器配置為雙至強+4G內存，優化前，系統平均負載（load average）基本維持在10以上，MySQL的CPU佔用率基本在90%以上，優化後，系統平均負載降到0.5以下，MySQL的CPU佔用率很少有超過10%的時候。優化前YSlow得分只有35分，優化後YSlow得分86分。現將優化的過程和經驗做一個記錄：
首先，對 Apache進行優化，編輯httpd.conf，設置HostnameLookups、KeepAlive、MaxKeepAliveRequests 以及KeepAliveTimeout四個參數，調整MaxSpareServers、ServerLimit、MaxClients以及 MaxRequestsPerChild參數，還可以考慮棄用prefork而採用worker MPM。設置mod_deflate及mod_expires模塊，不過注意Discuz!不能對PHP文件開啟Expires，否則會出現問題。另外還可以考慮開啟mod_cache和mod_mem_cache模塊。另外利用cronolog按天對日誌進行輪循截斷，如果日誌特別大，也可以按小時截斷。另外再加上Awstats對日誌進行分析，並用gzip對日誌進行壓縮，自動刪除1個月前的日誌。
其次，對PHP進行優化，編輯 php.ini，調整output_buffering、zlib.output_compression及max_execution_time、 max_input_time、memory_limit等參數，並安裝Xcache和Zend Optimizer。
然後對MySQL 進行優化。首先重新靜態編譯MySQL，使其只支持MyISAM和Memory兩種引擎，並按Discuz!編碼選擇只支持UTF-8或者GBK字符集。編輯my.cnf，設置skip-locking、skip-external-locking、skip-networking和skip-name- resolve，根據內存和數據庫狀態具體調整key_buffer_size、query_cache_size、 query_cache_limit、max_allowed_packet、table_cache、thread_cache_size、 sort_buffer_size、read_buffer_size、read_rnd_buffer_size、join_buffer_size、 tmp_table_size、max_tmp_tables、back_log、max_connections、wait_timeout的參數。
對數據庫進行優化，將threads和posts表中部分未索引的字段增加索引，並將supersite數據庫表從bbs數據庫獨立出去。修改discuz!配置文件，設置開啟pconnect。
對 Discuz！設置進行優化。進入Discuz!系統設置，修改頁面緩存設置中的緩存有效期和緩存係數，修改服務器優化中的禁止瀏覽器緩衝和頁面Gzip 壓縮，修改防盜鏈設置中下載附件來路檢查，用JSMin自動對js文件進行縮減（Discuz! 6.1的common.js原文件29.3k，經JSMin縮減後為24.1k，再經deflate後為7.3k），修改attachments.php 文件，將：
//dheader(』Cache-control: max-age=31536000′);
//dheader(』Expires: 『.gmdate(』D, d M Y H:i:s', $timestamp + 31536000).』 GMT');
前的註釋去掉。修改模板目錄下adv.htm，去掉與Insenz有關的代碼。
通過查看MySQL的status，可以看出優化後，長時間運行的Key_read_ratio基本保持在0.05%以下，Threads_cache_hitrate保持在99.9%以上。個人感覺，Discuz!將Session保存在數據庫中，極大地降低了 Query Cache的命中率，如果需要進一步優化，可以考慮修改Discuz!源碼，將Session保存到Memcache中。
優化之後用Siege做並發壓力測試，在200並發下，基本沒有任何錯誤。如果將來人數更多，可以考慮將平台遷移到Ngix+PHP FastCGI上。
下面是用Siege在300並發下的測試結果：
#siege -c 300 -b -r 35 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege.. done.
Transactions: 10500 hits
Availability: 100.00 %
Elapsed time: 52.68 secs
Data transferred: 65.67 MB
Response time: 1.27 secs
Transaction rate: 199.32 trans/sec
Throughput: 1.25 MB/sec
Concurrency: 253.07
Successful transactions: 10500
Failed transactions: 0
Longest transaction: 24.88
Shortest transaction: 0.00
500並發下的測試結果：
#siege -c 500 -b -r 20 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege.. done.
Transactions: 9979 hits
Availability: 99.79 %
Elapsed time: 86.52 secs
Data transferred: 82.66 MB
Response time: 3.30 secs
Transaction rate: 115.34 trans/sec
Throughput: 0.96 MB/sec
Concurrency: 381.07
Successful transactions: 9979
Failed transactions: 21
Longest transaction: 34.80
Shortest transaction: 0.00
摘自：http://www.dk101.com/index.php/125562/viewspace-42577.html
最近，幫一個朋友優化一個擁有20萬主題，100萬帖子，3萬多會員，平均在線人數2000人的Discuz!論壇，採用 Linux2.6+Apache2+mod_php5+MySQL5，服務器配置為雙至強+4G內存，優化前，系統平均負載（load average）基本維持在10以上，MySQL的CPU佔用率基本在90%以上，優化後，系統平均負載降到0.5以下，MySQL的CPU佔用率很少有超過10%的時候。優化前YSlow得分只有35分，優化後YSlow得分86分。現將優化的過程和經驗做一個記錄：
首先，對 Apache進行優化，編輯httpd.conf，設置HostnameLookups、KeepAlive、MaxKeepAliveRequests 以及KeepAliveTimeout四個參數，調整MaxSpareServers、ServerLimit、MaxClients以及 MaxRequestsPerChild參數，還可以考慮棄用prefork而採用worker MPM。設置mod_deflate及mod_expires模塊，不過注意Discuz!不能對PHP文件開啟Expires，否則會出現問題。另外還可以考慮開啟mod_cache和mod_mem_cache模塊。另外利用cronolog按天對日誌進行輪循截斷，如果日誌特別大，也可以按小時截斷。另外再加上Awstats對日誌進行分析，並用gzip對日誌進行壓縮，自動刪除1個月前的日誌。
其次，對PHP進行優化，編輯 php.ini，調整output_buffering、zlib.output_compression及max_execution_time、 max_input_time、memory_limit等參數，並安裝Xcache和Zend Optimizer。
然後對MySQL 進行優化。首先重新靜態編譯MySQL，使其只支持MyISAM和Memory兩種引擎，並按Discuz!編碼選擇只支持UTF-8或者GBK字符集。編輯my.cnf，設置skip-locking、skip-external-locking、skip-networking和skip-name- resolve，根據內存和數據庫狀態具體調整key_buffer_size、query_cache_size、 query_cache_limit、max_allowed_packet、table_cache、thread_cache_size、 sort_buffer_size、read_buffer_size、read_rnd_buffer_size、join_buffer_size、 tmp_table_size、max_tmp_tables、back_log、max_connections、wait_timeout的參數。
對數據庫進行優化，將threads和posts表中部分未索引的字段增加索引，並將supersite數據庫表從bbs數據庫獨立出去。修改discuz!配置文件，設置開啟pconnect。
對 Discuz！設置進行優化。進入Discuz!系統設置，修改頁面緩存設置中的緩存有效期和緩存係數，修改服務器優化中的禁止瀏覽器緩衝和頁面Gzip 壓縮，修改防盜鏈設置中下載附件來路檢查，用JSMin自動對js文件進行縮減（Discuz! 6.1的common.js原文件29.3k，經JSMin縮減後為24.1k，再經deflate後為7.3k），修改attachments.php 文件，將：
//dheader(』Cache-control: max-age=31536000′);
//dheader(』Expires: 『.gmdate(』D, d M Y H:i:s', $timestamp + 31536000).』 GMT');
前的註釋去掉。修改模板目錄下adv.htm，去掉與Insenz有關的代碼。
通過查看MySQL的status，可以看出優化後，長時間運行的Key_read_ratio基本保持在0.05%以下，Threads_cache_hitrate保持在99.9%以上。個人感覺，Discuz!將Session保存在數據庫中，極大地降低了 Query Cache的命中率，如果需要進一步優化，可以考慮修改Discuz!源碼，將Session保存到Memcache中。
優化之後用Siege做並發壓力測試，在200並發下，基本沒有任何錯誤。如果將來人數更多，可以考慮將平台遷移到Ngix+PHP FastCGI上。
下面是用Siege在300並發下的測試結果：
#siege -c 300 -b -r 35 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege.. done.
Transactions: 10500 hits
Availability: 100.00 %
Elapsed time: 52.68 secs
Data transferred: 65.67 MB
Response time: 1.27 secs
Transaction rate: 199.32 trans/sec
Throughput: 1.25 MB/sec
Concurrency: 253.07
Successful transactions: 10500
Failed transactions: 0
Longest transaction: 24.88
Shortest transaction: 0.00
500並發下的測試結果：
#siege -c 500 -b -r 20 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege.. done.
Transactions: 9979 hits
Availability: 99.79 %
Elapsed time: 86.52 secs
Data transferred: 82.66 MB
Response time: 3.30 secs
Transaction rate: 115.34 trans/sec
Throughput: 0.96 MB/sec
Concurrency: 381.07
Successful transactions: 9979
Failed transactions: 21
Longest transaction: 34.80
Shortest transaction: 0.00
摘自：http://www.dk101.com/index.php/125562/viewspace-42577.html
MySQL優化實例
在Apache, PHP, MySQL的體系架構中，MySQL對於性能的影響最大，也是關鍵的核心部分。對於Discuz!論壇程序也是如此，MySQL的設置是否合理優化，直接影響到論壇的速度和承載量！同時，MySQL也是優化難度最大的一個部分，不但需要理解一些MySQL專業知識，同時還需要長時間的觀察統計並且根據經驗進行判斷，然後設置合理的參數。
下面我們了解一下MySQL優化的一些基礎，MySQL的優化我分為兩個部分，一是服務器物理硬件的優化；二是MySQL自身(my.cnf)的優化。
服務器硬件對MySQL性能的影響
磁盤尋道能力（磁盤I/O）,以目前高轉速SCSI硬盤(7200轉/秒)為例，這種硬盤理論上每秒尋道7200次，這是物理特性決定的，沒有辦法改變。 MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。所以，通常認為磁盤I/O是製約MySQL性能的最大因素之一，對於日均訪問量在100萬PV以上的Discuz!論壇，由於磁盤I/O的製約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案：
使用RAID-0+1磁盤陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁盤陣列上的效率不會像你期待的那樣快； 拋棄傳統的硬盤，使用速度更快的閃存式存儲設備。經過Discuz!公司技術工程的測試，使用閃存式存儲設備可比傳統硬盤速度高出6－10倍左右。
CPU 對於MySQL應用，推薦使用SMP架構的多路對稱CPU，例如：可以使用兩顆Intel Xeon 3.6GHz的CPU。
物理內存對於一台使用MySQL的Database Server來說，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存。
MySQL自身因素當解決了上述服務器硬件製約因素後，讓我們看看MySQL自身的優化是如何操作的。對MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面我們介紹一些對性能影響較大的參數。
由於my.cnf文件的優化設置是與服務器硬件配置息息相關的，因而我們指定一個假想的服務器硬件環境：
CPU : 2顆 Intel Xeon 2.4GHz
內存: 4GB DDR
硬盤: SCSI 73GB
下面，我們根據以上硬件配置結合一份已經優化好的my.cnf進行說明：
# vi /etc/my.cnf
以下只列出my.cnf文件中mysqld段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。
[mysqld ]
port = 3306
serverid = 1
socket = /tmp/ mysql .sock
skip - locking
#避免MySQL的外部鎖定，減少出錯機率增強穩定性。
skip - name - resolve
禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！
back_log = 384
指定MySQL可能的連接數量。當MySQL主線程在很短的時間內接收到非常多的連接請求，該參數生效，主線程花費很短的時間檢查連接並且啟動一個新線程。
back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自己的限制。
試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。
key_buffer_size = 256M
# key_buffer_size指定用於索引的緩衝區大小，增加它可得到更好的索引處理性能。
對於內存在4GB左右的服務器該參數可設置為256M或384M。注意：該參數值設置的過大反而會是服務器整體效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的服務器推薦設置為6-8M。
read_buffer_size = 4M
讀查詢操作所能使用的緩衝區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
join_buffer_size = 8M
聯合查詢操作所能使用的緩衝區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
指定MySQL查詢緩衝區的大小。可以通過在MySQL控制台執行以下命令觀察：
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
#如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況；
如果Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝；Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多。
tmp_table_size = 256M
max_connections = 768
指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提示，則需要增大該參數值。
max_connect_errors = 10000000
wait_timeout = 10
指定一個請求的最大連接時間，對於4GB左右內存的服務器可以設置為5-10。
thread_concurrency = 8
該參數取值為服務器邏輯CPU數量×2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持HT超線程，所以實際取值為4 × 2 ＝ 8
skip - networking
開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項！否則將無法正常連接！
摘自：https://code.google.com/p/scriptz/wiki/MySqlOptimize
下面我們了解一下MySQL優化的一些基礎，MySQL的優化我分為兩個部分，一是服務器物理硬件的優化；二是MySQL自身(my.cnf)的優化。
服務器硬件對MySQL性能的影響
磁盤尋道能力（磁盤I/O）,以目前高轉速SCSI硬盤(7200轉/秒)為例，這種硬盤理論上每秒尋道7200次，這是物理特性決定的，沒有辦法改變。 MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。所以，通常認為磁盤I/O是製約MySQL性能的最大因素之一，對於日均訪問量在100萬PV以上的Discuz!論壇，由於磁盤I/O的製約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案：
使用RAID-0+1磁盤陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁盤陣列上的效率不會像你期待的那樣快； 拋棄傳統的硬盤，使用速度更快的閃存式存儲設備。經過Discuz!公司技術工程的測試，使用閃存式存儲設備可比傳統硬盤速度高出6－10倍左右。
CPU 對於MySQL應用，推薦使用SMP架構的多路對稱CPU，例如：可以使用兩顆Intel Xeon 3.6GHz的CPU。
物理內存對於一台使用MySQL的Database Server來說，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存。
MySQL自身因素當解決了上述服務器硬件製約因素後，讓我們看看MySQL自身的優化是如何操作的。對MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面我們介紹一些對性能影響較大的參數。
由於my.cnf文件的優化設置是與服務器硬件配置息息相關的，因而我們指定一個假想的服務器硬件環境：
CPU : 2顆 Intel Xeon 2.4GHz
內存: 4GB DDR
硬盤: SCSI 73GB
下面，我們根據以上硬件配置結合一份已經優化好的my.cnf進行說明：
# vi /etc/my.cnf
以下只列出my.cnf文件中mysqld段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。
[mysqld ]
port = 3306
serverid = 1
socket = /tmp/ mysql .sock
skip - locking
#避免MySQL的外部鎖定，減少出錯機率增強穩定性。
skip - name - resolve
禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！
back_log = 384
指定MySQL可能的連接數量。當MySQL主線程在很短的時間內接收到非常多的連接請求，該參數生效，主線程花費很短的時間檢查連接並且啟動一個新線程。
back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自己的限制。
試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。
key_buffer_size = 256M
# key_buffer_size指定用於索引的緩衝區大小，增加它可得到更好的索引處理性能。
對於內存在4GB左右的服務器該參數可設置為256M或384M。注意：該參數值設置的過大反而會是服務器整體效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的服務器推薦設置為6-8M。
read_buffer_size = 4M
讀查詢操作所能使用的緩衝區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
join_buffer_size = 8M
聯合查詢操作所能使用的緩衝區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
指定MySQL查詢緩衝區的大小。可以通過在MySQL控制台執行以下命令觀察：
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
#如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況；
如果Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝；Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多。
tmp_table_size = 256M
max_connections = 768
指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提示，則需要增大該參數值。
max_connect_errors = 10000000
wait_timeout = 10
指定一個請求的最大連接時間，對於4GB左右內存的服務器可以設置為5-10。
thread_concurrency = 8
該參數取值為服務器邏輯CPU數量×2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持HT超線程，所以實際取值為4 × 2 ＝ 8
skip - networking
開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項！否則將無法正常連接！
摘自：https://code.google.com/p/scriptz/wiki/MySqlOptimize
MySQL 編譯安裝及優化
注意： 由於我是作為數據庫服務器，所以安裝系統時，只需要基本的，其餘的都可以不安裝。
新建一個名為 mysql 的用戶組
# groupadd mysql
在mysql用戶組下新建一個名為mysql的用戶
# useradd -g mysql mysql
# tar xzf mysql-5.0.70.tar.gz
# cd mysql-5.0.70
源碼編譯 MYSQL (環境 CentOS 5.2 + Intel Pentium 4 630 3.00GHz + 4G RAM ,根據具體環境做相應的變更)
# CHOST="i686-pc-linux-gnu" CFLAGS="-O3 -msse -msse2 -msse3 -mmmx -mfpmath=sse,387 -mtune=prescott -march=prescott -pipe -fomit-frame-pointer -Wa, -march=prescott -finline-limit=400 -fforce-addr" CC="gcc" CXX="gcc" CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -felide-constructors -fno-exceptions -fno-rtti " LDFLAGS="-Wl,-O2 -s" ./configure --prefix=/usr/local/mysql --localstatedir=/var/lib/mysql --enable-assembler --enable-thread-safe-client - -with-big-tables --with-charset=utf8 --with-collation=utf8_general_ci --without-debug --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static - -with-comment=Source --with-server-suffix=-enterprise-gpl --with-mysqld-user=mysql --with-extra-charsets=gbk,latin1 --with-pthread --with-innodb -- without-isam
至於具體的優化參數就懶得解釋了，因為每個人的具體環境不一樣。
GCC 編譯優化可以參考
1. 英文好的看官方最新文檔
http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
2. 英文不好的看
http://lamp.linux.gov.cn/Linux/optimize_guide.html
至於 MySQL 的編譯優化可參與 MySQL 5.1 Reference Manual 中編譯指南。
# make
編譯的時間可能會比較長
# make install
編譯安裝完成後執行後續操作：
# cd /usr/local/mysql
# bin/mysql_install_db --user=mysql
# chown -R root . //設置權限，注意後面有一個"."
# chown -R mysql /var/lib/mysql //設置mysql目錄權限
# chgrp -R mysql . //注意後面有一個"."，同時讓mysql組用戶有同root的權限
# cp share/mysql/my-innodb-heavy-4G.cnf /etc/my.cnf
# cp share/mysql/mysql.server /etc/init.d/mysqld //開機自動啟動mysql
# chmod 755 /etc/init.d/mysqld
# chkconfig --add mysqld //讓 MySQL 隨機啟動
# /etc/init.d/mysqld start //啟動 MySQL
# bin/mysqladmin -u root password "password_for_root"
# service mysqld stop //關閉 MySQL
由於我是把它作為獨立的數據服務器，為了數據庫系統時間的準確性，最好裝 NTP 服務。
# yum install –y ntp
# crontab -e
0 03 * * * /usr/sbin/ntpdate 1.cn.pool.ntp.org
中國及亞洲 NTP 服務器
server 1.cn.pool.ntp.org
server 1.asia.pool.ntp.org
server 3.asia.pool.ntp.org
以上命令設置好後存盤。
# /sbin/service crond reload
MySQL 的優化分為兩部分，一是服務器物理硬件的優化；二是 MySQL 自身( my.cnf )的優化。
1.服務器硬件對 MySQL 性能的影響
a.磁盤尋道能力,以目前高轉速SATA硬盤(7200轉/秒)為例，這種硬盤理論上每秒尋道7200次，這是物理特性決定的，沒有辦法改變。 MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。所以，通常認為磁盤I/O是製約MySQL性能的最大因素之一，對於日均訪問量在100萬 PV 以上的應用，由於磁盤I/O的製約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案。
使用 RAID-0+1 磁盤陣列 ，注意不要嘗試使用 RAID-5 ， MySQL 在 RAID-5 磁盤陣列上的效率不會像你期待的那樣快；拋棄傳統的硬盤，使用速度更快的閃存式存儲設備。經過一些測試，使用閃存式存儲設備可比傳統硬盤速度高出6-10倍左右。
b. CPU對於MySQL應用，推薦使用SMP架構的多路對稱CPU。
c. 物理內存對於一台使用 MySQL 的 Database Server 來說非常重要，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存。
2.MySQL自身因素
當解決了上述服務器硬件製約因素後，看看 MySQL 自身的優化是如何操作的。對 MySQL 自身的優化主要是對其配置文件 my.cnf 中的各項參數進行優化調整。下面介紹一些對性能影響較大的參數。
由於 my.cnf 文件的優化設置是與服務器硬件配置息息相關的，下面服務器硬件環境：
CPU: Pentium 4 630 3.00GHz Threads:2
內存: 4GB DDR2 667
硬盤: SATA 160GB
我們根據以上硬件配置結合一份已經優化好的 my.cnf 進行說明：
# vi /etc/my.cnf
以下只列出 my.cnf 文件中 [mysqld] 段落中的內容，其他段落內容對 MySQL 運行性能影響甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
# skip-locking
避免 MySQL 的外部鎖定，減少出錯機率增強穩定性
# skip-name-resolve
禁止 MySQL 對外部連接進行 DNS 解析使用這一選項可以消除 MySQL 進行 DNS 解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則 MySQL 將無法正常處理連接請求！
注意： 如果從數據庫服務器以外的 PC 連接到 DB Server 很慢時，很可能就是這個參數未打開。
# back_log
這個值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。只有如果期望在一個短時間內有很多連接，你需要增加它，換句話說，這值對到來的TCP/IP連接的偵聽隊列的大小。你的操作系統在這個隊列大小上有它自己的限制。試圖設定back_log高於你的操作系統的限制將是無效的。 當你觀察你的主機進程列表，發現大量
264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL
的待連接進程時，就要加大 back_log 的值了。默認數值是50，一般384就夠了。
# key_buffer_size
這對 MyISAM 表來說非常重要。如果只是使用 MyISAM 表，可以把它設置為可用內存的30-40% 。合理的值取決於索引大小,數據量以及負載-- 記住: MyISAM 表會使用操作系統的緩存來緩存數據，因此需要留出部分內存給它們，很多情況下數據比索引大多了。儘管如此，需要總是檢查是否所有的 key_buffer 都被利用了 。 -- .MYI 文件只有1GB，而 key_buffer 卻設置為4GB的情況是非常少的，這麼做太浪費了。如果你很少使用 MyISAM 表，那麼也保留不低於16-32MB的 key_buffer_size 以適應給予磁盤的臨時表索引所需。
# sort_buffer_size
查詢排序時所能使用的緩衝區大小。 注意 ：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB 。所以，對於內存在4GB左右的服務器推薦設置為6-8M 。
# read_buffer_size
讀查詢操作所能使用的緩衝區大小。和 sort_buffer_size 一樣，該參數對應的分配內存也是每連接獨享！
# join_buffer_size
聯合查詢操作所能使用的緩衝區大小，和 sort_buffer_size 一樣，該參數對應的分配內存也是每連接獨享！
# query_cache_size
指定 MySQL 查詢緩衝區的大小。可以通過在 MySQL 控制台執行以下命令觀察：
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
如果 Qcache_lowmem_prunes 的值非常大，則表明經常出現緩沖不夠的情況；
如果 Qcache_hits 的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝； Qcache_free_blocks ，如果該值非常大，則表明緩衝區中碎片很多。
# max_connections
指定 MySQL 允許的最大連接進程數。如果在訪問時經常出現 Too Many Connections 的錯誤提示，則需要增大該參數值。
# wait_timeout
指定一個請求的最大連接時間，對於4GB 左右內存的服務器可以設置為5-10 。
# thread_concurrency
該參數取值為服務器邏輯CPU數量×2，在本例中，如果服務器有2顆邏輯CPU，而CPU又支持 HT 超線程，所以實際取值為4 × 2 ＝ 8
# skip-networking
開啟該選項可以徹底關閉 MySQL 的 TCP/IP 連接方式，如果 WEB 服務器是以遠程連接的方式訪問 MySQL 數據庫服務器則不要開啟該選項！否則將無法正常連接！
# innodb_buffer_pool_size
這對 Innodb 表來說非常重要。 Innodb 相比 MyISAM 表對緩衝更為敏感。 MyISAM 可以在默認的 key_buffer_size 設置下運行的可以，然而 Innodb 在默認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。由於 Innodb 把數據和索引都緩存起來，無需留給操作系統太多的內存，因此如果只需要用 Innodb 的話則可以設置它高達70-80%的可用內存。如果你的數據量不大，並且不會暴增，那麼無需把 innodb_buffer_pool_size 設置的太大了。
# innodb_additional_pool_size
這個選項對性能影響並不太多，至少在有差不多足夠內存可分配的操作系統上是這樣。不過如果你仍然想設置為20MB( 或者更大) ，就需要看一下Innodb 其他需要分配的內存有多少。
# innodb_log_file_size
在高寫入負載尤其是大數據集的情況下很重要。這個值越大則性能相對越高，但是要注意到可能會增加恢復時間。我經常設置為64-512MB ，跟據服務器大小而異。
# innodb_log_buffer_size
默認的設置在中等強度寫入負載以及較短事務的情況下服務器性能還可以。如果存在更新操作峰值或者負載較大，就應該考慮加大它的值了。如果它的值設置太高了，可能會浪費內存(它每秒都會刷新一次),因此無需設置超過1 秒所需的內存空間。通常8-16MB 就足夠了。越小的系統它的值越小。
# innodb_flush_logs_at_trx_commit
Crying about Innodb being 100 times slower than MyISAM ? You probably forgot to adjust this value. Default value of 1 will mean each update transaction commit (or each statement outside of transaction) will need to flush log to the disk which is rather expensive, especially if you do not have Battery backed up cache. Many applications, especially those moved from MyISAM tables are OK with value 2 which means do not flush log to the disk but only flush it to OS cache. The log is still flushed to the disk each second so you normally would not loose more than 1-2 sec worth of updates. Value 0 is a bit faster but is a bit less secure as you can lose transactions even in case MySQL Server crashes. Value 2 only cause data loss with full OS crash.
# table_cache
Opening tables can be expensive. For example MyISAM tables mark MYI header to mark table as currently in use. You do not want this to happen so frequently and it is typically best to size your cache so it is large enough to keep most of your tables open. It uses some OS resources and some memory but for modern hardware it is typically not the problem. 1024 is good value for applications with couple hundreds tables (remember each connection needs its own entry) if you have many connections or many tables increase it larger. I've seen values over 100.000 used.
# thread_cache
Thread creation/destructions can be expensive, which happen at each connect/disconnect. I normally set this value to at least 16. If application has large jumps in amount of concurrent connections and I see fast growth of
Threads_Created variable I boost it higher. The goal is not to have threads created in normal operation.
# query_cache
If your application is read intensive and you do not have application level caches this can be great help. Do not set it too large as it may slow things down as its maintenance may get expensive. Values from 32M to 512M normally make sense. Check it however after a while and see if it is well used. For certain workloads cache hit ratio is lower than would justify having it enabled.
Note: as you can see all of these are global variables. These variables depend on hardware and mix of storage engines, while per session variables are typically workload specific. If you have simple queries there is no reason to increase sort_buffer_size even if you have 64GB of memory to waste. Furthermore doing so may decrease performance.
I normally leave per session variable tuning to second step after I can analyze workload.
注意： 就像你看到的上面這些全局表量，它們都是依據硬件配置以及不同的存儲引擎而不同，但是會話變量通常是根據不同的負載來設定的。如果你只有一些簡單的查詢，那麼就無需增加 sort_buffer_size 的值了，儘管你有64GB的內存。搞不好也許會降低性能。
通常在分析系統負載後才來設置會話變量。
另附：如果發現你的應用日誌裡會有 too many open files 時，應修改 linux 系統的 open file 數量，也可通過以下命令來查看那個程序打開的文件數最多。
# lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more
可能出現的結果如下：
131 24204
57 24244
57 24231
56 24264
其中第一行是打開的文件句柄數量，第二行是進程號。得到進程號後，我們可以通過 ps 命令得到進程的詳細內容。
# ps -aef|grep 24204
mysql 24204 24162 99 16:15 ? 00:24:25 /usr/sbin/mysqld
修改系統默認值 ulimit -HSn 4096
以上命令中，H指定了硬性大小，S指定了軟性大小，n表示設定單個進程最大的打開文件句柄數量可以修改 /etc/profile 把上面命令加到最後，然後 source /etc/profile 再通過 ulimit -a 就可以看到修改後的結果了。
關於lsof命令的用法，詳細可參考IBM技術社區中的一篇關於 lsof 的文章。
摘自：http://janwer.javaeye.com/blog/210952
新建一個名為 mysql 的用戶組
# groupadd mysql
在mysql用戶組下新建一個名為mysql的用戶
# useradd -g mysql mysql
# tar xzf mysql-5.0.70.tar.gz
# cd mysql-5.0.70
源碼編譯 MYSQL (環境 CentOS 5.2 + Intel Pentium 4 630 3.00GHz + 4G RAM ,根據具體環境做相應的變更)
# CHOST="i686-pc-linux-gnu" CFLAGS="-O3 -msse -msse2 -msse3 -mmmx -mfpmath=sse,387 -mtune=prescott -march=prescott -pipe -fomit-frame-pointer -Wa, -march=prescott -finline-limit=400 -fforce-addr" CC="gcc" CXX="gcc" CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -felide-constructors -fno-exceptions -fno-rtti " LDFLAGS="-Wl,-O2 -s" ./configure --prefix=/usr/local/mysql --localstatedir=/var/lib/mysql --enable-assembler --enable-thread-safe-client - -with-big-tables --with-charset=utf8 --with-collation=utf8_general_ci --without-debug --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static - -with-comment=Source --with-server-suffix=-enterprise-gpl --with-mysqld-user=mysql --with-extra-charsets=gbk,latin1 --with-pthread --with-innodb -- without-isam
至於具體的優化參數就懶得解釋了，因為每個人的具體環境不一樣。
GCC 編譯優化可以參考
1. 英文好的看官方最新文檔
http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
2. 英文不好的看
http://lamp.linux.gov.cn/Linux/optimize_guide.html
至於 MySQL 的編譯優化可參與 MySQL 5.1 Reference Manual 中編譯指南。
# make
編譯的時間可能會比較長
# make install
編譯安裝完成後執行後續操作：
# cd /usr/local/mysql
# bin/mysql_install_db --user=mysql
# chown -R root . //設置權限，注意後面有一個"."
# chown -R mysql /var/lib/mysql //設置mysql目錄權限
# chgrp -R mysql . //注意後面有一個"."，同時讓mysql組用戶有同root的權限
# cp share/mysql/my-innodb-heavy-4G.cnf /etc/my.cnf
# cp share/mysql/mysql.server /etc/init.d/mysqld //開機自動啟動mysql
# chmod 755 /etc/init.d/mysqld
# chkconfig --add mysqld //讓 MySQL 隨機啟動
# /etc/init.d/mysqld start //啟動 MySQL
# bin/mysqladmin -u root password "password_for_root"
# service mysqld stop //關閉 MySQL
由於我是把它作為獨立的數據服務器，為了數據庫系統時間的準確性，最好裝 NTP 服務。
# yum install –y ntp
# crontab -e
0 03 * * * /usr/sbin/ntpdate 1.cn.pool.ntp.org
中國及亞洲 NTP 服務器
server 1.cn.pool.ntp.org
server 1.asia.pool.ntp.org
server 3.asia.pool.ntp.org
以上命令設置好後存盤。
# /sbin/service crond reload
MySQL 的優化分為兩部分，一是服務器物理硬件的優化；二是 MySQL 自身( my.cnf )的優化。
1.服務器硬件對 MySQL 性能的影響
a.磁盤尋道能力,以目前高轉速SATA硬盤(7200轉/秒)為例，這種硬盤理論上每秒尋道7200次，這是物理特性決定的，沒有辦法改變。 MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。所以，通常認為磁盤I/O是製約MySQL性能的最大因素之一，對於日均訪問量在100萬 PV 以上的應用，由於磁盤I/O的製約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案。
使用 RAID-0+1 磁盤陣列 ，注意不要嘗試使用 RAID-5 ， MySQL 在 RAID-5 磁盤陣列上的效率不會像你期待的那樣快；拋棄傳統的硬盤，使用速度更快的閃存式存儲設備。經過一些測試，使用閃存式存儲設備可比傳統硬盤速度高出6-10倍左右。
b. CPU對於MySQL應用，推薦使用SMP架構的多路對稱CPU。
c. 物理內存對於一台使用 MySQL 的 Database Server 來說非常重要，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存。
2.MySQL自身因素
當解決了上述服務器硬件製約因素後，看看 MySQL 自身的優化是如何操作的。對 MySQL 自身的優化主要是對其配置文件 my.cnf 中的各項參數進行優化調整。下面介紹一些對性能影響較大的參數。
由於 my.cnf 文件的優化設置是與服務器硬件配置息息相關的，下面服務器硬件環境：
CPU: Pentium 4 630 3.00GHz Threads:2
內存: 4GB DDR2 667
硬盤: SATA 160GB
我們根據以上硬件配置結合一份已經優化好的 my.cnf 進行說明：
# vi /etc/my.cnf
以下只列出 my.cnf 文件中 [mysqld] 段落中的內容，其他段落內容對 MySQL 運行性能影響甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
# skip-locking
避免 MySQL 的外部鎖定，減少出錯機率增強穩定性
# skip-name-resolve
禁止 MySQL 對外部連接進行 DNS 解析使用這一選項可以消除 MySQL 進行 DNS 解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則 MySQL 將無法正常處理連接請求！
注意： 如果從數據庫服務器以外的 PC 連接到 DB Server 很慢時，很可能就是這個參數未打開。
# back_log
這個值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。只有如果期望在一個短時間內有很多連接，你需要增加它，換句話說，這值對到來的TCP/IP連接的偵聽隊列的大小。你的操作系統在這個隊列大小上有它自己的限制。試圖設定back_log高於你的操作系統的限制將是無效的。 當你觀察你的主機進程列表，發現大量
264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL
的待連接進程時，就要加大 back_log 的值了。默認數值是50，一般384就夠了。
# key_buffer_size
這對 MyISAM 表來說非常重要。如果只是使用 MyISAM 表，可以把它設置為可用內存的30-40% 。合理的值取決於索引大小,數據量以及負載-- 記住: MyISAM 表會使用操作系統的緩存來緩存數據，因此需要留出部分內存給它們，很多情況下數據比索引大多了。儘管如此，需要總是檢查是否所有的 key_buffer 都被利用了 。 -- .MYI 文件只有1GB，而 key_buffer 卻設置為4GB的情況是非常少的，這麼做太浪費了。如果你很少使用 MyISAM 表，那麼也保留不低於16-32MB的 key_buffer_size 以適應給予磁盤的臨時表索引所需。
# sort_buffer_size
查詢排序時所能使用的緩衝區大小。 注意 ：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB 。所以，對於內存在4GB左右的服務器推薦設置為6-8M 。
# read_buffer_size
讀查詢操作所能使用的緩衝區大小。和 sort_buffer_size 一樣，該參數對應的分配內存也是每連接獨享！
# join_buffer_size
聯合查詢操作所能使用的緩衝區大小，和 sort_buffer_size 一樣，該參數對應的分配內存也是每連接獨享！
# query_cache_size
指定 MySQL 查詢緩衝區的大小。可以通過在 MySQL 控制台執行以下命令觀察：
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
如果 Qcache_lowmem_prunes 的值非常大，則表明經常出現緩沖不夠的情況；
如果 Qcache_hits 的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝； Qcache_free_blocks ，如果該值非常大，則表明緩衝區中碎片很多。
# max_connections
指定 MySQL 允許的最大連接進程數。如果在訪問時經常出現 Too Many Connections 的錯誤提示，則需要增大該參數值。
# wait_timeout
指定一個請求的最大連接時間，對於4GB 左右內存的服務器可以設置為5-10 。
# thread_concurrency
該參數取值為服務器邏輯CPU數量×2，在本例中，如果服務器有2顆邏輯CPU，而CPU又支持 HT 超線程，所以實際取值為4 × 2 ＝ 8
# skip-networking
開啟該選項可以徹底關閉 MySQL 的 TCP/IP 連接方式，如果 WEB 服務器是以遠程連接的方式訪問 MySQL 數據庫服務器則不要開啟該選項！否則將無法正常連接！
# innodb_buffer_pool_size
這對 Innodb 表來說非常重要。 Innodb 相比 MyISAM 表對緩衝更為敏感。 MyISAM 可以在默認的 key_buffer_size 設置下運行的可以，然而 Innodb 在默認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。由於 Innodb 把數據和索引都緩存起來，無需留給操作系統太多的內存，因此如果只需要用 Innodb 的話則可以設置它高達70-80%的可用內存。如果你的數據量不大，並且不會暴增，那麼無需把 innodb_buffer_pool_size 設置的太大了。
# innodb_additional_pool_size
這個選項對性能影響並不太多，至少在有差不多足夠內存可分配的操作系統上是這樣。不過如果你仍然想設置為20MB( 或者更大) ，就需要看一下Innodb 其他需要分配的內存有多少。
# innodb_log_file_size
在高寫入負載尤其是大數據集的情況下很重要。這個值越大則性能相對越高，但是要注意到可能會增加恢復時間。我經常設置為64-512MB ，跟據服務器大小而異。
# innodb_log_buffer_size
默認的設置在中等強度寫入負載以及較短事務的情況下服務器性能還可以。如果存在更新操作峰值或者負載較大，就應該考慮加大它的值了。如果它的值設置太高了，可能會浪費內存(它每秒都會刷新一次),因此無需設置超過1 秒所需的內存空間。通常8-16MB 就足夠了。越小的系統它的值越小。
# innodb_flush_logs_at_trx_commit
Crying about Innodb being 100 times slower than MyISAM ? You probably forgot to adjust this value. Default value of 1 will mean each update transaction commit (or each statement outside of transaction) will need to flush log to the disk which is rather expensive, especially if you do not have Battery backed up cache. Many applications, especially those moved from MyISAM tables are OK with value 2 which means do not flush log to the disk but only flush it to OS cache. The log is still flushed to the disk each second so you normally would not loose more than 1-2 sec worth of updates. Value 0 is a bit faster but is a bit less secure as you can lose transactions even in case MySQL Server crashes. Value 2 only cause data loss with full OS crash.
# table_cache
Opening tables can be expensive. For example MyISAM tables mark MYI header to mark table as currently in use. You do not want this to happen so frequently and it is typically best to size your cache so it is large enough to keep most of your tables open. It uses some OS resources and some memory but for modern hardware it is typically not the problem. 1024 is good value for applications with couple hundreds tables (remember each connection needs its own entry) if you have many connections or many tables increase it larger. I've seen values over 100.000 used.
# thread_cache
Thread creation/destructions can be expensive, which happen at each connect/disconnect. I normally set this value to at least 16. If application has large jumps in amount of concurrent connections and I see fast growth of
Threads_Created variable I boost it higher. The goal is not to have threads created in normal operation.
# query_cache
If your application is read intensive and you do not have application level caches this can be great help. Do not set it too large as it may slow things down as its maintenance may get expensive. Values from 32M to 512M normally make sense. Check it however after a while and see if it is well used. For certain workloads cache hit ratio is lower than would justify having it enabled.
Note: as you can see all of these are global variables. These variables depend on hardware and mix of storage engines, while per session variables are typically workload specific. If you have simple queries there is no reason to increase sort_buffer_size even if you have 64GB of memory to waste. Furthermore doing so may decrease performance.
I normally leave per session variable tuning to second step after I can analyze workload.
注意： 就像你看到的上面這些全局表量，它們都是依據硬件配置以及不同的存儲引擎而不同，但是會話變量通常是根據不同的負載來設定的。如果你只有一些簡單的查詢，那麼就無需增加 sort_buffer_size 的值了，儘管你有64GB的內存。搞不好也許會降低性能。
通常在分析系統負載後才來設置會話變量。
另附：如果發現你的應用日誌裡會有 too many open files 時，應修改 linux 系統的 open file 數量，也可通過以下命令來查看那個程序打開的文件數最多。
# lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more
可能出現的結果如下：
131 24204
57 24244
57 24231
56 24264
其中第一行是打開的文件句柄數量，第二行是進程號。得到進程號後，我們可以通過 ps 命令得到進程的詳細內容。
# ps -aef|grep 24204
mysql 24204 24162 99 16:15 ? 00:24:25 /usr/sbin/mysqld
修改系統默認值 ulimit -HSn 4096
以上命令中，H指定了硬性大小，S指定了軟性大小，n表示設定單個進程最大的打開文件句柄數量可以修改 /etc/profile 把上面命令加到最後，然後 source /etc/profile 再通過 ulimit -a 就可以看到修改後的結果了。
關於lsof命令的用法，詳細可參考IBM技術社區中的一篇關於 lsof 的文章。
摘自：http://janwer.javaeye.com/blog/210952
2010年4月20日 星期二
MySQL的my.cnf优化实例
我从网上找到的，我刚看了一下，还算不错，发在这里，大家看看，最好有牛人补充完善
然后，再整理整理！
========================================
在Apache, PHP, MySQL的体系架构中，MySQL对于性能的影响最大，也是关键的核心部分。对于Discuz!论坛程序也是如此，MySQL的设置是否合理优化，直接影响到论坛的速度和承载量！同时，MySQL也是优化难度最大的一个部分，不但需要理解一些MySQL专业知识，同时还需要长时间的观察统计并且根据经验进行判断，然后设置合理的参数。
下面我们了解一下MySQL优化的一些基础，MySQL的优化我分为两个部分，一是服务器物理硬件的优化；二是MySQL自身(my.cnf)的优化。
(1) 服务器硬件对MySQL性能的影响
a) 磁盘寻道能力（磁盘I/O）,以目前高转速SCSI硬盘(7200转/秒)为例，这种硬盘理论上每秒寻道7200次，这是物理特性决定的，没有办法改变。MySQL每秒钟都在进行大量、复杂的查询操作，对磁盘的读写量可想而知。所以，通常认为磁盘I/O是制约MySQL性能的最大因素之一，对于日均访问量在100万PV以上的Discuz!论坛，由于磁盘I/O的制约，MySQL的性能会非常低下！解决这一制约因素可以考虑以下几种解决方案：
使用RAID-0+1磁盘阵列，注意不要尝试使用RAID-5，MySQL在RAID-5磁盘阵列上的效率不会像你期待的那样快； 抛弃传统的硬盘，使用速度更快的闪存式存储设备。经过Discuz!公司技术工程的测试，使用闪存式存储设备可比传统硬盘速度高出6－10倍左右。
b) CPU 对于MySQL应用，推荐使用S.M.P.架构的多路对称CPU，例如：可以使用两颗Intel Xeon 3.6GHz的CPU。
c) 物理内存对于一台使用MySQL的Database Server来说，服务器内存建议不要小于2GB，推荐使用4GB以上的物理内存。
(2) MySQL自身因素当解决了上述服务器硬件制约因素后，让我们看看MySQL自身的优化是如何操作的。对MySQL自身的优化主要是对其配置文件my.cnf中的各项参数进行优化调整。下面我们介绍一些对性能影响较大的参数。
由于my.cnf文件的优化设置是与服务器硬件配置息息相关的，因而我们指定一个假想的服务器硬件环境：
CPU: 2颗Intel Xeon 2.4GHz
内存: 4GB DDR
硬盘: SCSI 73GB
下面，我们根据以上硬件配置结合一份已经优化好的my.cnf进行说明：
# vi /etc/my.cnf
以下只列出my.cnf文件中[mysqld]段落中的内容，其他段落内容对MySQL运行性能影响甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
# 避免MySQL的外部锁定，减少出错几率增强稳定性。
skip-name-resolve
禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！
back_log = 384
指定MySQL可能的连接数量。当MySQL主线程在很短的时间内接收到非常多的连接请求，该参数生效，主线程花费很短的时间检查连接并且启动一个新线程。
back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。 如果系统在一个短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自己的限制。
试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。
key_buffer_size = 256M
# key_buffer_size指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。
对于内存在4GB左右的服务器该参数可设置为256M或384M。
注意：该参数值设置的过大反而会是服务器整体效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占！如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。所以，对于内存在4GB左右的服务器推荐设置为6-8M。
read_buffer_size = 4M
读查询操作所能使用的缓冲区大小。和sort_buffer_size一样，该参数对应的分配内存也是每连接独享！
join_buffer_size = 8M
联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每连接独享！
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
指定MySQL查询缓冲区的大小。可以通过在MySQL控制台执行以下命令观察：
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
# 如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况；
如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓冲；Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多。
tmp_table_size = 256M
max_connections = 768
指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提 示，则需要增大该参数值。
max_connect_errors = 10000000
wait_timeout = 10
指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。
thread_concurrency = 8
该参数取值为服务器逻辑CPU数量×2，在本例中，服务器有2颗物理CPU，而每颗物理CPU又支持H.T超线程，所以实际取值为4 × 2 ＝ 8
skip-networking
开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！否则将无法正常连接！
摘自:http://bbs.chinaunix.net/archiver/?tid-809159.html
我从网上找到的，我刚看了一下，还算不错，发在这里，大家看看，最好有牛人补充完善
然后，再整理整理！
========================================
在Apache, PHP, MySQL的体系架构中，MySQL对于性能的影响最大，也是关键的核心部分。对于Discuz!论坛程序也是如此，MySQL的设置是否合理优化，直接影响到论坛的速度和承载量！同时，MySQL也是优化难度最大的一个部分，不但需要理解一些MySQL专业知识，同时还需要长时间的观察统计并且根据经验进行判断，然后设置合理的参数。
下面我们了解一下MySQL优化的一些基础，MySQL的优化我分为两个部分，一是服务器物理硬件的优化；二是MySQL自身(my.cnf)的优化。
(1) 服务器硬件对MySQL性能的影响
a) 磁盘寻道能力（磁盘I/O）,以目前高转速SCSI硬盘(7200转/秒)为例，这种硬盘理论上每秒寻道7200次，这是物理特性决定的，没有办法改变。MySQL每秒钟都在进行大量、复杂的查询操作，对磁盘的读写量可想而知。所以，通常认为磁盘I/O是制约MySQL性能的最大因素之一，对于日均访问量在100万PV以上的Discuz!论坛，由于磁盘I/O的制约，MySQL的性能会非常低下！解决这一制约因素可以考虑以下几种解决方案：
使用RAID-0+1磁盘阵列，注意不要尝试使用RAID-5，MySQL在RAID-5磁盘阵列上的效率不会像你期待的那样快； 抛弃传统的硬盘，使用速度更快的闪存式存储设备。经过Discuz!公司技术工程的测试，使用闪存式存储设备可比传统硬盘速度高出6－10倍左右。
b) CPU 对于MySQL应用，推荐使用S.M.P.架构的多路对称CPU，例如：可以使用两颗Intel Xeon 3.6GHz的CPU。
c) 物理内存对于一台使用MySQL的Database Server来说，服务器内存建议不要小于2GB，推荐使用4GB以上的物理内存。
(2) MySQL自身因素当解决了上述服务器硬件制约因素后，让我们看看MySQL自身的优化是如何操作的。对MySQL自身的优化主要是对其配置文件my.cnf中的各项参数进行优化调整。下面我们介绍一些对性能影响较大的参数。
由于my.cnf文件的优化设置是与服务器硬件配置息息相关的，因而我们指定一个假想的服务器硬件环境：
CPU: 2颗Intel Xeon 2.4GHz
内存: 4GB DDR
硬盘: SCSI 73GB
下面，我们根据以上硬件配置结合一份已经优化好的my.cnf进行说明：
# vi /etc/my.cnf
以下只列出my.cnf文件中[mysqld]段落中的内容，其他段落内容对MySQL运行性能影响甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
# 避免MySQL的外部锁定，减少出错几率增强稳定性。
skip-name-resolve
禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！
back_log = 384
指定MySQL可能的连接数量。当MySQL主线程在很短的时间内接收到非常多的连接请求，该参数生效，主线程花费很短的时间检查连接并且启动一个新线程。
back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。 如果系统在一个短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自己的限制。
试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。
key_buffer_size = 256M
# key_buffer_size指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。
对于内存在4GB左右的服务器该参数可设置为256M或384M。
注意：该参数值设置的过大反而会是服务器整体效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占！如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。所以，对于内存在4GB左右的服务器推荐设置为6-8M。
read_buffer_size = 4M
读查询操作所能使用的缓冲区大小。和sort_buffer_size一样，该参数对应的分配内存也是每连接独享！
join_buffer_size = 8M
联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每连接独享！
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
指定MySQL查询缓冲区的大小。可以通过在MySQL控制台执行以下命令观察：
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
# 如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况；
如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓冲；Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多。
tmp_table_size = 256M
max_connections = 768
指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提 示，则需要增大该参数值。
max_connect_errors = 10000000
wait_timeout = 10
指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。
thread_concurrency = 8
该参数取值为服务器逻辑CPU数量×2，在本例中，服务器有2颗物理CPU，而每颗物理CPU又支持H.T超线程，所以实际取值为4 × 2 ＝ 8
skip-networking
开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！否则将无法正常连接！
摘自:http://bbs.chinaunix.net/archiver/?tid-809159.html
2008年4月1日 星期二
MySQL分頁優化
MySQL中一般的分頁作法大多利用Limit限制回傳的資料筆數來達成分頁效果
例如下面的代碼
Select * From news limit 0, 100 第一頁
Select * From news limit 100,100 第二頁
Select * From news limit 200,100 第三頁
今天突然來了一個思路
和前作 上下頁查詢優化
的思路略同
定位到id值後再用id值作條件
優化的作法
經測試，一萬條數據以內一般的分頁作法比較快
超過一萬條後優化過的作法優勢就呈現出來
當數據量愈多，優化的分頁查詢速度愈快
所以在第一次查詢總資料筆數後可以增加一個判決
檢查資料量是否超過一萬筆
摘自:http://jian-zhoung.blogspot.com/2007/11/mysql.html
例如下面的代碼
Select * From news limit 0, 100 第一頁
Select * From news limit 100,100 第二頁
Select * From news limit 200,100 第三頁
今天突然來了一個思路
和前作 上下頁查詢優化
的思路略同
定位到id值後再用id值作條件
優化的作法
第一頁
Select * From news Where id >=(Select id From news Order By id limit 0,1) limit 100
第二頁
Select * From news Where id >=(Select id From news Order By id limit 100,1) limit 100
第三頁
Select * From news Where id >=(Select id From news Order By id limit 200,1) limit 100
經測試，一萬條數據以內一般的分頁作法比較快
超過一萬條後優化過的作法優勢就呈現出來
當數據量愈多，優化的分頁查詢速度愈快
所以在第一次查詢總資料筆數後可以增加一個判決
檢查資料量是否超過一萬筆
Select count(*) AS `count` From news //製作分頁的前置作業
if($rows['count'] <10000){
$sql = "Select * From news limit 0, 100 ";
}else{
$sql = "Select * From news Where id >=( Select id From news Order By id limit 0,1) limit 100";
}
摘自:http://jian-zhoung.blogspot.com/2007/11/mysql.html
2007年12月25日 星期二
MySQL優化經驗
MySQL優化經驗
同時線上訪問量繼續增大 對於1G記憶體的伺服器明顯感覺到吃力嚴重時甚至每天都會死機 或者時不時的伺服器卡一下 這個問題曾經困擾了我半個多月MySQL使用是很具伸縮性的演算法，因此你通常能用很少的記憶體運行或給MySQL更多的被存以得到更好的性能。
安裝好mysql後，配製檔應該在/usr/local/mysql/share/mysql目錄中，配製檔有幾個，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的網站和不同配製的伺服器環境，當然需要有不同的配製檔了。
一般的情況下，my-medium.cnf這個配製檔就能滿足我們的大多需要；一般我們會把配置檔拷貝到/etc/my.cnf 只需要修改這個配置檔就可以了，使用mysqladmin variables extended-status –u root –p 可以看到目前的參數，有３個配置參數是最重要的，即key_buffer_size,query_cache_size,table_cache。
key_buffer_size只對MyISAM表起作用，
key_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤其是索引讀的速度。一般我們設為16M,實際上稍微大一點的站點 這個數字是遠遠不夠的，通過檢查狀態值Key_read_requests和Key_reads,可以知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。 或者如果你裝了phpmyadmin 可以通過伺服器運行狀態看到,筆者推薦用phpmyadmin管理mysql，以下的狀態值都是本人通過phpmyadmin獲得的實例分析:
這個伺服器已經運行了20天
比例接近1:8000 健康狀況非常好
另外一個估計key_buffer_size的辦法 把你網站資料庫的每個表的索引所占空間大小加起來看看以此伺服器為例:比較大的幾個表索引加起來大概125M 這個數字會隨著表變大而變大。
從4.0.1開始，MySQL提供了查詢緩衝機制。使用查詢緩衝，MySQL將SELECT語句和查詢結果存放在緩衝區中，今後對於同樣的SELECT語句（區分大小寫），將直接從緩衝區中讀取結果。根據MySQL用戶手冊，使用查詢緩衝最多可以達到238%的效率。
通過調節以下幾個參數可以知道query_cache_size設置得是否合理
Qcache_lowmem_prunes的值非常大，則表明經常出現緩衝不夠的情況,同時Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，此時需要增加緩衝大小Qcache_hits的值不大，則表明你的查詢重複率很低，這種情況下使用查詢緩衝反而會影響效率，那麼可以考慮不用查詢緩衝。此外，在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩衝。
Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多query_cache_type指定是否使用查詢緩衝
我設置:
得到如下狀態值:
Qcache queries in cache 12737 表明目前緩存的條數
Qcache inserts 20649006
Qcache hits 79060095 看來重複查詢率還挺高的
Qcache lowmem prunes 617913 有這麼多次出現緩存過低的情況
Qcache not cached 189896
Qcache free memory 18573912 目前剩餘緩存空間
Qcache free blocks 5328 這個數字似乎有點大 碎片不少
Qcache total blocks 30953
如果記憶體允許32M應該要往上加點
table_cache指定表快取記憶體的大小。每當MySQL訪問一個表時，如果在表緩衝區中還有空間，該表就被打開並放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發現open_tables等於table_cache，並且opened_tables在不斷增長，那麼你就需要增加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會造成檔描述符不足，從而造成性能不穩定或者連接失敗。
對於有1G記憶體的機器，推薦值是128－256。
筆者設置table_cache = 256
得到以下狀態:
雖然open_tables已經等於table_cache，但是相對於伺服器運行時間來說,已經運行了20天，opened_tables的值也非常低。因此，增加table_cache的值應該用處不大。如果運行了6個小時就出現上述值 那就要考慮增大table_cache。
如果你不需要記錄2進制log 就把這個功能關掉，注意關掉以後就不能恢復出問題前的資料了，需要您手動備份，二進位日誌包含所有更新資料的語句，其目的是在恢復資料庫時用它來把資料盡可能恢復到最後的狀態。另外，如果做同步複製( Replication )的話，也需要使用二進位日誌傳送修改情況。
log_bin指定日誌檔，如果不提供檔案名，MySQL將自己產生缺省檔案名。MySQL會在檔案名後面自動添加數位引，每次啟動服務時，都會重新生成一個新的二進位檔。此外，使用log-bin-index可以指定索引檔；使用binlog-do-db可以指定記錄的資料庫；使用binlog-ignore-db可以指定不記錄的資料庫。注意的是：binlog-do-db和binlog-ignore-db一次只指定一個資料庫，指定多個資料庫需要多個語句。而且，MySQL會將所有的資料庫名稱改成小寫，在指定資料庫時必須全部使用小寫名字，否則不會起作用。
關掉這個功能只需要在他前面加上#號
開啟慢查詢日誌( slow query log ) 慢查詢日誌對於跟蹤有問題的查詢非常有用。它記錄所有查過long_query_time的查詢，如果需要，還可以記錄不使用索引的記錄。下面是一個慢查詢日誌的例子：
開啟慢查詢日誌，需要設置參數log_slow_queries、long_query_times、log-queries-not-using-indexes。
log_slow_queries指定日誌檔，如果不提供檔案名，MySQL將自己產生缺省檔案名。long_query_times指定慢查詢的閾值，缺省是10秒。log-queries-not-using-indexes是4.1.0以後引入的參數，它指示記錄不使用索引的查詢。筆者設置long_query_time=10
筆者設置:
參數說明:
back_log
要求MySQL能有的連接數量。當主要MySQL線程在一個很短時間內得到非常多的連接請求，這就起作用，然後主線程花些時間(儘管很短)檢查連接並且啟動一個新線程。back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆疊中。只有如果期望在一個短時間內有很多連接，你需要增加它，換句話說，這值對到來的TCP/IP連接的偵聽佇列的大小。你的作業系統在這個佇列大小上有它自己的限制。 Unix listen(2)系統調用的手冊頁應該有更多的細節。檢查你的OS文檔找出這個變數的最大值。試圖設定back_log高於你的作業系統的限制將是無效的。
max_connections
併發連接數目最大，120 超過這個值就會自動恢復，出了問題能自動解決
thread_cache
沒找到具體說明，不過設置為32後 20天才創建了400多個線程 而以前一天就創建了上千個線程 所以還是有用的
thread_concurrency
代碼:
補充
優化table_cachetable_cache指定表快取記憶體的大小。每當MySQL訪問一個表時，如果在表緩衝區中還有空間，該表就被打開並放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發現open_tables等於table_cache，並且opened_tables在不斷增長，那麼你就需要增加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會造成檔描述符不足，從而造成性能不穩定或者連接失敗。對於有1G記憶體的機器，推薦值是128－256。
案例1：該案例來自一個不是特別繁忙的伺服器table_cache – 512open_tables – 103opened_tables – 1273uptime – 4021421 (measured in seconds)該案例中table_cache似乎設置得太高了。在峰值時間，打開表的數目比table_cache要少得多。
案例2：該案例來自一台開發伺服器。table_cache – 64open_tables – 64opened-tables – 431uptime – 1662790 (measured in seconds)雖然open_tables已經等於table_cache，但是相對於伺服器運行時間來說，opened_tables的值也非常低。因此，增加table_cache的值應該用處不大。案例3：該案例來自一個upderperforming的伺服器table_cache – 64open_tables – 64opened_tables – 22423uptime – 19538該案例中table_cache設置得太低了。雖然運行時間不到6小時，open_tables達到了最大值，opened_tables的值也非常高。這樣就需要增加table_cache的值。優化key_buffer_sizekey_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤其是索引讀的速度。通過檢查狀態值Key_read_requests和Key_reads，可以知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表，但是內部的臨時磁片表是MyISAM表，也要使用該值。可以使用檢查狀態值created_tmp_disk_tables得知詳情。對於1G記憶體的機器，如果不使用MyISAM表，推薦值是16M（8-64M）。
案例1：健康狀況key_buffer_size – 402649088 (384M)key_read_requests – 597579931key_reads - 56188案例2：警報狀態key_buffer_size – 16777216 (16M)key_read_requests – 597579931key_reads - 53832731案例1中比例低於1:10000，是健康的情況；案例2中比例達到1:11，警報已經拉響。
同時線上訪問量繼續增大 對於1G記憶體的伺服器明顯感覺到吃力嚴重時甚至每天都會死機 或者時不時的伺服器卡一下 這個問題曾經困擾了我半個多月MySQL使用是很具伸縮性的演算法，因此你通常能用很少的記憶體運行或給MySQL更多的被存以得到更好的性能。
安裝好mysql後，配製檔應該在/usr/local/mysql/share/mysql目錄中，配製檔有幾個，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的網站和不同配製的伺服器環境，當然需要有不同的配製檔了。
一般的情況下，my-medium.cnf這個配製檔就能滿足我們的大多需要；一般我們會把配置檔拷貝到/etc/my.cnf 只需要修改這個配置檔就可以了，使用mysqladmin variables extended-status –u root –p 可以看到目前的參數，有３個配置參數是最重要的，即key_buffer_size,query_cache_size,table_cache。
key_buffer_size只對MyISAM表起作用，
key_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤其是索引讀的速度。一般我們設為16M,實際上稍微大一點的站點 這個數字是遠遠不夠的，通過檢查狀態值Key_read_requests和Key_reads,可以知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。 或者如果你裝了phpmyadmin 可以通過伺服器運行狀態看到,筆者推薦用phpmyadmin管理mysql，以下的狀態值都是本人通過phpmyadmin獲得的實例分析:
這個伺服器已經運行了20天
key_buffer_size – 128M
key_read_requests – 650759289
key_reads - 79112 比例接近1:8000 健康狀況非常好
另外一個估計key_buffer_size的辦法 把你網站資料庫的每個表的索引所占空間大小加起來看看以此伺服器為例:比較大的幾個表索引加起來大概125M 這個數字會隨著表變大而變大。
從4.0.1開始，MySQL提供了查詢緩衝機制。使用查詢緩衝，MySQL將SELECT語句和查詢結果存放在緩衝區中，今後對於同樣的SELECT語句（區分大小寫），將直接從緩衝區中讀取結果。根據MySQL用戶手冊，使用查詢緩衝最多可以達到238%的效率。
通過調節以下幾個參數可以知道query_cache_size設置得是否合理
Qcache inserts
Qcache hits
Qcache lowmem prunes
Qcache free blocks
Qcache total blocksQcache_lowmem_prunes的值非常大，則表明經常出現緩衝不夠的情況,同時Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，此時需要增加緩衝大小Qcache_hits的值不大，則表明你的查詢重複率很低，這種情況下使用查詢緩衝反而會影響效率，那麼可以考慮不用查詢緩衝。此外，在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩衝。
Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多query_cache_type指定是否使用查詢緩衝
我設置:
query_cache_size = 32M
query_cache_type= 1 得到如下狀態值:
Qcache queries in cache 12737 表明目前緩存的條數
Qcache inserts 20649006
Qcache hits 79060095 看來重複查詢率還挺高的
Qcache lowmem prunes 617913 有這麼多次出現緩存過低的情況
Qcache not cached 189896
Qcache free memory 18573912 目前剩餘緩存空間
Qcache free blocks 5328 這個數字似乎有點大 碎片不少
Qcache total blocks 30953
如果記憶體允許32M應該要往上加點
table_cache指定表快取記憶體的大小。每當MySQL訪問一個表時，如果在表緩衝區中還有空間，該表就被打開並放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發現open_tables等於table_cache，並且opened_tables在不斷增長，那麼你就需要增加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會造成檔描述符不足，從而造成性能不穩定或者連接失敗。
對於有1G記憶體的機器，推薦值是128－256。
筆者設置table_cache = 256
得到以下狀態:
Open tables 256
Opened tables 9046 雖然open_tables已經等於table_cache，但是相對於伺服器運行時間來說,已經運行了20天，opened_tables的值也非常低。因此，增加table_cache的值應該用處不大。如果運行了6個小時就出現上述值 那就要考慮增大table_cache。
如果你不需要記錄2進制log 就把這個功能關掉，注意關掉以後就不能恢復出問題前的資料了，需要您手動備份，二進位日誌包含所有更新資料的語句，其目的是在恢復資料庫時用它來把資料盡可能恢復到最後的狀態。另外，如果做同步複製( Replication )的話，也需要使用二進位日誌傳送修改情況。
log_bin指定日誌檔，如果不提供檔案名，MySQL將自己產生缺省檔案名。MySQL會在檔案名後面自動添加數位引，每次啟動服務時，都會重新生成一個新的二進位檔。此外，使用log-bin-index可以指定索引檔；使用binlog-do-db可以指定記錄的資料庫；使用binlog-ignore-db可以指定不記錄的資料庫。注意的是：binlog-do-db和binlog-ignore-db一次只指定一個資料庫，指定多個資料庫需要多個語句。而且，MySQL會將所有的資料庫名稱改成小寫，在指定資料庫時必須全部使用小寫名字，否則不會起作用。
關掉這個功能只需要在他前面加上#號
#log-bin 開啟慢查詢日誌( slow query log ) 慢查詢日誌對於跟蹤有問題的查詢非常有用。它記錄所有查過long_query_time的查詢，如果需要，還可以記錄不使用索引的記錄。下面是一個慢查詢日誌的例子：
開啟慢查詢日誌，需要設置參數log_slow_queries、long_query_times、log-queries-not-using-indexes。
log_slow_queries指定日誌檔，如果不提供檔案名，MySQL將自己產生缺省檔案名。long_query_times指定慢查詢的閾值，缺省是10秒。log-queries-not-using-indexes是4.1.0以後引入的參數，它指示記錄不使用索引的查詢。筆者設置long_query_time=10
筆者設置:
sort_buffer_size = 1M
max_connections=120
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
interactive_timeout=120
thread_concurrency = 4 參數說明:
back_log
要求MySQL能有的連接數量。當主要MySQL線程在一個很短時間內得到非常多的連接請求，這就起作用，然後主線程花些時間(儘管很短)檢查連接並且啟動一個新線程。back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆疊中。只有如果期望在一個短時間內有很多連接，你需要增加它，換句話說，這值對到來的TCP/IP連接的偵聽佇列的大小。你的作業系統在這個佇列大小上有它自己的限制。 Unix listen(2)系統調用的手冊頁應該有更多的細節。檢查你的OS文檔找出這個變數的最大值。試圖設定back_log高於你的作業系統的限制將是無效的。
max_connections
併發連接數目最大，120 超過這個值就會自動恢復，出了問題能自動解決
thread_cache
沒找到具體說明，不過設置為32後 20天才創建了400多個線程 而以前一天就創建了上千個線程 所以還是有用的
thread_concurrency
#設置為你的cpu數目x2,例如，只有一個cpu,那麼thread_concurrency=2
#有2個cpu,那麼thread_concurrency=4
skip-innodb
#去掉innodb支持代碼:
# Example MySQL config file for medium systems.
#
# This is for a system with little memory (32M - 64M) where MySQL plays
# an important part, or systems up to 128M where MySQL is used together with
# other programs (such as a web server)
#
# You can copy this file to
# /etc/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is /var/lib/mysql) or
# ~/.my.cnf to set user-specific options.
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--help" option.
# The following options will be passed to all MySQL clients
[client]
#password = your_password
port = 3306
socket = /tmp/mysql.sock
#socket = /var/lib/mysql/mysql.sock
# Here follows entries for some specific programs
# The MySQL server
[mysqld]
port = 3306
socket = /tmp/mysql.sock
#socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 128M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
net_buffer_length = 16K
myisam_sort_buffer_size = 1M
max_connections=120
#addnew config
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
skip-innodb
skip-bdb
skip-name-resolve
join_buffer_size=512k
query_cache_size = 32M
interactive_timeout=120
long_query_time=10
log_slow_queries= /usr/local/mysql4/logs/slow_query.log
query_cache_type= 1
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4
#end new config
# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking
# Replication Master Server (default)
# binary logging is required for replication
#log-bin
# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id = 1
# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
# the syntax is:
#
# CHANGE MASTER TO MASTER_HOST=, MASTER_PORT=,
# MASTER_USER=, MASTER_PASSWORD= ;
#
# where you replace , , by quoted strings and
# by the master's port number (3306 by default).
#
# Example:
#
# CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
# MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
# start replication for the first time (even unsuccessfully, for example
# if you mistyped the password in master-password and the slave fails to
# connect), the slave will create a master.info file, and any later
# change in this file to the variables' values below will be ignored and
# overridden by the content of the master.info file, unless you shutdown
# the slave server, delete master.info and restart the slaver server.
# For that reason, you may want to leave the lines below untouched
# (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id = 2
#
# The replication master for this slave - required
#master-host =
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user =
#
# The password the slave will authenticate with when connecting to
# the master - required
#master-password =
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port =
#
# binary logging - not required for slaves, but recommended
#log-bin
# Point the following paths to different dedicated disks
#tmpdir = /tmp/
#log-update = /path-to-dedicated-directory/hostname
# Uncomment the following if you are using BDB tables
#bdb_cache_size = 4M
#bdb_max_lock = 10000
# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M
[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout補充
優化table_cachetable_cache指定表快取記憶體的大小。每當MySQL訪問一個表時，如果在表緩衝區中還有空間，該表就被打開並放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發現open_tables等於table_cache，並且opened_tables在不斷增長，那麼你就需要增加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會造成檔描述符不足，從而造成性能不穩定或者連接失敗。對於有1G記憶體的機器，推薦值是128－256。
案例1：該案例來自一個不是特別繁忙的伺服器table_cache – 512open_tables – 103opened_tables – 1273uptime – 4021421 (measured in seconds)該案例中table_cache似乎設置得太高了。在峰值時間，打開表的數目比table_cache要少得多。
案例2：該案例來自一台開發伺服器。table_cache – 64open_tables – 64opened-tables – 431uptime – 1662790 (measured in seconds)雖然open_tables已經等於table_cache，但是相對於伺服器運行時間來說，opened_tables的值也非常低。因此，增加table_cache的值應該用處不大。案例3：該案例來自一個upderperforming的伺服器table_cache – 64open_tables – 64opened_tables – 22423uptime – 19538該案例中table_cache設置得太低了。雖然運行時間不到6小時，open_tables達到了最大值，opened_tables的值也非常高。這樣就需要增加table_cache的值。優化key_buffer_sizekey_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤其是索引讀的速度。通過檢查狀態值Key_read_requests和Key_reads，可以知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表，但是內部的臨時磁片表是MyISAM表，也要使用該值。可以使用檢查狀態值created_tmp_disk_tables得知詳情。對於1G記憶體的機器，如果不使用MyISAM表，推薦值是16M（8-64M）。
案例1：健康狀況key_buffer_size – 402649088 (384M)key_read_requests – 597579931key_reads - 56188案例2：警報狀態key_buffer_size – 16777216 (16M)key_read_requests – 597579931key_reads - 53832731案例1中比例低於1:10000，是健康的情況；案例2中比例達到1:11，警報已經拉響。
訂閱：
文章 (Atom)
發表文章
