mysql性能優化-慢查詢分析、優化索引和配置【轉】

1、優化概述

2、查詢與索引優化分析

1性能瓶頸定位

Show命令

慢查詢日誌

explain分析查詢

profiling分析查詢

 

2索引及查詢優化

3、配置優化

1)      max_connections

2)      back_log

3)      interactive_timeout

4)      key_buffer_size

5)      query_cache_size

6)      record_buffer_size

7)      read_rnd_buffer_size

8)      sort_buffer_size

9)      join_buffer_size

10)    table_cache

11)    max_heap_table_size

12)    tmp_table_size

13)    thread_cache_size

14)    thread_concurrency

15)    wait_timeout

 

1、 優化概述

MySQL數據庫是常見的兩個瓶頸是CPU和I/O的瓶頸，CPU在飽和的時候通常發生在數據裝入內存或從磁盤上讀取數據時候。磁盤I/O瓶頸發生在裝入數據遠大於內存容量的時候，若是應用分佈在網絡上，那麼查詢量至關大的時候那麼平瓶頸就會出如今網絡上，咱們能夠用mpstat, iostat, sar和vmstat來查看系統的性能狀態。

除了服務器硬件的性能瓶頸，對於MySQL系統自己，咱們可使用工具來優化數據庫的性能，一般有三種：使用索引，使用EXPLAIN分析查詢以及調整MySQL的內部配置。

2、查詢與索引優化分析

在優化MySQL時，一般須要對數據庫進行分析，常見的分析手段有慢查詢日誌，EXPLAIN 分析查詢，profiling分析以及show命令查詢系統狀態及系統變量，經過定位分析性能的瓶頸，才能更好的優化數據庫系統的性能。

1 性能瓶頸定位Show命令

咱們能夠經過show命令查看MySQL狀態及變量，找到系統的瓶頸：

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

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

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

Mysql> show processlist ——查看當前SQL執行，包括執行狀態、是否鎖表等

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

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

查看狀態變量及幫助：

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

 

比較全的Show命令的使用可參考： http://blog.phpbean.com/a.cn/18/

慢查詢日誌

慢查詢日誌開啓：

在配置文件my.cnf或my.ini中在[mysqld]一行下面加入兩個配置參數

log-slow-queries=/data/mysqldata/slow-query.log           

long_query_time=2                                                                 

注：log-slow-queries參數爲慢查詢日誌存放的位置，通常這個目錄要有mysql的運行賬號的可寫權限，通常都將這個目錄設置爲mysql的數據存放目錄；

long_query_time=2中的2表示查詢超過兩秒才記錄；

在my.cnf或者my.ini中添加log-queries-not-using-indexes參數，表示記錄下沒有使用索引的查詢。

log-slow-queries=/data/mysqldata/slow-query.log           

long_query_time=10                                                               

log-queries-not-using-indexes                                             

慢查詢日誌開啓方法二：

咱們能夠經過命令行設置變量來即時啓動慢日誌查詢。由下圖可知慢日誌沒有打開，slow_launch_time=# 表示若是創建線程花費了比這個值更長的時間,slow_launch_threads 計數器將增長

設置慢日誌開啓

MySQL後能夠查詢long_query_time 的值 。

爲了方便測試，能夠將修改慢查詢時間爲5秒。

慢查詢分析mysqldumpslow

咱們能夠經過打開log文件查看得知哪些SQL執行效率低下

[root@localhost mysql]# more slow-query.log                            

# Time: 081026 19:46:34                                                                          

# User@Host: root[root] @ localhost []                                                           

# Query_time: 11 Lock_time: 0 Rows_sent: 1 Rows_examined: 6552961        

select count(*) from t_user;                                                                                

從日誌中，能夠發現查詢時間超過5 秒的SQL，而小於5秒的沒有出如今此日誌中。

若是慢查詢日誌中記錄內容不少，可使用mysqldumpslow工具（MySQL客戶端安裝自帶）來對慢查詢日誌進行分類彙總。mysqldumpslow對日誌文件進行了分類彙總，顯示彙總後摘要結果。

