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反正規化設計
在實際工作中，對於獲得某些資訊過於頻繁時，我們一般採用反正規化設計，這樣就避免了多表的關鍵查詢，讓資料略有冗餘，換來的是查詢速度的提高。