查看MySql狀態及變量的方法：

Mysql>?show status?——顯示狀態信息（擴展show status like 'XXX'）

Mysql>?show variables?——顯示系統變量（擴展show variables like 'XXX'）

Mysql>?show innodb status?——顯示InnoDB存儲引擎的狀態

Shell> mysqladmin variables -u username -p password——顯示系統變量

Shell> mysqladmin extended-status -u username -p password——顯示狀態信息

查看狀態變量及幫助：

Shell> mysqld --verbose --help [|more #逐行顯示]

首先，讓我們看看有關請求連接的變量：

為了能適應更多數據庫應用用戶，MySql提供了連接（客戶端）變量，以對不同性質的用戶群體提供不同的解決方案，筆者就max_connections，back_log?做了一些細結，如下：

max_connections?是指MySql的最大連接數，如果服務器的并發連接請求量比較大，建議調高此值，以增加并行連接數量，當然這建立在機器能支撐的情況下，因為如果連接數越多，介于MySql會為每個連接提供連接緩沖區，就會開銷越多的內存，所以要適當調整該值，不能盲目提高設值。可以過'conn%'通配符查看當前狀態的連接數量，以定奪該值的大小。

back_log?是要求MySQL能有的連接數量。當主要MySQL線程在一個很短時間內得到非常多的連接請求，這就起作用，然后主線程花些時間(盡管很短)檢查連接并且啟動一個新線程。back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。如果期望在一個短時間內有很多連接，你需要增加它。也就是說，如果MySql的連接數據達到max_connections時，新來的請求將會被存在堆棧中，以等待某一連接釋放資源，該堆棧的數量即back_log，如果等待連接的數量超過back_log，將不被授予連接資源。另外，這值（back_log）限于您的操作系統對到來的TCP/IP連接的偵聽隊列的大小。你的操作系統在這個隊列大小上有它自己的限制（可以檢查你的OS文檔找出這個變量的最大值），試圖設定back_log高于你的操作系統的限制將是無效的。

優化了MySql的連接后屬性后，我們需要看看緩沖區變量：

使用MySql數據庫存儲大量數據（或使用復雜查詢）時，我們應該考慮MySql的內存配置。如果配置MySQL服務器使用太少的內存會導致性能不是最優的；如果配置了太多的內存則會導致崩潰，無法執行查詢或者導致交換操作嚴重變慢。在現在的32位平臺下，仍有可能把所有的地址空間都用完，因此需要審視。

計算內存使用的秘訣公式就能相對地解決這一部分問題。不過，如今這個公式已經很復雜了，更重要的是，通過它計算得到的值只是“理論可能”并不是真正消耗的值。事實上，有8GB內存的常規服務器經常能運行到最大的理論值（100GB甚至更高）。此外，你輕易不會使用到“超額因素”（它實際上依賴于應用以及配置）。一些應用可能需要理論內存的10%而有些僅需1%。
那么，我們可以做什么呢？

來看看那些在啟動時就需要分配并且總是存在的全局緩沖吧！

全局緩沖：
key_buffer_size, innodb_buffer_pool_size, innodb_additional_mem_pool_size，innodb_log_buffer_size, query_cache_size

注：如果你大量地使用MyISAM表，那么你也可以增加操作系統的緩存空間使得MySQL也能用得著。把這些也都加到操作系統和應用程序所需的內存值之中，可能需要增加32MB甚至更多的內存給MySQL服務器代碼以及各種不同的小靜態緩沖。這些就是你需要考慮的在MySQL服務器啟動時所需的內存。其他剩下的內存用于連接。

key_buffer_size?決定索引處理的速度，尤其是索引讀的速度。一般我們設為16M，通過檢查狀態值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表，也要使用該值。可以使用檢查狀態值'created_tmp_disk_tables'得知詳情。

innodb_buffer_pool_size?對于InnoDB表來說，作用就相當于key_buffer_size對于MyISAM表的作用一樣。InnoDB使用該參數指定大小的內存來緩沖數據和索引。對于單獨的MySQL數據庫服務器，最大可以把該值設置成物理內存的80%。

innodb_additional_mem_pool_size?指定InnoDB用來存儲數據字典和其他內部數據結構的內存池大小。缺省值是1M。通常不用太大，只要夠用就行，應該與表結構的復雜度有關系。如果不夠用，MySQL會在錯誤日志中寫入一條警告信息。

innodb_log_buffer_size?指定InnoDB用來存儲日志數據的緩存大小，如果您的表操作中包含大量并發事務（或大規模事務），并且在事務提交前要求記錄日志文件，請盡量調高此項值，以提高日志效率。

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可以明確表示不使用查詢緩沖。

除了全局緩沖，MySql還會為每個連接發放連接緩沖。

連接緩沖：
每個連接到MySQL服務器的線程都需要有自己的緩沖。大概需要立刻分配256K，甚至在線程空閑時，它們使用默認的線程堆棧，網絡緩存等。事務開始之后，則需要增加更多的空間。運行較小的查詢可能僅給指定的線程增加少量的內存消耗，然而如果對數據表做復雜的操作例如掃描、排序或者需要臨時表，則需分配大約read_buffer_size，sort_buffer_size，read_rnd_buffer_size，tmp_table_size?大小的內存空間。不過它們只是在需要的時候才分配，并且在那些操作做完之后就釋放了。有的是立刻分配成單獨的組塊。tmp_table_size 可能高達MySQL所能分配給這個操作的最大內存空間了。注意，這里需要考慮的不只有一點 —— 可能會分配多個同一種類型的緩存，例如用來處理子查詢。一些特殊的查詢的內存使用量可能更大——如果在MyISAM表上做成批的插入時需要分配 bulk_insert_buffer_size 大小的內存；執行 ALTER TABLE， OPTIMIZE TABLE， REPAIR TABLE 命令時需要分配 myisam_sort_buffer_size 大小的內存。

read_buffer_size?是MySql讀入緩沖區大小。對表進行順序掃描的請求將分配一個讀入緩沖區，MySql會為它分配一段內存緩沖區。read_buffer_size變量控制這一緩沖區的大小。如果對表的順序掃描請求非常頻繁，并且你認為頻繁掃描進行得太慢，可以通過增加該變量值以及內存緩沖區大小提高其性能。

sort_buffer_size?是MySql執行排序使用的緩沖大小。如果想要增加ORDER BY的速度，首先看是否可以讓MySQL使用索引而不是額外的排序階段。如果不能，可以嘗試增加sort_buffer_size變量的大小。

read_rnd_buffer_size?是MySql的隨機讀緩沖區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySql會首先掃描一遍該緩沖，以避免磁盤搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但MySql會為每個客戶連接發放該緩沖空間，所以應盡量適當設置該值，以避免內存開銷過大。

tmp_table_size是MySql的heap?（堆積）表緩沖大小。所有聯合在一個DML指令內完成，并且大多數聯合甚至可以不用臨時表即可以完成。大多數臨時表是基于內存的(HEAP)表。具有大的記錄長度的臨時表 (所有列的長度的和)或包含BLOB列的表存儲在硬盤上。如果某個內部heap（堆積）表大小超過tmp_table_size，MySQL可以根據需要自動將內存中的heap表改為基于硬盤的MyISAM表。還可以通過設置tmp_table_size選項來增加臨時表的大小。也就是說，如果調高該值，MySql同時將增加heap表的大小，可達到提高聯接查詢速度的效果。

當我們設置好了緩沖區大小之后，再來看看：

table_cache?所有線程打開的表的數目，增大該值可以增加mysqld需要的文件描述符的數量。每當MySQL訪問一個表時，如果在表緩沖區中還有空間，該表就被打開并放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值’Open_tables’和’Opened_tables’，可以決定是否需要增加table_cache的值。如果你發現open_tables等于table_cache，并且opened_tables在不斷增長，那么你就需要增加table_cache的值了（上述狀態值可以使用’Open%tables’獲得）。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會造成文件描述符不足，從而造成性能不穩定或者連接失敗。

做了以上方面的調優設置之后，MySql應該基本能滿足您需求（當然是建立在調優設置適當的情況下），我們還應該了解并注意：

只有簡單查詢OLTP（聯機事務處理）應用的內存消耗經常是使用默認緩沖的每個線程小于1MB，除非需要使用復雜的查詢否則無需增加每個線程的緩沖大小。使用1MB的緩沖來對10行記錄進行排序和用16MB的緩沖基本是一樣快的（實際上16MB可能會更慢，不過這是其他方面的事了）。

找出MySQL服務器內存消耗的峰值。這很容易就能計算出操作系統所需的內存、文件緩存以及其他應用。在32位環境下，還需要考慮到32位的限制，限制 “mysqld” 的值大約為2.5G（實際上還要考慮到很多其他因素）。現在運行 “ps aux” 命令來查看 “VSZ” 的值（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 blocks

Qcache_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 – 512

open_tables – 103

opened_tables – 1273

uptime – 4021421 (measured in seconds)

該案例中table_cache似乎設置得太高了。在峰值時間，打開表的數目比table_cache要少得多。

案例2：該案例來自一臺開發服務器。

table_cache – 64

open_tables – 64

opened-tables – 431

uptime – 1662790 (measured in seconds)

雖然open_tables已經等于table_cache，但是相對于服務器運行時間來說，opened_tables的值也非常低。因此，增加table_cache的值應該用處不大。

案例3：該案例來自一個upderperforming的服務器

table_cache – 64

open_tables – 64

opened_tables – 22423

uptime – 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 – 597579931

key_reads - 56188

案例2：警報狀態

key_buffer_size – 16777216 (16M)

key_read_requests – 597579931

key_reads - 53832731

案例1中比例低于1:10000，是健康的情況；案例2中比例達到1:11，警報已經拉響。

本文轉自 chengxuyonghu 51CTO博客，原文鏈接：http://blog.51cto.com/6226001001/1567604，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的MySQL数据库服务器优化详细的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。