進入log的存放目錄，運行

[root@mysql_data]#mysqldumpslow  slow-query.log                                 

Reading mysql slow query log from slow-query.log                            

Count: 2 Time=11.00s (22s) Lock=0.00s (0s) Rows=1.0 (2), root[root]@mysql    

select count(N) from t_user;                                                

mysqldumpslow命令

/path/mysqldumpslow -s c -t 10 /database/mysql/slow-query.log                      

這會輸出記錄次數最多的10條SQL語句，其中：

-s, 是表示按照何種方式排序，c、t、l、r分別是按照記錄次數、時間、查詢時間、返回的記錄數來排序，ac、at、al、ar，表示相應的倒敘；

-t, 是top n的意思，即爲返回前面多少條的數據；

-g, 後邊能夠寫一個正則匹配模式，大小寫不敏感的；

例如：

/path/mysqldumpslow -s r -t 10 /database/mysql/slow-log                                 

獲得返回記錄集最多的10個查詢。

/path/mysqldumpslow -s t -t 10 -g 「left join」 /database/mysql/slow-log       

獲得按照時間排序的前10條裏面含有左鏈接的查詢語句。

使用mysqldumpslow命令能夠很是明確的獲得各類咱們須要的查詢語句，對MySQL查詢語句的監控、分析、優化是MySQL優化很是重要的一步。開啓慢查詢日誌後，因爲日誌記錄操做，在必定程度上會佔用CPU資源影響mysql的性能，可是能夠階段性開啓來定位性能瓶頸。

explain分析查詢

使用 EXPLAIN 關鍵字能夠模擬優化器執行SQL查詢語句，從而知道MySQL是如何處理你的SQL語句的。這能夠幫你分析你的查詢語句或是表結構的性能瓶頸。經過explain命令能夠獲得:

– 表的讀取順序

– 數據讀取操做的操做類型

– 哪些索引可使用

– 哪些索引被實際使用

– 表之間的引用

– 每張表有多少行被優化器查詢

EXPLAIN字段：

ØTable：顯示這一行的數據是關於哪張表的

Øpossible_keys：顯示可能應用在這張表中的索引。若是爲空，沒有可能的索引。能夠爲相關的域從WHERE語句中選擇一個合適的語句

Økey：實際使用的索引。若是爲NULL，則沒有使用索引。MYSQL不多會選擇優化不足的索引，此時能夠在SELECT語句中使用USE INDEX（index）來強制使用一個索引或者用IGNORE INDEX（index）來強制忽略索引

Økey_len：使用的索引的長度。在不損失精確性的狀況下，長度越短越好

Øref：顯示索引的哪一列被使用了，若是可能的話，是一個常數

Ørows：MySQL認爲必須檢索的用來返回請求數據的行數

Øtype：這是最重要的字段之一，顯示查詢使用了何種類型。從最好到最差的鏈接類型爲system、const、eq_reg、ref、range、index和ALL

nsystem、const：能夠將查詢的變量轉爲常量.  如id=1; id爲 主鍵或惟一鍵.

neq_ref：訪問索引,返回某單一行的數據.(一般在聯接時出現，查詢使用的索引爲主鍵或唯一鍵)

nref：訪問索引,返回某個值的數據.(能夠返回多行) 一般使用=時發生

nrange：這個鏈接類型使用索引返回一個範圍中的行，好比使用>或<查找東西，而且該字段上建有索引時發生的狀況(注:不必定好於index)

nindex：以索引的順序進行全表掃描，優勢是不用排序,缺點是還要全表掃描

nALL：全表掃描，應該儘可能避免

ØExtra：關於MYSQL如何解析查詢的額外信息，主要有如下幾種

nusing index：只用到索引,能夠避免訪問表. 

nusing where：使用到where來過慮數據. 不是全部的where clause都要顯示using where. 如以=方式訪問索引.

nusing tmporary：用到臨時表

nusing filesort：用到額外的排序. (當使用order by v1,而沒用到索引時,就會使用額外的排序)

nrange checked for eache record(index map:N)：沒有好的索引.

profiling分析查詢

