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

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反范式設計

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