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

1監控

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

 

2調優

2.1 DB層操做與調優

              2.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.二、mysqldumpslow分析慢查詢。

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

Mysqldumpslow 分析慢查詢日誌

                                               參數說明：

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

                                                        -t 返回前面多少條數據

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

 

              2.1.三、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.四、分析後調優，優化索引

                                     根據每一個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反範式設計

在實際工做中，對於得到某些信息過於頻繁時，咱們通常採用反範式設計，這樣就避免了多表的關鍵查詢，讓數據略有冗餘，換來的是查詢速度的提升。