經過慢日誌查詢能夠知道哪些SQL語句執行效率低下，經過explain咱們能夠得知SQL語句的具體執行狀況，索引使用等，還能夠結合show命令查看執行狀態。

若是以爲explain的信息不夠詳細，能夠同經過profiling命令獲得更準確的SQL執行消耗系統資源的信息。

profiling默認是關閉的。能夠經過如下語句查看

 

 

打開功能： mysql>set profiling=1; 執行須要測試的sql 語句：

mysql> show profiles\G; 能夠獲得被執行的SQL語句的時間和ID

mysql>show profile for query 1; 獲得對應SQL語句執行的詳細信息

Show Profile命令格式：

SHOW PROFILE [type [, type] … ]                                    

    [FOR QUERY n]                                                            

    [LIMIT row_count [OFFSET offset]]                             

type:                                                                                  

    ALL                                                                               

  | BLOCK IO                                                                      

  | CONTEXT SWITCHES                                                   

  | CPU                                                                              

  | IPC                                                                                

  | MEMORY                                                                            

  | PAGE FAULTS                                                               

  | SOURCE                                                                        

  | SWAPS                

 

 

 

 

以上的16rows是針對很是簡單的select語句的資源信息，對於較複雜的SQL語句，會有更多的行和字段，好比converting HEAP to MyISAM 、Copying to tmp table等等，因爲以上的SQL語句不存在複雜的表操做，因此未顯示這些字段。經過profiling資源耗費信息，咱們能夠採起針對性的優化措施。

 

測試完畢之後 ，關閉參數：mysql> set profiling=0

 

 

2     索引及查詢優化

 

索引的類型

Ø 普通索引：這是最基本的索引類型，沒惟一性之類的限制。

Ø 惟一性索引：和普通索引基本相同，但全部的索引列值保持惟一性。

Ø 主鍵：主鍵是一種惟一索引，但必須指定爲」PRIMARY KEY」。

Ø 全文索引：MYSQL從3.23.23開始支持全文索引和全文檢索。在MYSQL中，全文索引的索引類型爲FULLTEXT。全文索引能夠在VARCHAR或者TEXT類型的列上建立。

大多數MySQL索引(PRIMARY KEY、UNIQUE、INDEX和FULLTEXT)使用B樹中存儲。空間列類型的索引使用R-樹，MEMORY表支持hash索引。

單列索引和多列索引（複合索引）

索引能夠是單列索引，也能夠是多列索引。對相關的列使用索引是提升SELECT操做性能的最佳途徑之一。

多列索引：

MySQL能夠爲多個列建立索引。一個索引能夠包括15個列。對於某些列類型，能夠索引列的左前綴，列的順序很是重要。

多列索引能夠視爲包含經過鏈接索引列的值而建立的值的排序的數組。通常來講，即便是限制最嚴格的單列索引，它的限制能力也遠遠低於多列索引。

最左前綴

多列索引有一個特色，即最左前綴（Leftmost Prefixing）。假若有一個多列索引爲key(firstname lastname age)，當搜索條件是如下各類列的組合和順序時，MySQL將使用該多列索引：

firstname，lastname，age

firstname，lastname

firstname

也就是說，至關於還創建了key(firstname lastname)和key(firstname)。

索引主要用於下面的操做：

Ø 快速找出匹配一個WHERE子句的行。

Ø 刪除行。當執行聯接時，從其它表檢索行。

Ø 對具體有索引的列key_col找出MAX()或MIN()值。由預處理器進行優化，檢查是否對索引中在key_col以前發生全部關鍵字元素使用了WHERE key_part_# = constant。在這種狀況下，MySQL爲每一個MIN()或MAX()表達式執行一次關鍵字查找，並用常數替換它。若是全部表達式替換爲常量，查詢當即返回。例如：

SELECT MIN(key2), MAX (key2)  FROM tb WHERE key1=10;

Ø 若是對一個可用關鍵字的最左面的前綴進行了排序或分組(例如，ORDER BY key_part_1,key_part_2)，排序或分組一個表。若是全部關鍵字元素後面有DESC，關鍵字以倒序被讀取。

