可以線上執行檢視效果哦！

        本文根據優才網課程整理，面向web開發者，內容以實用為主，專業DBA可以繞行。

        如果你在大公司，可能有專門的DBA來做這些事情，如果你在一個小公司當架構師或者技術總監，或者你自己創業，那DBA的活你也得幹了。咱們來講一下基本的mysql安裝和優化。

一： MYSQL安裝和基本配置

在linux上安裝，可以用包管理工具來安裝，比較簡單：

RedHat 系列：yum -yinstall  mysql mysql-server 

Debian系列：sudo apt-getinstall  mysql mysql-server

安裝之後不知道mysql裝到哪了怎麼辦，用whereis mysql 命令來找一下。先找到mysql的預設配置檔案。一般來說，安裝後有這麼幾個備選的配置：my-huge.cnf my-innodb-heavy-4G.cnf my-large.cnf my-medium.cnf my-small.cnf

就2014年的機器配置來說，咱們直接用my-huge.cnf。把my-huge.cnf 複製到/etc/下，改名my.cnf。配置檔案就有了，然後啟動mysql： /etc/init.d/mysqld start 。

安裝之後預設的帳號是root, 密碼為空。咱們要做的第一件事是改root密碼。

進入mysql：mysql -uroot -p

選擇資料庫： use mysql

改密碼： UPDATE user SET Password = PASSWORD('xxxx') WHERE user = 'root';

重新整理許可權： FLUSH PRIVILEGES;

現在資料庫裝好了，帳號和許可權也設定了，是不是就可以使用了呢,還要檢查幾個配置。開啟配置檔案 vim /etc/my.cnf

skip-networking 要關閉。

bind-address = 127.0.0.1 這一行要關閉或者修改成允許的IP

skip-name-resolve 禁止dns解析，只能用IP連，這個可以開啟。

       如果你的mysql經過一段時間執行，挺過了訪問高峰，咱們再來檢查一下配置是否合適。下面說的配置，都必須是在執行一段時間後檢查才有意義。如果剛啟動沒多久，mysql的執行狀態沒有代表性，不能作為參考。檢查配置引數也沒意義。

二：連線數(connection)配置

       max_connections 可以設定最大併發連線數。當MySql的併發連線達到這個設定值時，新的連線將會被拒絕（“Can not connect to MySQL server. Too many connections”-mysql 1040錯誤，）。當發現MySql有能力處理更多的併發的時候， 建議調大這個值，相應給伺服器帶來更高的負載(CPU/IO/記憶體)。

檢視設定的最大連線是多少：

mysql> show variables like 'max_connections';

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

| Variable_name   | Value |

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

| max_connections | 151   | 允許的最大連線數

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

 看當前連線數：showstatus like 'threads_connected';

最大連線數: show status like "max_used_connections";

如果max_used_connections已經接近 max_connections了，就說明max_connections太小。不合適了。

還有一些跟連線數相關的配置：

back_log=50

MySQL能暫存的連線數量。當主要MySQL執行緒在一個很短時間內得到非常多的連線請求，這就起作用。如果MySQL的連線資料達到max_connections時，新來的請求將會被存在堆疊中，以等待某一連線釋放資源，該堆疊的數量即back_log，如果等待連線的數量超過back_log，將不被授予連線資源。

        back_log值指出在MySQL暫時停止回答新請求之前的短時間內有多少個請求可以被存在堆疊中。只有如果期望在一個短時間內有很多連線，你需要增加它，換句話說，這值對到來的TCP/IP連線的偵聽佇列的大小。

        不同的作業系統在這個佇列大小上有它自己的限制。試圖設定back_log高於你的作業系統的限制將是無效的。預設值為50。對於Linux系統推薦設定為小於512的整數。

如果連結數超過max_connections+back_log ，才會出錯。

max_connect_errors=10

        當客戶端連線服務端超時(超過connect_timeout), 服務端就會給這個客戶端記錄一次error，當出錯的次數達到max_connect_errors的時候，這個客戶端就會被鎖定。除非執行FLUSH HOSTS命令。

connect_timeout=5

連線超時的秒數

