- 性能參數配置之前的介紹
打開mysql的命令窗口。開始->所有程序->MySql->Mysql Server 5.0-> mysql command line client。優化配置參數，首先要了解當前的配置參數以及運行情況。
查看系統參數配置，輸入命令：
- mysql>show variables;(查看所以參數配置)
- mysql>show variables like ‘%variableName%’;查詢某條或某些條包含variableName的參數。
運行下列命令可以獲取狀態變量的值： - mysql> SHOW STATUS;
- mysql> SHOW STATUS LIKE ‘[匹配模式]’; ( 可以使用%、?等 ) 如果只要檢查某幾個狀態變量，可以使用下列命令：
運行類似一下命令可以修改服務器參數配置： - set global variableName=….;
例如：set global table_cache=256;
性能參數的配置：
- back_log：（處於Advanced標籤下，Various組下）
要求 MySQL 能有的連接數量。當主要MySQL線程在一個很短時間內得到非常多的連接請求，這就起作用，然後主線程花些時間(儘管很短)檢查連接並且啓動一個新線程。
back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。只有如果期望在一個短時間內有很多連接，你需要增加它，換句話說，這值對到來的TCP/IP連接的偵聽隊列的大小。你的操作系統在這個隊列大小上有它自己的限制。 試圖設定back_log高於你的操作系統的限制將是無效的。
當你觀察你的主機進程列表，發現大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待連接進程時，就要加大 back_log 的值了。默認數值是50，我把它改爲500。 - interactive_timeout：
服務器在關閉它前在一個交互連接上等待行動的秒數。一個交互的客戶被定義爲對 mysql_real_connect()使用 CLIENT_INTERACTIVE 選項的客戶。 默認數值是28800，我把它改爲7200。 - key_buffer_size：
索引塊是緩衝的並且被所有的線程共享。決定索引處理的速度，尤其是索引讀的速度。key_buffer_size是用於索引塊的緩衝區大小，增加它可得到更好處理的索引(對所有讀和多重寫)，到你能負擔得起那樣多。如果你使它太大，系統將開始換頁並且真的變慢了。默認數值是8388600(8M)，我的MySQL主機有2GB內存，因爲我們的數據庫中沒有使用到MyIsAm類型的表，所以建議設爲16M（8-64M），通過檢查狀態值Key_read_requests和Key_reads，可以知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該儘可能的低，至少是1:100，1:1000更好（上述狀態值可以使用’key_read%’獲得用來顯示狀態數據）。key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表，但是內部的臨時磁盤表是MyISAM表，也要使用該值。 - max_connections：
允許的同時客戶的數量。增加該值增加 mysqld 要求的文件描述符的數量。這個數字應該增加，否則，你將經常看到 Too many connections 錯誤。 默認數值是100，我把它改爲1024 。 - record_buffer：
每個進行一個順序掃描的線程爲其掃描的每張表分配這個大小的一個緩衝區。如果你做很多順序掃描，你可能想要增加該值。默認數值是131072(128K)，我把它改爲16773120 (16M)。 - sort_buffer：
每個需要進行排序的線程分配該大小的一個緩衝區。增加這值加速ORDER BY或GROUP BY操作。默認數值是2097144(2M)，我把它改爲 16777208 (16M)。 table_cache：
table_cache指定表高速緩存的大小。每當MySQL訪問一個表時，如果在表緩衝區中還有空間，該表就被打開並放入其中，這樣可以更快地訪問表內容。通過檢查峯值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發現open_tables等於table_cache，並且opened_tables在不斷增長，那麼你就需要增加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會造成文件描述符不足，從而造成性能不穩定或者連接失敗。默認數值是64，我把它改爲512。thread_cache_size：
可以複用的保存在緩存中的線程的數量。如果有，新的線程從緩存中取得，當斷開連接的時候如果有空間，客戶的線置在緩存中。如果有很多新的線程，爲了提高性能可以這個變量值。通過比較 Connections 和 Threads_created 狀態的變量，可以看到這個變量的作用。我把它設置爲 80。（set global thread_cache_size=80;）- wait_timeout：
服務器在關閉它之前在一個連接上等待行動的秒數。默認數值是28800，我把它改爲7200。 - max_connections
是指MySql的最大連接數，如果服務器的併發連接請求量比較大，建議調高此值，以增加並行連接數量，當然這建立在機器能支撐的情況下，因爲如果連接數越多，介於MySql會爲每個連接提供連接緩衝區，就會開銷越多的內存，所以要適當調整該值，不能盲目提高設值。可以過’conn%’通配符查看當前狀態的連接數量，以定奪該值的大小。 - innodb_buffer_pool_size
對於InnoDB表來說，作用就相當於key_buffer_size對於MyISAM表的作用一樣。InnoDB使用該參數指定大小的內存來緩衝數據和索引。對於單獨的MySQL數據庫服務器，可以把該值設置成物理內存的80%，但不要超過80%。如果數據量比較小也不怎麼增加，那麼不要把這個值設太高也可以提高內存的使用率。由於我們的數據庫表都是InnoDB類型，我設置成75%;根據MySQL手冊，對於2G內存的機器，推薦值是1G（50%）。 - query_cache_size
是MySql的查詢緩衝大小。（從4.0.1開始，MySQL提供了查詢緩衝機制）使用查詢緩衝，MySQL將SELECT語句和查詢結果存放在緩衝區中，今後對於同樣的SELECT語句（區分大小寫），將直接從緩衝區中讀取結果。根據MySQL用戶手冊，使用查詢緩衝最多可以達到238%的效率。通過檢查狀態值’Qcache_%’，可以知道query_cache_size設置是否合理：如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩衝不夠的情況，如果Qcache_hits的值也非常大，則表明查詢緩衝使用非常頻繁，此時需要增加緩衝大小；如果Qcache_hits的值不大，則表明你的查詢重複率很低，這種情況下使用查詢緩衝反而會影響效率，那麼可以考慮不用查詢緩衝。此外，在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩衝。 - read_buffer_size
是MySql讀入緩衝區大小。對錶進行順序掃描的請求將分配一個讀入緩衝區，MySql會爲它分配一段內存緩衝區。read_buffer_size變量控制這一緩衝區的大小。如果對錶的順序掃描請求非常頻繁，並且你認爲頻繁掃描進行得太慢，可以通過增加該變量值以及內存緩衝區大小提高其性能。 - innodb_log_file_size
對於寫很多尤其是大數據量時非常重要。要注意，大的文件提供更高的性能，但數據庫恢復時會用更多的時間。根據MySQL手冊，推薦值是innodb_buffer_pool_size的25%。我一般用64M-512M，具體取決於服務器的空間。 - innodb_flush_log_at_trx_commit
默認值1的意思是每一次事務提交或事務外的指令都需要把日誌寫入（flush）硬盤，這是很費時的。設成2對於很多運用，特別是從MyISAM錶轉過來的是可以的，它的意思是不寫入硬盤而是寫入系統緩存。日誌仍然會每秒flush到硬盤，所以你一般不會丟失超過1-2秒的更新。設成0會更快一點，但安全方面比較差，即使MySQL掛了也可能會丟失事務的數據。而值2只會在整個操作系統掛了時纔可能丟數據。實際測試發現，該值對插入數據的速度影響非常大，設置爲2時插入10000條記錄只需要2秒，設置爲0時只需要1秒，而設置爲1時則需要229秒。因此，根據MySQL手冊，我都儘量將插入操作合併成一個事務，這樣可以大幅提高速度。 - innodb_additional_mem_pool_size
該參數指定InnoDB用來存儲數據字典和其他內部數據結構的內存池大小。缺省值是1M。通常不用太大，只要夠用就行，應該與表結構的複雜度有關係。如果不夠用，MySQL會在錯誤日誌中寫入一條警告信息。 根據MySQL手冊，對於2G內存的機器，推薦值是20M。
注：這是一個比較謹慎的工作，上面的結果也僅僅是我的一些看法，你可以根據你自己主機的硬件情況（特別是內存大小）進一步修改。使用MySql數據庫存儲大量數據（或使用複雜查詢）時，我們應該考慮MySql的內存配置。如果配置MySQL服務器使用太少的內存會導致性能不是最優的；如果配置了太多的內存則會導致崩潰，無法執行查詢或者導致交換操作嚴重變慢。在現在的32位平臺下，仍有可能把所有的地址空間都用完，因此需要審視
- back_log：（處於Advanced標籤下，Various組下）