Ø 在一些狀況中，能夠對一個查詢進行優化以便不用查詢數據行便可以檢索值。若是查詢只使用來自某個表的數字型而且構成某些關鍵字的最左面前綴的列，爲了更快，能夠從索引樹檢索出值。

SELECT key_part3 FROM tb WHERE key_part1=1

有時MySQL不使用索引，即便有可用的索引。一種情形是當優化器估計到使用索引將須要MySQL訪問表中的大部分行時。(在這種狀況下，表掃描可能會更快些）。然而，若是此類查詢使用LIMIT只搜索部分行，MySQL則使用索引，由於它能夠更快地找到幾行並在結果中返回。例如：

 

合理的創建索引的建議：

(1)  越小的數據類型一般更好：越小的數據類型一般在磁盤、內存和CPU緩存中都須要更少的空間，處理起來更快。 

(2)  簡單的數據類型更好：整型數據比起字符，處理開銷更小，由於字符串的比較更復雜。在MySQL中，應該用內置的日期和時間數據類型，而不是用字符串來存儲時間；以及用整型數據類型存儲IP地址。

(3)  儘可能避免NULL：應該指定列爲NOT NULL，除非你想存儲NULL。在MySQL中，含有空值的列很難進行查詢優化，由於它們使得索引、索引的統計信息以及比較運算更加複雜。你應該用0、一個特殊的值或者一個空串代替空值

 

這部分是關於索引和寫SQL語句時應當注意的一些瑣碎建議和注意點。

1. 當結果集只有一行數據時使用LIMIT 1

2. 避免SELECT *，始終指定你須要的列

從表中讀取越多的數據，查詢會變得更慢。他增長了磁盤須要操做的時間，仍是在數據庫服務器與WEB服務器是獨立分開的狀況下。你將會經歷很是漫長的網絡延遲，僅僅是由於數據沒必要要的在服務器之間傳輸。

3. 使用鏈接（JOIN）來代替子查詢(Sub-Queries)

       鏈接（JOIN）.. 之因此更有效率一些，是由於MySQL不須要在內存中建立臨時表來完成這個邏輯上的須要兩個步驟的查詢工做。

4. 使用ENUM、CHAR 而不是VARCHAR，使用合理的字段屬性長度

5. 儘量的使用NOT NULL

6. 固定長度的表會更快

7. 拆分大的DELETE 或INSERT 語句

8. 查詢的列越小越快

 

 Where條件

在查詢中，WHERE條件也是一個比較重要的因素，儘可能少而且是合理的where條件是很重要的，儘可能在多個條件的時候，把會提取儘可能少數據量的條件放在前面，減小後一個where條件的查詢時間。

有些where條件會致使索引無效：

Ø where子句的查詢條件裏有！=，MySQL將沒法使用索引。

Ø where子句使用了Mysql函數的時候，索引將無效，好比：select * from tb where left(name, 4) = ‘xxx’

Ø 使用LIKE進行搜索匹配的時候，這樣索引是有效的：select * from tbl1 where name like ‘xxx%’，而like ‘%xxx%’ 時索引無效

 

3、    配置優化

安裝MySQL後，配置文件my.cnf在 /MySQL安裝目錄/share/mysql目錄中，該目錄中還包含多個配置文件可供參考，有my-large.cnf ，my-huge.cnf，  my-medium.cnf，my-small.cnf，分別對應大中小型數據庫應用的配置。win環境下即存在於MySQL安裝目錄中的.ini文件。

 

下面列出了對性能優化影響較大的主要變量，主要分爲鏈接請求的變量和緩衝區變量。

1.   鏈接請求的變量：

1)     max_connections

MySQL的最大鏈接數，增長該值增長mysqld 要求的文件描述符的數量。若是服務器的併發鏈接請求量比較大，建議調高此值，以增長並行鏈接數量，固然這創建在機器能支撐的狀況下，由於若是鏈接數越多，介於MySQL會爲每一個鏈接提供鏈接緩衝區，就會開銷越多的內存，因此要適當調整該值，不能盲目提升設值。