三：查詢快取(query_cache)配置

        查詢快取就是記憶體中的一塊儲存區域，其儲存了使用者的SQL文字以及相關的查詢結果。通常情況下，使用者下次查詢時，如果所使用的SQL文字是相同的，並且自從上次查詢後，相關的紀錄沒有被更新過，此時資料庫就直接採用快取中的內容。從記憶體中讀取要比從硬碟上速度要快好幾百倍。MYSQL的查詢快取用於快取select查詢結果，並在下次接收到同樣的查詢請求時，不再執行實際查詢處理而直接返回結果，有這樣的查詢快取能提高查詢的速度，使查詢效能得到優化。

       要使用快取，有幾個條件：一是所採用的SQL語句是相同的。每次查詢的語句不一樣，肯定不能用到快取。比如語句裡帶當前秒數 where ctime > xxx；二是表資料沒有改過。沒有改過結構，沒有update，insert；三、客戶端與伺服器的預設字符集得一樣。所以可以看出，要利用好快取，有大量的相同的查詢，而很少改變表裡的資料，否則沒有必要使用此功能。

檢視查詢快取的設定：

SHOW VARIABLES LIKE '%query_cache%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| have_query_cache             | YES      |
| query_cache_limit            | 1048576  |  如果單個查詢結果大於這個值，則不Cache
| query_cache_min_res_unit     | 4096     |  每次給QC結果分配記憶體的大小
| query_cache_size             | 33554432 |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

query_cache_type=1

        如果設定為1，將會快取所有的結果，除非你的select語句使用SQL_NO_CACHE禁用了查詢快取。如果設定為2，則只快取在select語句中通過SQL_CACHE指定需要快取的查詢。query_cache_size 預設是32M，太小了，可調到128M或者256M。 可以通過Qcache_lowmem_prunes變數的值來檢查是否當前的值滿足你目前系統的負載。

        query_cache_size的工作原理：一個SELECT查詢在DB中工作後，DB會把該語句快取下來，當同樣的一個SQL再次來到DB裡呼叫時，DB在該表沒發生變化的情況下把結果從快取中返回給Client。這裡有一個關建點，就是DB在利用Query_cache工作時，要求該語句涉及的表在這段時間內沒有發生變更。那如果該表在發生變更時，Query_cache裡的資料又怎麼處理呢？

        首先要把Query_cache和該表相關的語句全部置為失效，然後在寫入更新。那麼如果Query_cache非常大，該表的查詢結構又比較多，查詢語句失效也慢，一個更新或是Insert就會很慢，這樣看到的就是Update或是Insert怎麼這麼慢了。所以在資料庫寫入量或是更新量也比較大的系統，該引數不適合分配過大。而且在高併發，寫入量大的系統，建系把該功能禁掉。 

       Qcache_lowmem_prunes可以檢查是否設定的太小。query_cache_limit 預設是1M，根據你的常用查詢的資料結果大小來定。如果返回的資料小，可以設定小一點。設定值大對大資料查詢有好處，但如果你的查詢都是小資料查詢，就容易造成記憶體碎片和浪費。

檢視快取使用效果如何：

 showstatus like '%Qcache%';

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

| Variable_name           | Value    |

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

| Qcache_free_blocks      | 160     | 目前還處於空閒狀態的 Query Cache中記憶體 Block 數目，數目大說明可能有碎片。FLUSH QUERY CACHE會對快取中的碎片進行整理，從而得到一個空閒塊。

| Qcache_free_memory      | 23147296 | 快取中的空閒記憶體總量。

| Qcache_hits             | 52349    | 快取命中次數。

| Qcache_inserts          | 8827     | 快取失效次數。

| Qcache_lowmem_prunes    | 0       | 快取出現記憶體不足並且必須要進行清理以便為更多查詢提供空間的次數。這個數字最好長時間來看；如果這個數字在不斷增長，就表示可能碎片非常嚴重，或者記憶體很少。

| Qcache_not_cached       | 2446     | 沒有被cache和不適合進行快取的查詢的數量，通常是由於這些查詢不是SELECT語句以及由於query_cache_type設定的不會被Cache的查詢。show,use,desc

| Qcache_queries_in_cache | 5234     | 當前被cache的SQL數量。

| Qcache_total_blocks     | 10796   | 快取中塊的數量。

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

show global status like 'Com_select'; 

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

| Variable_name | Value |

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

| Com_select    | 12592 | com_select 變數記錄的是無快取的查詢次數+錯誤查詢+許可權檢查查詢。

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

Mysql的查詢快取命中率沒有官方演算法，只有前人的經驗總結

命中率≈ qcache_hits / (qcache_hits + com_select)

快取碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100% ,如果碎片率太高，20% ，可以FLUSHQUERY 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可能有點小，要不就是碎片太多。

如何提高命中率：

1、字符集相同；2、SQL語句儘量固定(SQL語句避免隨機數，秒數等)；3、 加大快取空間； 4、適當分表,動靜分離。

