vi  /etc/my.cnf

    back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆疊中。也就是說，如果MySql的連線資料達到max_connections時，新來的請求將會被存在堆疊中，以等待某一連線釋放資源，該堆疊的數量即back_log，如果等待連線的數量超過back_log，將不被授予連線資源。將會報：unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 

back_log值不能超過TCP/IP連線的偵聽佇列的大小。若超過則無效，檢視當前系統的TCP/IP連線的偵聽佇列的大小命令：cat /proc/sys/net/ipv4/tcp_max_syn_backlog目前系統為1024。對於Linux系統推薦設定為小於512的整數。

修改系統核心引數，）http://www.51testing.com/html/64/n-810764.html

檢視mysql 當前系統預設back_log值，命令：

show variables like 'back_log'; 檢視當前數量

我對wait-timeout這個引數的理解：MySQL客戶端的資料庫連線閒置最大時間值。

說得比較通俗一點，就是當你的MySQL連線閒置超過一定時間後將會被強行關閉。MySQL預設的wait-timeout  值為8個小時，可以通過命令show variables like 'wait_timeout'檢視結果值;。

設定這個值是非常有意義的，比如你的網站有大量的MySQL連結請求（每個MySQL連線都是要記憶體資源開銷的 ），由於你的程式的原因有大量的連線請求空閒啥事也不幹，白白佔用記憶體資源，或者導致MySQL超過最大連線數從來無法新建連線導致“Too many connections”的錯誤。在設定之前你可以檢視一下你的MYSQL的狀態（可用show processlist)，如果經常發現MYSQL中有大量的Sleep程序，則需要 修改wait-timeout值了。

interactive_timeout：伺服器關閉互動式連線前等待活動的秒數。互動式客戶端定義為在mysql_real_connect()中使用CLIENT_INTERACTIVE選項的客戶端。

wait_timeout:伺服器關閉非互動連線之前等待活動的秒數。線上程啟動時，根據全域性wait_timeout值或全域性 interactive_timeout值初始化會話wait_timeout值，取決於客戶端型別(由mysql_real_connect()的連線選項CLIENT_INTERACTIVE定義).

這兩個引數必須配合使用。否則單獨設定wait_timeout無效

max_connections是指MySql的最大連線數，如果伺服器的併發連線請求量比較大，建議調高此值，以增加並行連線數量，當然這建立在機器能支撐的情況下，因為如果連線數越多，介於MySql會為每個連線提供連線緩衝區，就會開銷越多的記憶體，所以要適當調整該值，不能盲目提高設值。可以過'conn%'萬用字元檢視當前狀態的連線數量，以定奪該值的大小。

MySQL伺服器允許的最大連線數16384；

檢視系統當前最大連線數：

show variables like 'max_connections';

 max_user_connections是指每個資料庫使用者的最大連線

針對某一個賬號的所有客戶端並行連線到MYSQL服務的最大並行連線數。簡單說是指同一個賬號能夠同時連線到mysql服務的最大連線數。設定為0表示不限制。

目前預設值為：0不受限制。

這兒順便介紹下Max_used_connections:它是指從這次mysql服務啟動到現在，同一時刻並行連線數的最大值。它不是指當前的連線情況，而是一個比較值。如果在過去某一個時刻，MYSQL服務同時有1000個請求連線過來，而之後再也沒有出現這麼大的併發請求時，則Max_used_connections=1000.請注意與show variables 裡的max_user_connections的區別。預設為0表示無限大。

檢視max_user_connections值

show variables like 'max_user_connections';

thread_concurrency的值的正確與否, 對mysql的效能影響很大, 在多個cpu(或多核)的情況下，錯誤設定了thread_concurrency的值, 會導致mysql不能充分利用多cpu(或多核), 出現同一時刻只能一個cpu(或核)在工作的情況。

thread_concurrency應設為CPU核數的2倍. 比如有一個雙核的CPU, 那thread_concurrency  的應該為4; 2個雙核的cpu, thread_concurrency的值應為8.

比如：根據上面介紹我們目前系統的配置，可知道為4個CPU,每個CPU為8核，按照上面的計算規則，這兒應為:4*8*2=64

檢視系統當前thread_concurrency預設配置命令：

 show variables like 'thread_concurrency';

skip-name-resolve：禁止MySQL對外部連線進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠端主機連線授權都要使用IP地址方式，否則MySQL將無法正常處理連線請求！

開啟該選項可以徹底關閉MySQL的TCP/IP連線方式，如果WEB伺服器是以遠端連線的方式訪問MySQL資料庫伺服器則不要開啟該選項！否則將無法正常連線！

設定建立資料庫及表預設儲存型別

show table status like ‘tablename’顯示錶的當前儲存狀態值

檢視MySQL有哪些儲存狀態及預設儲存狀態

 show engines;

建立表並指定儲存型別

CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB;

修改表儲存型別：

  Alter table tableName engine =engineName

備註：設定完後把以下幾個開啟：

# Uncomment the following if you are using InnoDB tables

innodb_data_home_dir = /var/lib/mysql