數值太小會常常出現ERROR 1040: Too many connections錯誤，能夠過’conn%’通配符查看當前狀態的鏈接數量，以定奪該值的大小。

show variables like ‘max_connections’ 最大鏈接數

show  status like ‘max_used_connections’響應的鏈接數

以下：

mysql> show variables like ‘max_connections‘;

+———————–+——-+

| Variable_name　| Value |

+———————–+——-+

| max_connections | 256　　|

+———————–+——-+

mysql> show status like ‘max%connections‘;

+———————–+——-+

| Variable_name　      | Value |

+—————————-+——-+

| max_used_connections | 256|

+—————————-+——-+

max_used_connections / max_connections * 100% （理想值≈ 85%） 

若是max_used_connections跟max_connections相同 那麼就是max_connections設置太低或者超過服務器負載上限了，低於10%則設置過大。

2)     back_log

MySQL能暫存的鏈接數量。當主要MySQL線程在一個很短期內獲得很是多的鏈接請求，這就起做用。若是MySQL的鏈接數據達到max_connections時，新來的請求將會被存在堆棧中，以等待某一鏈接釋放資源，該堆棧的數量即back_log，若是等待鏈接的數量超過back_log，將不被授予鏈接資源。

back_log值指出在MySQL暫時中止回答新請求以前的短期內有多少個請求能夠被存在堆棧中。只有若是指望在一個短期內有不少鏈接，你須要增長它，換句話說，這值對到來的TCP/IP鏈接的偵聽隊列的大小。

當觀察你主機進程列表（mysql> show full processlist），發現大量264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待鏈接進程時，就要加大back_log 的值了。

默認數值是50，可調優爲128，對於Linux系統設置範圍爲小於512的整數。 

3)     interactive_timeout

一個交互鏈接在被服務器在關閉前等待行動的秒數。一個交互的客戶被定義爲對mysql_real_connect()使用CLIENT_INTERACTIVE 選項的客戶。 

默認數值是28800，可調優爲7200。 

2.   緩衝區變量

全局緩衝：

4)     key_buffer_size

key_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得知詳情。

舉例以下：

mysql> show variables like ‘key_buffer_size‘;

+——————-+————+

| Variable_name | Value      |

+———————+————+

| key_buffer_size | 536870912 |

+———— ———-+————+

key_buffer_size爲512MB，咱們再看一下key_buffer_size的使用狀況：

mysql> show global status like ‘key_read%‘;

+————————+————-+

| Variable_name　  | Value    |

+————————+————-+

| Key_read_requests| 27813678764 |

| Key_reads　　　|  6798830      |

+————————+————-+

一共有27813678764個索引讀取請求，有6798830個請求在內存中沒有找到直接從硬盤讀取索引，計算索引未命中緩存的機率：

key_cache_miss_rate ＝Key_reads / Key_read_requests * 100%，設置在1/1000左右較好

默認配置數值是8388600(8M)，主機有4GB內存，能夠調優值爲268435456(256MB)。

5)     query_cache_size

使用查詢緩衝，MySQL將查詢結果存放在緩衝區中，從此對於一樣的SELECT語句（區分大小寫），將直接從緩衝區中讀取結果。

經過檢查狀態值Qcache_*，能夠知道query_cache_size設置是否合理（上述狀態值可使用SHOW STATUS LIKE ‘Qcache%’得到）。若是Qcache_lowmem_prunes的值很是大，則代表常常出現緩衝不夠的狀況，若是Qcache_hits的值也很是大，則代表查詢緩衝使用很是頻繁，此時須要增長緩衝大小；若是Qcache_hits的值不大，則代表你的查詢重複率很低，這種狀況下使用查詢緩衝反而會影響效率，那麼能夠考慮不用查詢緩衝。此外，在SELECT語句中加入SQL_NO_CACHE能夠明確表示不使用查詢緩衝。

 

與查詢緩衝有關的參數還有query_cache_type、query_cache_limit、query_cache_min_res_unit。

 

query_cache_type指定是否使用查詢緩衝，能夠設置爲0、一、2，該變量是SESSION級的變量。

