MySQL配置文件my.cnf中文詳解，附mysql性能優化方法分享

=================================================================================================

Mysql參數優化對于新手來講，是比較難懂的東西，其實這個參數優化，是個很復雜的東西，對于不同的網站，及其在線量，訪問量，帖子數量，網絡情況，以及機器硬件配置都有關系，優化不可能一次性完成，需要不斷的觀察以及調試，才有可能得到最佳效果。

下面先說我的服務器的硬件以及論壇情況，
CPU: 2顆四核Intel Xeon 2.00GHz
內存: 4GB DDR
硬盤: SCSI 146GB
論壇：在線會員 一般在 5000 人左右 – 最高記錄是 13264.
下面，我們根據以上硬件配置結合一份已經做過一次優化的my.cnf進行分析說明：有些參數可能還得根據論壇的變化情況以及程序員的程序進行再調整。
[mysqld]
port?= 3306
serverid?= 1
socket?= /tmp/mysql.sock
skip-locking?# 避免MySQL的外部鎖定，減少出錯幾率增強穩定性。

?skip-name-resolve

禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求!
back_log = 500
要求 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。
key_buffer_size?= 384M
# key_buffer_size指定用于索引的緩沖區大小，增加它可得到更好處理的索引(對所有讀和多重寫)，到你能負擔得起那樣多。如果你使它太大，系統將開始換頁并且真的變慢了。對于內存在4GB左右的服務器該參數可設置為384M或512M。通過檢查狀態值Key_read_requests和 Key_reads,可以知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好(上述狀態值可以使用SHOW STATUS LIKE ‘key_read%'獲得)。注意：該參數值設置的過大反而會是服務器整體效率降低!
max_allowed_packet?= 32M
增加該變量的值十分安全，這是因為僅當需要時才會分配額外內存。例如，僅當你發出長查詢或mysqld必須返回大的結果行時mysqld才會分配更多內存。該變量之所以取較小默認值是一種預防措施，以捕獲客戶端和服務器之間的錯誤信息包，并確保不會因偶然使用大的信息包而導致內存溢出。
table_cache?= 512（5.1之后叫做table_open_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設置成很大的值。如果設置得太高，可能會造成文件描述符不足，從而造成性能不穩定或者連接失敗。
sort_buffer_size?= 4M
查詢排序時所能使用的緩沖區大小。注意：該參數對應的分配內存是每連接獨占!如果有100個連接，那么實際分配的總共排序緩沖區大小為100 × 4 = 400MB。所以，對于內存在4GB左右的服務器推薦設置為4-8M。
read_buffer_size?= 4M
讀查詢操作所能使用的緩沖區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享!
join_buffer_size?= 8M
聯合查詢操作所能使用的緩沖區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享!
myisam_sort_buffer_size?= 64M
MyISAM表發生變化時重新排序所需的緩沖
query_cache_size?= 64M
指定MySQL查詢緩沖區的大小。可以通過在MySQL控制臺執行以下命令觀察：
# > SHOW VARIABLES LIKE ‘%query_cache%'; # > SHOW STATUS LIKE ‘Qcache%'; # 如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況;
如果Qcache_hits的值非常大，則表明查詢緩沖使用非常頻繁，如果該值較小反而會影響效率，那么可以考慮不用查詢緩沖;Qcache_free_blocks，如果該值非常大，則表明緩沖區中碎片很多。
thread_cache_size?= 64
可以復用的保存在中的線程的數量。如果有，新的線程從緩存中取得，當斷開連接的時候如果有空間，客戶的線置在緩存中。如果有很多新的線程，為了提高性能可以提高這個變量值。通過比較 Connections 和 Threads_created 狀態的變量，可以看到這個變量的作用
tmp_table_size?= 256M
max_connections?= 1000
指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提示，則需要增大該參數值。
max_connect_errors = 10000000
對于同一主機，如果有超出該參數值個數的中斷錯誤連接，則該主機將被禁止連接。如需對該主機進行解禁，執行：FLUSH HOST;。
wait_timeout?= 10
指定一個請求的最大連接時間，對于4GB左右內存的服務器可以設置為5-10。
thread_concurrency?= 8
該參數取值為服務器邏輯CPU數量×2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持H.T超線程，所以實際取值為4 × 2 = 8
skip-networking
開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項!否則將無法正常連接!
long_query_time?= 10
log-slow-queries?=
log-queries-not-using-indexes
開啟慢查詢日志( 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
外附上使用show status命令查看mysql狀態相關的值及其含義：
使用show status命令
含義如下:
aborted_clients 客戶端非法中斷連接次數
aborted_connects 連接mysql失敗次數
com_xxx xxx命令執行次數,有很多條
connections 連接mysql的數量
Created_tmp_disk_tables 在磁盤上創建的臨時表
Created_tmp_tables 在內存里創建的臨時表
Created_tmp_files 臨時文件數
Key_read_requests The number of requests to read a key block from the cache
Key_reads The number of physical reads of a key block from disk
Max_used_connections 同時使用的連接數
Open_tables 開放的表
Open_files 開放的文件
Opened_tables 打開的表
Questions 提交到server的查詢數
Sort_merge_passes 如果這個值很大,應該增加my.cnf中的sort_buffer值
Uptime 服務器已經工作的秒數
提升性能的建議:
1.如果opened_tables太大,應該把my.cnf中的table_cache變大

2.如果Key_reads太大,則應該把my.cnf中key_buffer_size變大.可以用Key_reads/Key_read_requests計算出cache失敗率

3.如果Handler_read_rnd太大,則你寫的SQL語句里很多查詢都是要掃描整個表,而沒有發揮索引的鍵的作用

4.如果Threads_created太大,就要增加my.cnf中thread_cache_size的值.可以用Threads_created/Connections計算cache命中率

5.如果Created_tmp_disk_tables太大,就要增加my.cnf中tmp_table_size的值,用基于內存的臨時表代替基于磁盤的

==========================================================================================================
存儲引擎是什么？MySQL中的數據用各種不同的技術存儲在文件(或者內 正確的編譯方法固然重要，但它只是提高MySQL服務器性能工作的一部分。MySQL服務器的許多參數會影響服務器的性能表現，而且我們可以把這些參數保存到配置文件，使得每次MySQL服務器啟動時這些參數都自動發揮作用。這個配置文件就是my.cnf。
MySQL服務器提供了my.cnf文件的幾個示例，它們可以在/usr/local/mysql/share/mysql/目錄下找到，名字分別為 my-small.cnf、my-medium.cnf、my-large.cnf以及my-huge.cnf。文件名字中關于規模的說明描述了該配置文件適用的系統類型。例如，如果運行MySQL服務器的系統內存不多，而且MySQL只是偶爾使用，那么使用my-small.cnf配置文件最為理想，這個配置文件告訴mysqld daemon使用最少的系統資源。反之，如果MySQL服務器用于支持一個大規模的在線商場，系統擁有2G的內存，那么使用mysql-huge.cnf 最為合適。
要使用上述示例配置文件，我們應該先復制一個最適合要求的配置文件，并把它命名為my.cnf。這個復制得到的配置文件可以按照如下三種方式使用：
全局：把這個my.cnf文件復制到服務器的/etc目錄，此時文件中所定義的參數將全局有效，即對該服務器上運行的所有MySQL數據庫服務器都有效。
局部：把這個my.cnf文件復制到[MYSQL-INSTALL-DIR]/var/將使該文件只對指定的服務器有效，其中[MYSQL-INSTALL-DIR]表示安裝MySQL的目錄。
用戶：最后，我們還可以把該文件的作用范圍局限到指定的用戶，這只需把my.cnf文件復制到用戶的根目錄即可。
那么，如何設置my.cnf文件中的參數呢？或者進一步說，哪些參數是我們可以設置的呢？所有這些參數都對MySQL服務器有著全局性的影響，但同時每一個參數都和MySQL的特定部分關系較為密切。例如，max_connections參數屬于mysqld一類。那么，如何才能得知這一點呢？這只需執行如下命令：

% >/usr/local/mysql/libexec/mysqld –help
該命令將顯示出和mysqld有關的各種選項和參數。要尋找這些參數非常方便，因為這些參數都在“Possible variables for option –set-variable (-O) are”這行內容的后面。找到這些參數之后，我們就可以在my.cnf文件中按照如下方式設置所有這些參數：

set-variable = max_connections=100

這行代碼的效果是：同時連接MySQL服務器的最大連接數量限制為100。不要忘了在my.cnf文件[mysqld]小節加上一個set-variable指令，具體請參見配置文件中的示例。

MySQL的max_connections參數用來設置最大連接（用戶）數。每個連接MySQL的用戶均算作一個連接，max_connections的默認值為100。本文將講解此參數的詳細作用與性能影響。

[max_connections]

=================================================================================================

MySQL無論如何都會保留一個用于管理員（SUPER）登陸的連接，用于管理員連接數據庫進行維護操作，即使當前連接數已經達到了max_connections。因此MySQL的實際最大可連接數為max_connections+1；
這個參數實際起作用的最大值（實際最大可連接數）為16384，即該參數最大值不能超過16384，即使超過也以16384為準；
增加max_connections參數的值，不會占用太多系統資源。系統資源（CPU、內存）的占用主要取決于查詢的密度、效率等；
該參數設置過小的最明顯特征是出現”Too many connections”錯誤；

我們先來看下如何查看當前mysql的max_connections的值：

如下sql

復制代碼代碼如下:
show variables like "max_connections";

?

顯示的結果如下格式

+-----------------+-------+
| Variable_name?? | Value |
+-----------------+-------+
| max_connections | 100?? |
+-----------------+-------+

可以通過下面的sql語句將max_connections的值設置為200，當然前提是當前登錄的用戶有足夠的權限：

set global max_connections = 200;

這個設置會馬上生效，但是當mysql重啟時這個設置會失效，更好的辦法是修改mysql的ini配置文件my.ini

找到mysqld塊，修改或者添加下面的設置：

max_connections=200

這樣修改之后，即便重啟mysql也會默認載入這個配置了

?不過為了安全期間，建議大家直接到my.ini里修改，么有可以加上。

調整max_connections參數的值

調整此參數的方法有幾種，既可以在編譯的時候設置，也可以在MySQL配置文件 my.cnf 中設置，也可以直接使用命令調整并立即生效。

1、在編譯的時候設置默認最大連接數

打開MySQL的源碼，進入sql目錄，修改mysqld.cc文件：

復制代碼代碼如下:
{"max_connections", OPT_MAX_CONNECTIONS,
"The number of simultaneous clients allowed.", (gptr*) &max_connections,
(gptr*) &max_connections, 0, GET_ULONG, REQUIRED_ARG, 100, 1, 16384, 0, 1,
0},

紅色的”100″即為該參數的默認值，修改為想要的數值，存盤退出。然后執行

復制代碼代碼如下:
./configure;make;make install

重新編譯安裝MySQL；注意，由于編譯安裝且修改了MySQL源碼，此操作最好在安裝MySQL之前進行；

?

2、在配置文件my.cnf中設置max_connections的值

打開MySQL配置文件my.cnf

復制代碼代碼如下:
[root@www ~]# vi /etc/my.cnf

找到max_connections一行，修改為（如果沒有，則自己添加），

復制代碼代碼如下:
max_connections = 1000

上面的1000即該參數的值。

?

3、實時（臨時）修改此參數的值

首先登陸mysql，執行如下命令：

復制代碼代碼如下:
[root@www ~]# mysql -uroot -p

然后輸入MySQL Root的密碼。

?

查看當前的Max_connections參數值：

復制代碼代碼如下:
mysql> SELECT @@MAX_CONNECTIONS AS 'Max Connections';

設置該參數的值：

復制代碼代碼如下:
mysql> set GLOBAL max_connections=1000;

（注意上面命令的大小寫）

?

修改完成后實時生效，無需重啟MySQL。

總體來說，該參數在服務器資源夠用的情況下應該盡量設置大，以滿足多個客戶端同時連接的需求。否則將會出現類似”Too many connections”的錯誤。

?

【THREAD_CACHE】

=================================================================================================

MySQL里面為了提高客戶端請求創建連接過程的性能,提供了一個連接池也就是 Thread_Cache池,將空閑的連接線程放在連接池中,而不是立即銷毀.這樣的好處就是,當又有一個新的請求的時候,mysql不會立即去創建連接 線程,而是先去Thread_Cache中去查找空閑的連接線程,如果存在則直接使用,不存在才創建新的連接線程.

有關Thread_Cache在MySQL有幾個重要的參數,簡單介紹如下:

thread_cache_size

Thread_Cache 中存放的最大連接線程數.在短連接的應用中Thread_Cache的功效非常明顯,因為在應用中數據庫的連接和創建是非常頻繁的,如果不使用 Thread_Cache那么消耗的資源是非常可觀的!在長連接中雖然帶來的改善沒有短連接的那么明顯,但是好處是顯而易見的.但并不是越大越好大了反而 浪費資源這個的確定一般認為和物理內存有一定關系,如下:

復制代碼代碼如下:
1G —> 8
2G —> 16
3G —> 32
>3G —> 64

如果短連接多的話可以適當加大.

?

thread_stack

每個連接被創建的時候,mysql分配給它的內存.這個值一般認為默認就可以應用于大部分場景了,除非必要非則不要動它.

thread_handing

運用Thread_Cache處理連接的方式,5.1.19添加的新特性.有兩個值可選[no-threads|one-thread-per-connection] 看字面意思大家也該猜出八九分了,呵呵,no-threads 服務器使用一個線程,one-thread-per-connection 服務器為每個客戶端請求使用一個線程.原手冊中提到,no-threads是在Linux下調試用的.

復制代碼代碼如下:
mysql> show variables like 'thread%';
+——————-+—————————+
| Variable_name???? | Value???????????????????? |
+——————-+—————————+
| thread_cache_size | 32??????????????????????? |
| thread_handling?? | one-thread-per-connection |
| thread_stack????? | 196608??????????????????? |
+——————-+—————————+
3 rows in set (0.01 sec)

?

mysql> show status like '%connections%';
+———————-+——–+
| Variable_name??????? | Value? |
+———————-+——–+
| Connections????????? | 199156 |
| Max_used_connections | 31???? |
+———————-+——–+
2 rows in set (0.00 sec)

mysql> show status like '%thread%';
+————————+——–+
| Variable_name????????? | Value? |
+————————+——–+
| Delayed_insert_threads | 0????? |
| Slow_launch_threads??? | 0????? |
| Threads_cached???????? | 3????? |
| Threads_connected????? | 6????? |
| Threads_created??????? | 8689?? |
| Threads_running??????? | 5????? |
+————————+——–+
6 rows in set (0.00 sec)

通過以上3個命令,可以看到服務器的 thread_cache池中最多可以存放32個連接線程,為每個客戶端球使用一個線程.為每個連接的線程分配192k的內存空間.

?

服 務器總共有199156次連接,最大并發連接數為31,當前在thread_cashe池中的連接數為3個,連接數為6個,處于活躍狀態的有5個,共創建 了8689次連接.顯然這里以短連接為主.可以算出thread_cache命中率,公式為:

?

復制代碼代碼如下:
Thread_Cache_Hit=(Connections-Thread_created)/Connections*100%

?

當前服務器的Thread_cache命中率約為95.6%這個結果我還是比較滿意的.但是可以看出 thread_cache_size有點多余改成16或8更合理一些.

?

?

【TABLE_OPEN_CACHE】

==========================================================================================================

由于MySQL是多線程的機制,為了提高性能,每個線程都是獨自打開自己需要的表的文件描 述符,而不是通過共享已經打開的.針對不同存儲引擎處理的方法當然也不一樣.

在myisam表引擎中,數據文件的描述符 (descriptor)是不共享的,但是索引文件的描述符卻是所有線程共享的.Innodb中和使用表空間類型有關,假如是共享表空間那么實際就一個數 據文件,當然占用的數據文件描述符就會比獨立表空間少.

個人感覺有點像php里面的fopen打開一個連接,操作完數據之后,并不立即 關閉,而是緩存起來,等待下一個連接這個文件的請求就不必去重新打開文件了,不知樣理解對不對,哈.

手冊上有段關于打開表時的描述:

復制代碼代碼如下:
A MyISAM table is opened for each concurrent access. This means the table needs to be opened twice if two threads access the same table or if a thread accesses the table twice in the same query (for example, by joining the table to itself). Each concurrent open requires an entry in the table cache. The first open of any MyISAM table takes two file descriptors: one for the data file and one for the index file. Each additional use of the table takes only one file descriptor for the data file. The index file descriptor is shared among all threads.

如果你正用 HANDLER tbl_name OPEN語句打開一個表，將為該線程專門分配一個表。該表不被其它線程共享，只有線程調用HANDLER tbl_name CLOSE或線程終止后才被關閉。表關閉后，被拉回表緩存中(如果緩存不滿)。

?

mysql手冊上給的建議大小 是:table_cache=max_connections*n

n表示查詢語句中最大表數, 還需要為臨時表和文件保留一些額外的文件描述符。

這個數據遭到很多質疑,table_cache夠用就好,檢查 Opened_tables值,如果這個值很大,或增長很快那么你就得考慮加大table_cache了.

在下面的條件下，未使用的表 將被關閉并從表緩存中移出：

當緩存滿了并且一個線程試圖打開一個不在緩存中的表時。

當緩存包含超過table_cache個條目，并且緩存中的表不再被任何線程使用。

當表刷新操作發生。當執行FLUSH TABLES語句或執行mysqladmin flush-tables或mysqladmin refresh命令時會發生。

當表緩存滿時，服務器使用下列過程找到一個緩存入口來使用：

當前未使用的表被釋放，以最近最少使用順序。

如果緩存滿了并且沒有表可以釋放，但是一個新表需要打開，緩存必須臨時被擴大。

如果緩存處于一個臨時擴大狀態并且一個表從在用變為不在用狀態，它被關閉并從緩存中釋放。

幾個關于table_cache的 狀態值:

1. table_cache：所有線程打開的表的數目。增大該值可以增加mysqld需要的文件描述符的數量。默認值是64.

2. open_tables：當前打開的表的數量.

3. opened_tables ：Number of table cache misses，如果opened_tables較大，table_cache 值可能太小.

4. Open_table_definitions : The number of cached .frm files. This variable was added in MySQL 5.1.3.

5. Opened_table_definitions : The number of .frm files that have been cached. This variable was added in MySQL 5.1.24.

轉載于:https://www.cnblogs.com/zhangkeyu/p/6657751.html

總結

以上是生活随笔為你收集整理的mysql配置以及性能优化（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

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