#innodb_data_file_path = ibdata1:1024M;ibdata2:10M:autoextend（要註釋掉，否則會建立一個新的把原來的替換的。）

innodb_log_group_home_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 = 1000M

innodb_additional_mem_pool_size = 20M

# Set .._log_file_size to 25 % of buffer pool size

innodb_log_file_size = 500M

innodb_log_buffer_size = 20M

innodb_flush_log_at_trx_commit = 0

innodb_lock_wait_timeout = 50

設定完後一定記得把MySQL安裝目錄地址（我們目前是預設安裝所以地址/var/lib/mysql/）下的ib_logfile0和ib_logfile1刪除掉。否則重啟MySQL起動失敗。

資料庫屬於IO密集型的應用程式，其主職責就是資料的管理及儲存工作。而我們知道，從記憶體中讀取一個數據庫的時間是微秒級別，而從一塊普通硬碟上讀取一個 IO是在毫秒級別，二者相差3個數量級。所以，要優化資料庫，首先第一步需要優化的就是IO，儘可能將磁碟IO轉化為記憶體IO。本文先從MySQL資料庫 IO相關引數(快取引數)的角度來看看可以通過哪些引數進行IO優化

啟動MySQL時就要分配並且總是存在的全域性快取。目前有：key_buffer_size(預設值：402653184,即384M)、innodb_buffer_pool_size(預設值：134217728即：128M)、innodb_additional_mem_pool_size（預設值：8388608即：8M）、innodb_log_buffer_size(預設值：8388608即：8M)、query_cache_size(預設值：33554432即：32M)等五個。總共：560M.

這些變數值都可以通過命令如：show variables like '變數名';檢視到。

    key_buffer_size是用於索引塊的緩衝區大小，增加它可得到更好處理的索引(對所有讀和多重寫)，對MyISAM(MySQL表儲存的一種型別，可以百度等檢視詳情)表效能影響最大的一個引數。如果你使它太大，系統將開始換頁並且真的變慢了。嚴格說是它決定了資料庫索引處理的速度，尤其是索引讀的速度。對於記憶體在4GB左右的伺服器該引數可設定為256M或384M.

怎麼才能知道key_buffer_size的設定是否合理呢，一般可以檢查狀態值Key_read_requests和Key_reads   ，比例key_reads / key_read_requests應該儘可能的低，比如1:100，1:1000 ，1:10000。其值可以用以下命令查得：show status like 'key_read%';

比如檢視系統當前key_read和key_read_request值為：

+-------------------+-------+

| Variable_name     | Value |

+-------------------+-------+

| Key_read_requests | 28535 |

| Key_reads         | 269   |

+-------------------+-------+

可知道有28535個請求，有269個請求在記憶體中沒有找到直接從硬碟讀取索引.

未命中快取的概率為：0.94%=269/28535*100%.  一般未命中概率在0.1之下比較好。目前已遠遠大於0.1，證明效果不好。若命中率在0.01以下，則建議適當的修改key_buffer_size值。

http://dbahacker.com/mysql/innodb-myisam-compare(InnoDB與MyISAM的六大區別)

http://kb.cnblogs.com/page/99810/（檢視儲存引擎介紹）

MyISAM、InnoDB、MyISAM Merge引擎、InnoDB、memory(heap)、archive

   innodb_buffer_pool_size:主要針對InnoDB表效能影響最大的一個引數。功能與Key_buffer_size一樣。InnoDB佔用的記憶體，除innodb_buffer_pool_size用於儲存頁面快取資料外，另外正常情況下還有大約8%的開銷，主要用在每個緩存頁幀的描述、adaptive hash等資料結構，如果不是安全關閉，啟動時還要恢復的話，還要另開大約12%的記憶體用於恢復，兩者相加就有差不多21%的開銷。假設：12G的innodb_buffer_pool_size，最多的時候InnoDB就可能佔用到14.5G的記憶體。若系統只有16G，而且只執行MySQL，且MySQL只用InnoDB，

那麼為MySQL開12G，是最大限度地利用記憶體了。

另外InnoDB和 MyISAM 儲存引擎不同， MyISAM 的 key_buffer_size 只能快取索引鍵，而 innodb_buffer_pool_size 卻可以快取資料塊和索引鍵。適當的增加這個引數的大小，可以有效的減少 InnoDB 型別的表的磁碟 I/O 。

當我們操作一個 InnoDB 表的時候，返回的所有資料或者去資料過程中用到的任何一個索引塊，都會在這個記憶體區域中走一遭。

可以通過 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 計算快取命中率，並根據命中率來調整 innodb_buffer_pool_size 引數大小進行優化。值可以用以下命令查得：show status like 'Innodb_buffer_pool_read%';

比如檢視當前系統中系統中

| Innodb_buffer_pool_read_requests      | 1283826 |

| Innodb_buffer_pool_reads              | 519     |

+---------------------------------------+---------+

其命中率99.959%=（1283826-519）/1283826*100%  命中率越高越好。

     innodb_additional_mem_pool_size 設定了InnoDB儲存引擎用來存放資料字典資訊以及一些內部資料結構的記憶體空間大小，所以當我們一個MySQL Instance中的資料庫物件非常多的時候，是需要適當調整該引數的大小以確保所有資料都能存放在記憶體中提高訪問效率的。

