1監控

???????? ?工具： sp on mysql???? ?sp系列可監控各種數據庫

?

2調優

2.1 DB層操作與調優

????????????? ?2.1.1、開啟慢查詢

??????????????????????????? ?在 My.cnf文件中添加如下內容（如果不知道 my.cnf的路徑可使用 find / -name my.cnf進行查找）：

??????????????????????????? ?在 mysqld下添加

??????????????????????????? ?Log_slow_queries = ON? ?作用：開啟慢查詢服務

??????????????????????????? ?Log-slow-queries = /var/log/slowqueries.log ?作用：慢查詢日志存儲路徑。

??????????????????????????? ?Long_query_time = 1 ?作用：定義慢查詢時間長度，默認為 10

??????????????????????????? ?添加以上內容后使用 service mysqld restart ?重啟 mysql服務

??????????????????????????? ?重啟后使用 ?show variables like ‘%slow%’查看慢查詢開啟狀態

??????????????????????????? ?如 slow_query_log ?和 ?log_slow_queries ?兩個字段的值都顯示為 ON，那么說明慢查詢開啟成功。

????????????? ?2.1.2、 mysqldumpslow分析慢查詢。

? ? ? ? ? ? ? ? ? ?切換到慢查詢存儲路徑下 ?cd /var/log ?使用 ?ll ?命令查看文件，如果 slowqueries.log ?的文件的大小變大，有內容說明已經捕捉到慢查詢語句，或者使用 cat ?、 more ?、 less ?、 vi ?等命令進入文件內部進行查看，有內容說明捕捉到慢查詢。

Mysqldumpslow ?分析慢查詢日志

?????????????????????????????????????????????? ?參數說明：

??????????????????????????????????????????????????????? ?-s ?排序方式 ?c,t,l,r ?四個參數分別表示記錄次數、時間、查詢時間的多少和返回記錄次數排序。

??????????????????????????????????????????????????????? ?-t ?返回前面多少條數據

??????????????????????????????????????????????????????? ?-g ?正則表達式匹配日志內容

?

????????????? ?2.1.3、 explain執行計劃進行 sql語句分析

???????????????????????????????????? ?Explain分析捕捉到的 select語句

???????????????????????????????????? ?用法： explain ?后邊直接加 select ?語句。

?????????????????????????????????????????????? ?重點： type列

?????????????????????????????????????????????? ?指標說明：（從左到右，性能由差到好）

???????????????????????????????????????????????????????????????? ?All,index ,range,ref,,eq_ref,const or system ,null

?????????????????????????????????????????????? ?重點： extra

?????????????????????????????????????????????? ?指標說明：

???????????????????????????????????????????????????????????????? ?Only index ?使用到了索引

???????????????????????????????????????????????????????????????? ?Where used ?使用到了 where限制

???????????????????????????????????????????????????????????????? ?Using filesort ?使用了全文排序

???????????????????????????????????????????????????????????????? ?Using temporary ?使用到了臨時表

?????????????????????????????????????????????? ?當 extra里顯示有 using filesort ?或 ?using temporary ?時， sql的執行就會很吃力，時間就會增加。

?

????????????? ?2.1.4、分析后調優，優化索引

???????????????????????????????????? ?根據每個 sql語句的表現不同，在相應的字段上加索引

???????????????????????????????????? ?索引一般加在 sql語句中的 where字句相關的字段上。

?

2.2Cache層的操作與調優

2.2.1開啟 query cache

在 my.cnf里 mysqld下添加：

???????????????????????????? ?Query_cache_size = 268435456

使用的內存大小， ?這個值必須是 1024的整數倍

???????????????????????????? ?Query_cache_type = 1

???????????????????????????? ?此字段值可以 0,1,2 ?三個值

???????????????????????????? ?0,代表關閉

???????????????????????????? ?1代表給所有的 select語句做 cache

?????????????????????????????????????? ?當語句 select no_no_cache * from A;執行時不做 cache

???????????????????????????? ?2代表開啟 query cache功能，但只有執行

??????????????????????????????????????????????? ?語句 select sql_cache * from A; ?時才做 cache

???????????????????????????? ?Query_cache_limit = 1048576

???????????????????????????? ?單條語句的最大容量限制，超過此容量的 sql語句講不被 cache

?

當做 cache時需注意，只有完全相同的 sql語句才被認為是相同的，此時才能夠從緩存當中取數據，增加 sql執行速度。

如果 cache不合理，會導致大量的清緩存，加 cache的動作，不但不會增加 sql執行速度，反而會降低效率。如：當某表中有大量的插入，刪除，修改等操作時，就不適合做 cache。

?

2.2.2query cache ?運行狀態分析

show status like ‘%qcache%’

??????????????????? ?qcache_free_blocks:數目大說明有碎片

??????????????????? ?qcache_free_memory:緩存中的空閑內存

??????????????????? ?qcache_hits:命中次數，每次查詢在緩存中命中就增加

??????????????????? ?qcache_inserts:緩存中插入查詢次數，每次插入就增加

