> 我曾經在公司處理過很多次Mysql性能上的問題，利用一些Linux常用的命令來查看Mysql對服務器的CUP和I/O使用情況，通過慢查詢日志找出有待優化的sql，通過show processlist查看正在執行的sql的情況以及及時kill死鎖的sql，通過EXPLAIN分析需要優化的sql語句。當然也對Mysql內部配置做了一些調整。 > > 最近也在看《高性能MySQL**》**這本Mysql的經典書籍，很早的時候我就想寫一個系列來介紹我在使用Mysql遇到的一些問題。無意中發現一篇博客寫的內容和我想寫的基本差不多，于是我在通讀了N篇之后整理如下。 > > 本文主要講的內容包括：查看Linux系統性能的常用命令、查詢與索引分析方法以及優化方式、Mysql內部配置優化。 > > 文章內容比較干，也比較多，建議大家收藏后慢慢消化。我也會在之后的文章中再逐一介紹我在使用中的問題。PS：本文對我找工作面試超級有用！！ **一、查看Linux系統性能的常用命令** MySQL數據庫是常見的兩個瓶頸是CPU和I/O的瓶頸。CPU在飽和的時候一般發生在數據裝入內存或從磁盤上讀取數據時候，磁盤I/O瓶頸發生在裝入數據遠大于內存容量的時候，如果應用分布在網絡上，那么查詢量相當大的時候那么瓶頸就會出現在網絡上。Linux中我們常用mpstat、vmstat、iostat、sar和top來查看系統的性能狀態。 § mpstat： mpstat是Multiprocessor Statistics的縮寫，是實時系統監控工具。其報告為CPU的一些統計信息，這些信息存放在/proc/stat文件中。在多CPUs系統里，其不但能查看所有CPU的平均狀況信息，而且能夠查看特定CPU的信息。mpstat最大的特點是可以查看多核心cpu中每個計算核心的統計數據，而類似工具vmstat只能查看系統整體cpu情況。 § vmstat：vmstat命令是最常見的Linux/Unix監控工具，可以展現給定時間間隔的服務器的狀態值，包括服務器的CPU使用率，內存使用，虛擬內存交換情況，IO讀寫情況。這個命令是我查看Linux/Unix最喜愛的命令，一個是Linux/Unix都支持，二是相比top，我可以看到整個機器的CPU、內存、IO的使用情況，而不是單單看到各個進程的CPU使用率和內存使用率(使用場景不一樣)。 § iostat: 主要用于監控系統設備的IO負載情況，iostat首次運行時顯示自系統啟動開始的各項統計信息，之后運行iostat將顯示自上次運行該命令以后的統計信息。用戶可以通過指定統計的次數和時間來獲得所需的統計信息。 § sar： sar（System Activity Reporter系統活動情況報告）是目前 Linux 上最為全面的系統性能分析工具之一，可以從多方面對系統的活動進行報告，包括：文件的讀寫情況、系統調用的使用情況、磁盤I/O、CPU效率、內存使用狀況、進程活動及IPC有關的活動等。 § top：top命令是Linux下常用的性能分析工具，能夠實時顯示系統中各個進程的資源占用狀況，類似于Windows的任務管理器。top顯示系統當前的進程和其他狀況，是一個動態顯示過程,即可以通過用戶按鍵來不斷刷新當前狀態.如果在前臺執行該命令，它將獨占前臺，直到用戶終止該程序為止。比較準確的說，top命令提供了實時的對系統處理器的狀態監視。它將顯示系統中CPU最“敏感”的任務列表。該命令可以按CPU使用。內存使用和執行時間對任務進行排序；而且該命令的很多特性都可以通過交互式命令或者在個人定制文件中進行設定。 除了服務器硬件的性能瓶頸，對于MySQL系統本身，我們可以使用工具來優化數據庫的性能，通常有三種：使用索引，使用EXPLAIN分析查詢以及調整MySQL的內部配置。 **二、查詢與索引分析方法以及優化方式** 在優化MySQL時，通常需要對數據庫進行分析，常見的分析手段有慢查詢日志，EXPLAIN 分析查詢，profiling分析以及show命令查詢系統狀態及系統變量，通過定位分析性能的瓶頸，才能更好的優化數據庫系統的性能。 2.1、性能瓶頸定位 我們可以通過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——顯示狀態信息 我常用的主要有show status和show processlist。 **慢查詢日志分析法** 慢查詢日志開啟方法一：在配置文件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 慢查詢日志開啟方法二：當然我們也可以通過命令行設置變量來即時啟動慢日志查詢，這里就不詳細介紹啦。 接下來就是打開log文件查看得知哪些SQL執行效率低下，再進行分析和處理。 **explain（執行計劃）分析查詢** 使用 EXPLAIN 關鍵字可以模擬優化器執行SQL查詢語句，從而知道MySQL是如何處理你的SQL語句的。這可以幫你分析你的查詢語句或是表結構的性能瓶頸。通過explain命令可以得到: – 表的讀取順序 – 數據讀取操作的操作類型 – 哪些索引可以使用 – 哪些索引被實際使用 – 表之間的引用 – 每張表有多少行被優化器查詢 EXPLAIN字段： ?Table：顯示這一行的數據是關于哪張表的。 ?possible\_keys：顯示可能應用在這張表中的索引。如果為空，沒有可能的索引。 ?key：實際使用的索引。如果為NULL，則沒有使用索引。MYSQL很少會選擇優化不足的索引，此時可以在SELECT語句中使用USE INDEX（index）來強制使用一個索引或者用IGNORE INDEX（index）來強制忽略索引。 ?key\_len：使用的索引的長度。在不損失精確性的情況下，長度越短越好。 ?ref：顯示索引的哪一列被使用了，如果可能的話，是一個常數。 ?rows：MySQL認為必須檢索的用來返回請求數據的行數。 ?type：這是最重要的字段之一，顯示查詢使用了何種類型。從最好到最差的連接類型為system、const、eq\_reg、ref、range、index和ALL。 > system、const：可以將查詢的變量轉為常量。如id=1; id為主鍵或唯一鍵. > > eq\_ref：訪問索引，返回某單一行的數據。(通常在聯接時出現，查詢使用的索引為主鍵或惟一鍵)。 > > ref：訪問索引,返回某個值的數據.(可以返回多行) 通常使用=時發生 > > range：這個連接類型使用索引返回一個范圍中的行，比如使用>或<查找東西，并且該字段上建有索引時發生的情況(注:不一定好于index)。 > > index：以索引的順序進行全表掃描，優點是不用排序，缺點是還要全表掃描。 > > ALL：全表掃描，應該盡量避免。 ?Extra：關于MYSQL如何解析查詢的額外信息，主要有以下幾種： > using index：只用到索引，可以避免訪問表。 > > using where：使用到where來過慮數據。不是所有的where clause都要顯示using where.。如以=方式訪問索引。 > > using tmporary：用到臨時表。 > > using filesort：用到額外的排序.。(當使用order by v1，而沒用到索引時，就會使用額外的排序)。 > > range checked for eache record(index map:N)：沒有好的索引。 **profiling分析查詢** 通過慢日志查詢可以知道哪些SQL語句執行效率低下，通過explain我們可以得知SQL語句的具體執行情況，索引使用等，還可以結合show命令查看執行狀態。 如果覺得explain的信息不夠詳細，可以同通過profiling命令得到更準確的SQL執行消耗系統資源的信息。 profiling默認是關閉的，打開方式 ： > mysql>set profiling=1; 2.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子句的查詢條件里有！=，MySQL將無法使用索引。 ? where子句使用了Mysql函數的時候，索引將無效，比如：select \* from tb where left(name, 4) = ‘xxx’。 ? 使用LIKE進行搜索匹配的時候，這樣索引是有效的：select \* from tbl1 where name like ‘xxx%’，而like ‘%xxx%’ 時索引無效。 **三、Mysql內部配置優化** 安裝MySQL后，配置文件my.cnf在 /MySQL安裝目錄/share/mysql目錄中，該目錄中還包含多個配置文件可供參考，有my-large.cnf ，my-huge.cnf， ?my-medium.cnf，my-small.cnf，分別對應大中小型數據庫應用的配置。win環境下即存在于MySQL安裝目錄中的.ini文件。 下面列出了對性能優化影響較大的主要變量，主要分為連接請求的變量和緩沖區變量。 3.1、連接請求的變量： 1）max\_connections MySQL的最大連接數，如果服務器的并發連接請求量比較大，建議調高此值，以增加并行連接數量，當然這建立在機器能支撐的情況下，因為如果連接數越多，介于MySQL會為每個連接提供連接緩沖區，就會開銷越多的內存，所以要適當調整該值，不能盲目提高設值。 數值過小會經常出現ERROR 1040: Too many connections錯誤，可以通過’conn%’通配符查看當前狀態的連接數量，以定奪該值的大小。 > show variables like ‘max\_connections’ ?#最大連接數 > > show ?status like ‘max\_used\_connections’ ?#響應的連接數 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。 3.2、緩沖區變量 **全局緩沖：** 1）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)。 2） 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、1、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％，命中率很差，可能寫操作比較頻繁吧，而且可能有些碎片。 **每個連接的緩沖** 1）record\_buffer\_size 每個進行一個順序掃描的線程為其掃描的每張表分配這個大小的一個緩沖區。如果你做很多順序掃描，你可能想要增加該值。 默認數值是131072(128K)，可改為16773120 (16M) 2）read\_rnd\_buffer\_size 隨機讀緩沖區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySQL會首先掃描一遍該緩沖，以避免磁盤搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但MySQL會為每個客戶連接發放該緩沖空間，所以應盡量適當設置該值，以避免內存開銷過大。 一般可設置為16M 3） sort\_buffer\_size 每個需要進行排序的線程分配該大小的一個緩沖區。增加這值加速ORDER BY或GROUP BY操作。 默認數值是2097144(2M)，可改為16777208 (16M)。 4） join\_buffer\_size 聯合查詢操作所能使用的緩沖區大小 record\_buffer\_size，read\_rnd\_buffer\_size，sort\_buffer\_size，join\_buffer\_size為每個線程獨占，也就是說，如果有100個線程連接，則占用為16M\*100 5） 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。 6） max\_heap\_table\_size 用戶可以創建的內存表(memory table)的大小。這個值用來計算內存表的最大行數值。這個變量支持動態改變，即set @max\_heap\_table\_size=# 這個變量和tmp\_table\_size一起限制了內部內存表的大小。如果某個內部heap（堆積）表大小超過tmp\_table\_size，MySQL可以根據需要自動將內存中的heap表改為基于硬盤的MyISAM表。 7）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堵塞 8）thread\_cache\_size 可以復用的保存在中的線程的數量。如果有，新的線程從緩存中取得，當斷開連接的時候如果有空間，客戶的線置在緩存中。如果有很多新的線程，為了提高性能可以這個變量值。 通過比較 Connections和Threads\_created狀態的變量，可以看到這個變量的作用。 默認值為110，可調優為80。 9） thread\_concurrency 推薦設置為服務器 CPU核數的2倍，例如雙核的CPU, 那么thread\_concurrency的應該為4；2個雙核的cpu, thread\_concurrency的值應為8。默認為8 10）wait\_timeout 指定一個請求的最大連接時間，對于4GB左右內存的服務器可以設置為5-10。 3.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、1、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