這個引數大小是否足夠還是比較容易知道的，因為當過小的時候，MySQL會記錄Warning資訊到資料庫的error log中，這時候你就知道該調整這個引數大小了。

檢視當前系統mysql的error日誌  cat  /var/lib/mysql/機器名.error 發現有很多waring警告。所以要調大為20M.

根據MySQL手冊，對於2G記憶體的機器，推薦值是20M。

    32G記憶體的 100M

    innodb_log_buffer_size  這是InnoDB儲存引擎的事務日誌所使用的緩衝區。類似於Binlog Buffer，InnoDB在寫事務日誌的時候，為了提高效能，也是先將資訊寫入Innofb Log Buffer中，當滿足innodb_flush_log_trx_commit引數所設定的相應條件(或者日誌緩衝區寫滿)之後，才會將日誌寫到檔案 (或者同步到磁碟)中。可以通過innodb_log_buffer_size 引數設定其可以使用的最大記憶體空間。

   InnoDB 將日誌寫入日誌磁碟檔案前的緩衝大小。理想值為 1M 至 8M。大的日誌緩衝允許事務執行時不需要將日誌儲存入磁碟而只到事務被提交(commit)。 因此，如果有大的事務處理，設定大的日誌緩衝可以減少磁碟I/O。 在 my.cnf中以數字格式設定。

預設是8MB，系的如頻繁的系統可適當增大至4MB～8MB。當然如上面介紹所說，這個引數實際上還和另外的flush引數相關。一般來說不建議超過32MB

注：innodb_flush_log_trx_commit引數對InnoDB Log的寫入效能有非常關鍵的影響,預設值為1。該引數可以設定為0，1，2，解釋如下：

0：log buffer中的資料將以每秒一次的頻率寫入到log file中，且同時會進行檔案系統到磁碟的同步操作，但是每個事務的commit並不會觸發任何log buffer 到log file的重新整理或者檔案系統到磁碟的重新整理操作;

1：在每次事務提交的時候將log buffer 中的資料都會寫入到log file，同時也會觸發檔案系統到磁碟的同步;

2：事務提交會觸發log buffer到log file的重新整理，但並不會觸發磁碟檔案系統到磁碟的同步。此外，每秒會有一次檔案系統到磁碟同步操作。

實際測試發現，該值對插入資料的速度影響非常大，設定為2時插入10000條記錄只需要2秒，設定為0時只需要1秒，而設定為1時則需要229秒。因此，MySQL手冊也建議儘量將插入操作合併成一個事務，這樣可以大幅提高速度。根據MySQL手冊，在存在丟失最近部分事務的危險的前提下，可以把該值設為0。

     query_cache_size: 主要用來快取MySQL中的ResultSet，也就是一條SQL語句執行的結果集，所以僅僅只能針對select語句。當我們打開了 Query Cache功能，MySQL在接受到一條select語句的請求後，如果該語句滿足Query Cache的要求(未顯式說明不允許使用Query Cache，或者已經顯式申明需要使用Query Cache)，MySQL會直接根據預先設定好的HASH演算法將接受到的select語句以字串方式進行hash，然後到Query Cache中直接查詢是否已經快取。也就是說，如果已經在快取中，該select請求就會直接將資料返回，從而省略了後面所有的步驟(如SQL語句的解析，優化器優化以及向儲存引擎請求資料等)，極大的提高效能。根據MySQL使用者手冊，使用查詢緩衝最多可以達到238%的效率。

當然，Query Cache也有一個致命的缺陷，那就是當某個表的資料有任何任何變化，都會導致所有引用了該表的select語句在Query Cache中的快取資料失效。所以，當我們的資料變化非常頻繁的情況下，使用Query Cache可能會得不償失

   Query Cache的使用需要多個引數配合，其中最為關鍵的是query_cache_size和query_cache_type，前者設定用於快取 ResultSet的記憶體大小，後者設定在何場景下使用Query Cache。在以往的經驗來看，如果不是用來快取基本不變的資料的MySQL資料庫，query_cache_size一般256MB是一個比較合適的大小。當然，這可以通過計算Query Cache的命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))來進行調整。 query_cache_type可以設定為0(OFF)，1(ON)或者2(DEMOND)，分別表示完全不使用query cache，除顯式要求不使用query cache(使用sql_no_cache)之外的所有的select都使用query cache，只有顯示要求才使用query cache(使用sql_cache)。如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩衝. 如果Qcache_hits的值也非常大，則表明查詢緩衝使用非常頻繁，此時需要增加緩衝大小；

根據命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))進行調整，一般不建議太大，256MB可能已經差不多了，大型的配置型靜態資料可適當調大.

可以通過命令：show status like 'Qcache_%';檢視目前系統Query catch使用大小

| Qcache_hits             | 1892463  |

| Qcache_inserts          | 35627  

命中率98.17%=1892463/(1892463 +35627 )*100

除了全域性緩衝，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表的大小，可達到提高

聯接查詢速度的效果。

  record_buffer每個進行