query_cache_limit指定單個查詢可以使用的緩衝區大小，缺省爲1M。

query_cache_min_res_unit是在4.1版本之後引入的，它指定分配緩衝區空間的最小單位，缺省爲4K。檢查狀態值Qcache_free_blocks，若是該值很是大，則代表緩衝區中碎片不少，這就代表查詢結果都比較小，此時須要減少query_cache_min_res_unit。

舉例以下：

mysql> show global status like ‘qcache%‘;

+——————————-+—————–+

| Variable_name                  | Value　       |

+——————————-+—————–+

| Qcache_free_blocks　       | 22756　      |

| Qcache_free_memory　    | 76764704    |

| Qcache_hits　　　　　      | 213028692 |

| Qcache_inserts　　　　     | 208894227   |

| Qcache_lowmem_prunes   | 4010916      |

| Qcache_not_cached　| 13385031    |

| Qcache_queries_in_cache | 43560　|

| Qcache_total_blocks          | 111212　     |

+——————————-+—————–+

mysql> show variables like ‘query_cache%‘;

+————————————–+————–+

| Variable_name　　　　　       | Value　     |

+————————————–+———–+

| query_cache_limit　　　　　    | 2097152     |

| query_cache_min_res_unit　     | 4096　　  |

| query_cache_size　　　　　    | 203423744 |

| query_cache_type　　　　　   | ON　          |

| query_cache_wlock_invalidate | OFF　  |

+————————————–+—————+

查詢緩存碎片率= Qcache_free_blocks / Qcache_total_blocks * 100%

若是查詢緩存碎片率超過20%，能夠用FLUSH QUERY CACHE整理緩存碎片，或者試試減少query_cache_min_res_unit，若是你的查詢都是小數據量的話。

查詢緩存利用率= (query_cache_size – Qcache_free_memory) / query_cache_size * 100%

查詢緩存利用率在25%如下的話說明query_cache_size設置的過大，可適當減少；查詢緩存利用率在80％以上並且Qcache_lowmem_prunes > 50的話說明query_cache_size可能有點小，要不就是碎片太多。

查詢緩存命中率= (Qcache_hits – Qcache_inserts) / Qcache_hits * 100%

示例服務器查詢緩存碎片率＝20.46％，查詢緩存利用率＝62.26％，查詢緩存命中率＝1.94％，命中率不好，可能寫操做比較頻繁吧，並且可能有些碎片。

每一個鏈接的緩衝

6)    record_buffer_size

每一個進行一個順序掃描的線程爲其掃描的每張表分配這個大小的一個緩衝區。若是你作不少順序掃描，你可能想要增長該值。

默認數值是131072(128K)，可改成16773120 (16M)

7)     read_rnd_buffer_size

隨機讀緩衝區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySQL會首先掃描一遍該緩衝，以免磁盤搜索，提升查詢速度，若是須要排序大量數據，可適當調高該值。但MySQL會爲每一個客戶鏈接發放該緩衝空間，因此應儘可能適當設置該值，以免內存開銷過大。

通常可設置爲16M 

8)     sort_buffer_size

每一個須要進行排序的線程分配該大小的一個緩衝區。增長這值加速ORDER BY或GROUP BY操做。

默認數值是2097144(2M)，可改成16777208 (16M)。

9)     join_buffer_size

聯合查詢操做所能使用的緩衝區大小

record_buffer_size，read_rnd_buffer_size，sort_buffer_size，join_buffer_size爲每一個線程獨佔，也就是說，若是有100個線程鏈接，則佔用爲16M*100

10)  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。內存在4GB左右的服務器該參數可設置爲256M或384M。

11)  max_heap_table_size

用戶能夠建立的內存表(memory table)的大小。這個值用來計算內存表的最大行數值。這個變量支持動態改變，即set @max_heap_table_size=#

這個變量和tmp_table_size一塊兒限制了內部內存表的大小。若是某個內部heap（堆積）表大小超過tmp_table_size，MySQL能夠根據須要自動將內存中的heap表改成基於硬盤的MyISAM表。