四、臨時表快取(tmp_table_size)配置

        mysql進行復雜查詢或者 做高階GROUP BY操作的時候，系統為了優化查詢，生成一些臨時表。通過設定tmp_table_size選項來設定臨時表佔用空間的大小。我們使用explain分析SQL，如果在Extra列看到Using temporary就意味著使用了臨時表。

        MySQL臨時表分為“記憶體臨時表”和“磁碟臨時表”，其中記憶體臨時表使用MySQL的MEMORY儲存引擎，磁碟臨時表使用MySQL的MyISAM儲存引擎。一般情況下，MySQL會先建立記憶體臨時表，但記憶體臨時表超過配置指定的值後，MySQL會將記憶體臨時表匯出到磁碟臨時表。臨時表將在你連線MySQL期間存在。當你斷開時，MySQL將自動刪除表並釋放所用的空間。

 mysql> SHOW VARIABLES LIKE '%tmp_table_size%';
+----------------+----------+
| Variable_name  | Value    |
+----------------+----------+
| tmp_table_size | 33554432 | 
+----------------+----------+
1 row in set (0.00 sec)
 
mysql> show global status like 'created_tmp%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+

| Created_tmp_disk_tables | 690421   |  伺服器執行語句時在硬碟上自動建立的臨時表的數量

| Created_tmp_files       | 755473   |  mysqld已經建立的臨時檔案的數量

| Created_tmp_tables      | 14372959 | 伺服器執行語句時自動建立的記憶體中的臨時表的數量。如果Created_tmp_disk_tables較大，你可能要增加tmp_table_size值使臨時 表基於記憶體而不基於硬碟

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

       每次建立臨時表，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%，應該相當好了。預設大小是 32M，可調到64-256最佳，執行緒獨佔，太大可能記憶體不夠I/O堵塞。

       跟臨時表相關的另一配置是max_heap_table_size ，使用者可以建立的獨立的記憶體表所允許的最大容量.這個變數不適用與使用者建立的記憶體表(memory table).SHOW VARIABLES LIKE'%max_heap_table_size%'; 咱們希望臨時表是放到記憶體的。所以這個值設定的臨時表快取的空間一樣就行。（實際起限制作用的是tmp_table_size和max_heap_table_size的最小值。）如果臨時表大於這兩個的任何一個，都會存硬碟快取：自動地把它轉化為基於磁碟的MyISAM表，儲存在指定的tmpdir目錄下。

五、索引緩衝區（key_buffer_size）配置

       key_buffer_size是對MyISAM表效能影響最大的一個引數.key_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤其是索引讀的速度。通過檢查狀態值Key_read_requests和Key_reads，可以知道key_buffer_size設定是否合理。比例key_reads /key_read_requests應該儘可能的低，至少是1:100，1:1000更好。

       key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表，但是內部的臨時磁碟表是MyISAM表，也要使用該值。可以使用檢查狀態值created_tmp_disk_tables得知詳情。

mysql> show variables like 'key_buffer_size';
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| key_buffer_size | 67108864 | 索引緩衝區的大小
+-----------------+----------+
 
show variables like 'key_cache_block_size';
 
 
mysql> show global status like 'key%';
+------------------------+------------+
| Variable_name          | Value      |
+------------------------+------------+
| Key_blocks_not_flushed | 0          |索引快取內已經更改，但還沒有清空到硬碟上的索引的資料塊數量。
| Key_blocks_unused      | 0          | 索引快取內未使用的塊數量。你可以使用該值來確定使用了多少鍵快取
| Key_blocks_used        | 53585      | 索引快取內使用的塊數量。該值為高水平線標記，說明已經同時最多使用了多少塊。
| Key_read_requests      | 4952122733 | 一共有XXX個索引讀取請求，
| Key_reads              | 11879      | 索引讀取請求在記憶體中沒有找到，直接從硬碟讀取索引
| Key_write_requests     | 10508455   | 將索引的資料塊寫入快取的請求數。
| Key_writes             | 6042774    |  將索引向硬碟寫入資料塊的物理寫操作的次數。
+------------------------+------------+

       比例key_reads /key_read_requests應該儘可能的低，至少是1:100，1:1000更好；

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

Key_writes/Key_write_requests：比例接近1較好。

       別人的經驗是記憶體在4GB左右的伺服器該引數可設定為384M或512M。可以自己算一下自己資料庫的索引檔案大小。注意：該引數值設定的過大反而會是伺服器整體效率降低！

Cache命中比率：

1 - Key_reads / Key_read_requests 
Key buffer的使用率
100 – ( (Key_blocks_unused *key_cache_block_size) * 100 / key_buffer_size )