??????????????????? ?qcache_lowmem_prunes:這個數字增長，表明碎片多或內存少

??????????????????? ?qcache_total_blocks:緩存中塊的總數量

2.2.3計算

　　　　Query_cache命中率 =query_hits/(qcache_hits+qcache_inserts)

　　　　緩存碎片率 =qcache_free_blocks/qcache_total_blocks*100%

??????????????????? ?碎片率超過 20%時，可用 flush query cache整理緩存碎片

　　　　緩存利用率 =（ query_cache_size-qcache_free_memory） /query_cache_size*100%

?

2.2.4 qchche優化

???????? 整理所有查詢的 sql，講所有需要返回結果相同以及查詢方法相同的 sql整理后寫成一模一樣的，或使用 mybatis框架，把所有的 sql寫到配置文件中，使用的時候調用。

原因是，只有一模一樣的 sql語句，才會在 cache中取結果。

?

?

2.3 mysql配置優化

2.3.1 back_log

要求 ?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。

2.3.2interactive_timeout

服務器在關閉它前在一個交互連接上等待行動的秒數。一個交互的客戶被定義為對 ?mysql_real_connect()使用 ?CLIENT_INTERACTIVE ?選項的客戶。 ?默認數值是 28800，我把它改為 7200。

2.3.3 key_buffer_size

索引塊是緩沖的并且被所有的線程共享。 key_buffer_size是用于索引塊的緩沖區大小，增加它可得到更好處理的索引 (對所有讀和多重 ?寫 )，到你 ?能負擔得起那樣多。如果你使它太大，系統將開始換頁并且真的變慢了。默認數值是 8388600(8M)，我的 MySQL主機有 2GB內存，所以我把它改為 ?402649088(400MB)。

2.3.4 max_connections

允許的同時客戶的數量。增加該值增加 ?mysqld ?要求的文件描述符的數量。這個數字應該增加，否則，你將經?？吹? ?Too many connections ?錯誤。 ?默認數值是 100，我把它改為 1024 ?。

2.3.5 record_buffer

每個進行一個順序掃描的線程為其掃描的每張表分配這個大小的一個緩沖區。如果你做很多順序掃描，你可能想要增加該值。默認數值是 ?131072(128K)，我把它改為 16773120 (16M)

2.3.6 sort_buffer

每個需要進行排序的線程分配該大小的一個緩沖區。增加這值加速 ORDER BY或 GROUP BY操作。默認數值是 2097144(2M)，我把它改為 ?16777208 (16M)。

2.3.7 table_cache

為所有線程打開表的數量。增加該值能增加 mysqld要求的文件描述符的數量。 MySQL對每個唯一打開的表需要 2個文件描述符。默認數值是 64， ?我把它改為 512。

2.3.8 thread_cache_size

可以復用的保存在中的線程的數量。如果有，新的線程從緩存中取得，當斷開連接的時候如果有空間，客戶的線置在緩存中。如果有很多新的線程，為了提高 ?性能可 ?以這個變量值。通過比較 ?Connections ?和 ?Threads_created ?狀態的變量，可以看到這個變量的作用。我把它設置為 ?80。

2.3.9 wait_timeout

服務器在關閉它之前在一個連接上等待行動的秒數。 ?默認數值是 28800，我把它改為 7200。

注：參數的調整可以通過修改 ?/etc/my.cnf ?文件并重啟 ?MySQL ?實現。這是一個比較謹慎的工作，上面的結果也僅僅是我的一些看法，你可以根據你自己主機的硬件情況 (特別是內存大小 )進一步修改。

2.4 ?數據庫設計模型

2.4.1范式設計

2.4.1.1 ?一范式

需要保持每一列的原子性

例：電話號碼： 86-010-11111111

如果要符合一范式，那么需要把電話號碼拆分為國家號碼、區號、電話號碼進行存儲，達到每一列不能夠再拆分。

符合原子性的標準即為一范式

2.4.1.2 ?二范式

首先必須符合一范式。

另外需要滿足，每一個表必須有主鍵

除主鍵外其他的列必須和主鍵相關，不能只與主鍵的某一個部分相關

例如一個表有一個聯合主鍵，而部分數據是與聯合主鍵相關而不與主鍵相關，那么這時需要把表拆開，使得每一列都與主鍵相關。

?

2.4.1.3 ?三范式

首先必須符合二范式

另外需要滿足，每一個非主鍵列必須直接依賴主鍵，而不能存在傳遞依賴。

?

2.4.1.4 ?范式設計的優點

范式設計可以避免數據冗余，減少數據庫的使用空間，減輕維護數據完整性的麻煩。

2.4.1.5范式設計的缺點

?

符合范式設計的級別越高，那么拆分出來的表越多，想獲得一個完整的數據的時候聯合查詢的時候所關聯的表就越多，直接帶來的問題就是性能的下降。

?

1.2.4.2反范式設計

在實際工作中，對于獲得某些信息過于頻繁時，我們一般采用反范式設計，這樣就避免了多表的關鍵查詢，讓數據略有冗余，換來的是查詢速度的提高。

mysql監控、性能調優及三范式理解