table_cache=1024
物理內存越大,設置就越大.默認為2402,調到512-1024最佳。由於每個客戶端連接都會至少訪問一個表，因此此參數的值與max_connections有關。當某一連接訪問一個表時，MySQL會檢查當前已緩存表的數量。如果該表已經在緩存中打開，則會直接訪問緩存中的表已加快查詢速度；如果該表未被緩存，則會將當前的表添加進緩存並進行查詢。在執行緩存操作之前，table_cache用於限制緩存表的最大數目：如果當前已經緩存的表未達到table_cache，則會將新表添加進來；若已經達到此值，MySQL將根據緩存表的最后查詢時間、查詢率等規則釋放之前的緩存。
innodb_additional_mem_pool_size=4M
默認為2M
innodb_thread_concurrency=8
你的服務器CPU有幾個就設置為幾,建議用默認一般為8
key_buffer_size=256M
默認為218,調到128最佳/用於緩存MyISAM表的索引塊。決定數據庫索引處理的速度（尤其是索引讀）,批定用於索引的緩沖區大小，增加它可以得到更好的索引處理性能，對於內存在4GB左右的服務器來說，該參數可設置為256MB或384MB。
tmp_table_size=64M
默認為16M,調到64-256最掛
read_buffer_size=4M
默認為64K讀查詢操作所能使用的緩沖區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。 對表進行順序掃描的請求將分配一個讀入緩沖區，MySql會為它分配一段內存緩沖區。read_buffer_size變量控制這一緩沖區的大小。如果對表的順序掃描請求非常頻繁，並且你認為頻繁掃描進行得太慢，可以通過增加該變量值以及內存緩沖區大小提高其性能。和sort_buffer_size一樣，該參數對應的分配內存也是每個連接獨享。
read_rnd_buffer_size=16M
默認為256K, MySql的隨機讀（查詢操作）緩沖區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySql會首先掃描一遍該緩沖，以避免磁盤搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但MySql會為每個客戶連接發放該緩沖空間，所以應盡量適當設置該值，以避免內存開銷過大。
sort_buffer_size=32M
默認為256KSort_Buffer_Size 並不是越大越好，由於是connection級的參數，過大的設置+高並發可能會耗盡系統內存資源。例如：500個連接將會消耗 500*sort_buffer_size(8M)=4G內存,Sort_Buffer_Size 超過2KB的時候，就會使用mmap() 而不是 malloc() 來進行內存分配，導致效率降低。
join_buffer_size = 8M
聯合查詢操作所能使用的緩沖區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。
innodb_buffer_pool_size=105M
InnoDB使用緩沖池來緩存索引和行數據。該值設置的越大，則磁盤IO越少。一般將該值設為物理內存的80%。這對Innodb表來說非常重要。Innodb相比MyISAM表對緩沖更為敏感。MyISAM可以在默認的 key_buffer_size 設置下運行的可以，然而Innodb在默認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。由於Innodb把數據和索引都緩存起來，無需留給操作系統太多的內存，因此如果只需要用Innodb的話則可以設置它高達 70-80% 的可用內存。一些應用於 key_buffer 的規則有 — 如果你的數據量不大，並且不會暴增，那么無需把 innodb_buffer_pool_size 設置的太大了
myisam_max_sort_file_size=100G
mysql重建索引時允許使用的臨時文件最大大小,MyISAM表發生變化時重新排序所需的緩沖
query_cache_size=64M
查詢緩存大小，用於緩存SELECT查詢結果。如果有許多返回相同查詢結果的SELECT查詢，並且很少改變表，可以設置query_cache_size大於0，可以極大改善查詢效率。而如果表數據頻繁變化，就不要使用這個，會適得其反.對於使用MySQL的用戶，對於這個變量大家一定不會陌生。前幾年的MyISAM引擎優化中，這個參數也是一個重要的優化參數。但隨着發展，這個參數也爆露出來一些問題。機器的內存越來越大，人們也都習慣性的把以前有用的參數分配的值越來越大。這個參數加大后也引發了一系列問題。我們首先分析一下 query_cache_size的工作原理：一個SELECT查詢在DB中工作后，DB會把該語句緩存下來，當同樣的一個SQL再次來到DB里調用時，DB在該表沒發生變化的情況下把結果從緩存中返回給Client。這里有一個關建點，就是DB在利用Query_cache工作時，要求該語句涉及的表在這段時間內沒有發生變更。那如果該表在發生變更時，Query_cache里的數據又怎么處理呢？首先要把Query_cache和該表相關的語句全部置為失效，然后在寫入更新。那么如果Query_cache非常大，該表的查詢結構又比較多，查詢語句失效也慢，一個更新或是Insert就會很慢，這樣看到的就是Update或是Insert怎么這么慢了。所以在數據庫寫入量或是更新量也比較大的系統，該參數不適合分配過大。而且在高並發，寫入量大的系統，建議把該功能禁掉。
query_cache_limit = 4M
指定單個查詢能夠使用的緩沖區大小，缺省為1M