同時在線訪問量繼續增大 對于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只對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指定是否使用查詢緩沖
我設置:
得到如下狀態值:
如果內存允許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。
