這幾天喻名堂在學習mysql數據庫的優化并在自己的服務器上進行設置，喻名堂主要學習了MyISAM和InnoDB兩種引擎的優化方法，它們各有優缺點，一般在實際應用中將兩種引擎結合起來使用效果會更好。喻名堂測試的硬件配置以及軟件環境如下： 

服務器型號：IBM S226 
CPU：至強四核 
內存：4G 
硬盤：兩個80G做RAID1 
系統：windows server 2003 SP1 32位企業版 
Mysql版本：5.5 
根據自己服務器的實際情況，優化過和參數如下： 

一、公共選項 
skip-external-locking //避免MySQL的外部鎖定，減少出錯幾率增強穩定性。 
skip-name-resolve //禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程億恩科技主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！ 
max_connections = 1024 //指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提示，則需要增大該參數值。 
query_cache_size = 16M //默認為0，就是不啟用。指定MySQL查詢緩沖區的大小?？梢酝ㄟ^在MySQL控制臺執行以下命令觀察： 
# > SHOW VARIABLES LIKE '%query_cache%'; 
# > SHOW STATUS LIKE 'Qcache%'; 
# 如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況； 
如果Qcache_hits的值非常大，則表明查詢緩沖使用非常頻繁，如果該值較小反而會影響效率，那么可以考慮不用查詢緩沖；Qcache_free_blocks，如果該值非常大，則表明緩沖區中碎片很多。 
sort_buffer_size = 6M //每個線程的排序緩存大小，該選項對排序order by、group by起作用。注意：該參數對應的分配內存是每連接獨占！如果有100個連接，那么實際分配的總共排序緩沖區大小為100 × 6 ＝ 600MB。所以，對于內存在4GB左右的服務器推薦設置為6-8M。 
record_buffer=16M //每個進行一個順序掃描的線程為其掃描的每張表分配這個大小的一個緩沖區，可以設置為2M以上 
table_cache = 512 //為所有線程打開表的數量。增加該值能增加mysqld要求的文件描述符的數量。Mysql對每個唯一打開的表需要2個文件描述符。 

二、MyISAM選項 
key_buffer_size = 256M //key_buffer_size指定用于索引的緩沖區大小，增加它可得到更好的索引處理性能。對于內存在4GB左右的服務器該參數可設置為256M或384M。 
注意：該參數值設置的過大反而會是服務器整體效率降低！ 
read_buffer_size = 4M //讀查詢操作所能使用的緩沖區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！ 
myisam_sort_buffer_size = 64M //默認為16M。設置、恢復、修改表的時候使用的緩沖大小，值不要設的太大。 
join_buffer_size = 8M //聯合查詢操作所能使用的緩沖區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！ 

三、InnoDB選項 
innodb_buffer_pool_size＝1G //一個Innodb最重要的參數，這個參數和MyISAM的key_buffer_size有相似之處，但也是有差別的。這個參數主要緩存innodb表的索引，數據，插入數據時的緩沖，設置得越大，存取表里面數據時所需要的磁盤I/O越少，一般是內存的一半，不超過2G，否則系統會崩潰。為Innodb加速優化首要參數。該參數分配內存的原則：這個參數默認分配只有8M，可以說是非常小的一個值。如果是一個專用ＤＢ服務器，那么他可以占到內存的70%-80%。這個參數不能動態更改，所以分配需多考慮。分配過大，會使Swap占用過多，致使Mysql的查詢特慢。如果你的數據比較小，那么可分配是你的數據大小＋１０％左右做為這個參數的值。 

例如：數據大小為50Ｍ,那么給這個值分配innodb_buffer_pool_size＝64Ｍ 
innodb_additional_mem_pool_size=16M //用來存放Innodb的內部目錄這個值不用分配太大，系統可以自動調。不用設置太高。通常比較大數據設置16Ｍ夠用了，如果表比較多，可以適當的增大。如果這個值自動增加，會在error log有中顯示的。 

innodb_log_file_size=256M //在日志組中每個日志文件的大小，一般是innodb_buffer_pool_size的25%，官方推薦是innodb_buffer_pool_size的40-50%。一般控制在幾個ＬＯＧ文件相加大小在２Ｇ以內為佳。具體情況還需要看你的事務大小，數據大小為依據。說明：這個值分配的大小和數據庫的寫入速度，事務大小，異常重啟后的恢復有很大的關系。 

innodb_log_files_in_group=2 //指定你有幾個日志組。分配原則：一般我們可以用２－３個日值組。默認為兩個。 

innodb_log_buffer_size＝3M //事務在內存中的緩沖。分配原則：控制在2-8M.這個值不用太多的。他里面的內存一般一秒鐘寫到磁盤一次。具體寫入方式和你的事務提交方式有關。在oracle等數據庫了解這個，一般最大指定為３Ｍ比較合適。 

innodb_flush_logs_at_trx_commit＝0 //控制事務的提交方式分配原則：這個參數只有３個值，０，１，２請確認一下自已能接受的級別。默認為１，主庫請不要更改了。性能更高的可以設置為０或是２，但會丟失一秒鐘的事務。說明：這個參數的設置對Ｉｎｎｏｄｂ的性能有很大的影響，所以在這里給多說明一下。當這個值為1時：innodb 的事務LOG在每次提交后寫入日值文件，并對日值做刷新到磁盤。這個可以做到不丟任何一個事務。當這個值為2時：在每個提交，日志緩沖被寫到文件，但不對日志文件做到磁盤操作的刷新,在對日志文件的刷新在值為2的情況也每秒發生一次。但需要注意的是，由于進程調用方面的問題，并不能保證每秒１００％的發生。從而在性能上是最快的。但操作系統崩潰或掉電才會刪除最后一秒的事務。當這個值為0時：日志緩沖每秒一次地被寫到日志文件，并且對日志文件做到磁盤操作的刷新，但是在一個事務提交不做任何操作。mysqld進程的崩潰會刪除崩潰前最后一秒的事務。 

從以上分析，當這個值不為１時，可以取得較好的性能，但遇到異常會有損失，所以需要根據自已的情況去衡量。