12)  tmp_table_size

經過設置tmp_table_size選項來增長一張臨時表的大小，例如作高級GROUP BY操做生成的臨時表。若是調高該值，MySQL同時將增長heap表的大小，可達到提升聯接查詢速度的效果，建議儘可能優化查詢，要確保查詢過程當中生成的臨時表在內存中，避免臨時表過大致使生成基於硬盤的MyISAM表。

mysql> show global status like ‘created_tmp%‘;

+——————————–+———+

| Variable_name　　           | Value　|

+———————————-+———+

| Created_tmp_disk_tables | 21197  |

| Created_tmp_files　　　| 58　　|

| Created_tmp_tables　　| 1771587 |

+——————————–+———–+

每次建立臨時表，Created_tmp_tables增長，若是臨時表大小超過tmp_table_size，則是在磁盤上建立臨時表，Created_tmp_disk_tables也增長,Created_tmp_files表示MySQL服務建立的臨時文件文件數，比較理想的配置是：

Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%好比上面的服務器Created_tmp_disk_tables / Created_tmp_tables * 100% ＝1.20%，應該至關好了

默認爲16M，可調到64-256最佳，線程獨佔，太大可能內存不夠I/O堵塞

13)  thread_cache_size

能夠複用的保存在中的線程的數量。若是有，新的線程從緩存中取得，當斷開鏈接的時候若是有空間，客戶的線置在緩存中。若是有不少新的線程，爲了提升性能能夠這個變量值。

經過比較 Connections和Threads_created狀態的變量，能夠看到這個變量的做用。

默認值爲110，可調優爲80。 

14)  thread_concurrency

推薦設置爲服務器 CPU核數的2倍，例如雙核的CPU, 那麼thread_concurrency的應該爲4；2個雙核的cpu, thread_concurrency的值應爲8。默認爲8

15)  wait_timeout

指定一個請求的最大鏈接時間，對於4GB左右內存的服務器能夠設置爲5-10。

 

3.    配置InnoDB的幾個變量

innodb_buffer_pool_size

對於InnoDB表來講，innodb_buffer_pool_size的做用就至關於key_buffer_size對於MyISAM表的做用同樣。InnoDB使用該參數指定大小的內存來緩衝數據和索引。對於單獨的MySQL數據庫服務器，最大能夠把該值設置成物理內存的80%。

根據MySQL手冊，對於2G內存的機器，推薦值是1G（50%）。

 

innodb_flush_log_at_trx_commit

主要控制了innodb將log buffer中的數據寫入日誌文件並flush磁盤的時間點，取值分別爲0、一、2三個。0，表示當事務提交時，不作日誌寫入操做，而是每秒鐘將log buffer中的數據寫入日誌文件並flush磁盤一次；1，則在每秒鐘或是每次事物的提交都會引發日誌文件寫入、flush磁盤的操做，確保了事務的ACID；設置爲2，每次事務提交引發寫入日誌文件的動做，但每秒鐘完成一次flush磁盤操做。

實際測試發現，該值對插入數據的速度影響很是大，設置爲2時插入10000條記錄只須要2秒，設置爲0時只須要1秒，而設置爲1時則須要229秒。所以，MySQL手冊也建議儘可能將插入操做合併成一個事務，這樣能夠大幅提升速度。

根據MySQL手冊，在容許丟失最近部分事務的危險的前提下，能夠把該值設爲0或2。

 

innodb_log_buffer_size

log緩存大小，通常爲1-8M，默認爲1M，對於較大的事務，能夠增大緩存大小。

可設置爲4M或8M。

 

innodb_additional_mem_pool_size

該參數指定InnoDB用來存儲數據字典和其餘內部數據結構的內存池大小。缺省值是1M。一般不用太大，只要夠用就行，應該與表結構的複雜度有關係。若是不夠用，MySQL會在錯誤日誌中寫入一條警告信息。

根據MySQL手冊，對於2G內存的機器，推薦值是20M，可適當增長。

 

innodb_thread_concurrency=8

推薦設置爲 2*(NumCPUs+NumDisks)，默認通常爲8