MySQL優化

　　好記性不如爛筆頭，索性本身整理一下。

MySQL優化多多方面的，包括查詢優化，更新優化，和服務器優化，

目的是爲了使MySQL減小IO次數，提升反應速度，運行更快，減小資源佔用

查詢優化：

　　原則是優化更須要優化的SQL,什麼事更須要優化的SQL呢，就是執行頻率很高的的SQL

　　影響性能的緣由：

　　　　CPU致使？IO引發？數據訪問所致？數據運算影響？

　　爲了肯定是哪方面的問題引發，咱們須要使用到查看SQL的執行計劃   EXPLAIN + sql語句

 　　咱們根據主鍵id查詢一個用戶的信息，查看他的執行計劃

　　　

　　　查詢出來的結果爲：

　　　

　　　咱們對其中比較重要也就是須要咱們關注的字段進行一下說明：

　　　　type : 表示表的鏈接類型，表明這條sql語句的的執行效率斷定，有如下值

　　　　　　=system : 最高級，通常不會出現

　　　　　　=const　: 根據查詢條件，只有一行符合查詢條件，通常是以主鍵或惟一鍵做爲條件查詢

　　　　　　　　　　　　能夠理解爲 ，這就是咱們平常中最好的一種狀態了

　　　　　　

　　　　　　=eq_ref  : 聯表查詢，通常用於使用 = 比較帶索引的列-->  u.id  o.id都帶索引

　　　　　　

 　　　　　  =ref : 查詢條件沒有主鍵索引，也沒有惟一索引，通常出現於 = ,>, <操做帶有其餘索引的列 　　　　　　

　　　　　　

　　　　　　=ref_or_null : 和ref相似，包含了能夠搜索NULL值的行，通常出現與在子查詢中

 　　　　上面這五種是屬於比較理想的一種索引使用狀況，下面來看看不怎麼樣的

　　　　　　=index_merge

　　　　　　=unique_subquery

　　　　　　=index_subquery

　　　　　　=range　　　　　　：只檢索給定範圍的行 好比 age>18，使用一個索引來選擇行

　　　　　　=index　　　　　　  : 比ALL好一點

　　　　　　=ALL　　　　　　　: 完整掃描，性能最差的一個狀態

　　　有些說的太模糊了，我暫時沒搞懂什麼意思，下面繼續看其餘重要字段的意思

　　　possible_keys字段：

　　　　表示咱們的sql語句能夠經過什麼索引來找到改行 好比primarykey

　　　　　　　　若是顯示爲NULL，則表示沒有使用索引，全表掃描，效率極低

　　　key字段：

　　　　顯示sql查詢中實際使用到的索引d的字段，若是沒有顯示爲NULL

　　　　　　能夠強制使用索引或者忽略索引，以下

　　　　

其餘的字段就顯得不怎麼重要了，不作參考。

經過查看執行計劃，咱們就能夠以此爲着手點進行優化，下面說說優化的的手法：

　先理解一下索引：適當的索引能夠加快查詢速度，但若是索引過多，膽兒影響速度，在此基礎上

　　　　咱們能夠爲一下不常修改且常常被做爲查詢條件的字段添加索引，提升檢索效率；

　　1.儘可能不要在數據庫作運算，咱們應該吧運算放在service層，具備更好的擴展；

　　2.儘可能不使用反向查詢 好比 ！=  ，not in，<>....等；

　　3.儘可能不要使用Like關鍵字，若是迷糊查詢字段開頭就模糊 ，不會使用索引 好比  ‘%漢三’；

　　4.使用 or 關鍵字時，只有當先後兩個條件字段都爲索引時，索引纔會生效；

　　5這個有點多，不搬磚了，給一個截圖吧，hahhahaha 

　　　　

　　　　

 固然更多優化是方方面面的，具體狀況具體分析下面來看看插入優化：

　　插入數據時，影響插入速度的主要元素是： 索引，主鍵的惟一性的校驗，一次性插入數據的條數

　　優化手段和選擇的儲存引擎的不一樣而不一樣，在MySQL中經常使用的儲存引擎有 InnoDB 和 MyISAM ；

　　下面咱們簡單介紹一下這兩種比較經常使用的儲存引擎： MyISAM  和 InnoDB

　　　　MyISAM是ISAM的加強，在MySQL5.5以前的默認儲存引擎 ( 不包括5.5版本 )，不支持事務，外鍵；

　　　　使用一種表格鎖定的機制，優化多個併發的讀的操做，代價爲須要常常運行 optimize table命令，

　　　　　　來恢復被更新機制所浪費的空間；

　　　　MyISAM強調了快速讀取的操做，讀取數據性能是非明顯，這可能也是MySQL火的緣由之一；

　　　　MyISAM的一個重要缺陷爲，不能再表損壞後恢復數據，因此須要常常備份實時數據

　　　　說說爲何MyISAM儲存引擎查詢數據會特別快，咱們經過他/它生成的文件來看

　　　　　　.frm  ：表結構信息

　　　　　　.MYD : 數據文件　　　　　(理解爲 My Data)

　　　　　　.MYI ： 表的索引信息　　（理解爲 My Index）

　　　　　　經過上面三個文件，咱們在插入數據時，若是where後面的條件爲有索引的條件，

　　　　　　　　就會查詢表的索引信息文件，該文件能夠看做一個K-V結構，若是該條件有對應的索引，　　

　　　　　　　　就會獲得一個該索引對應在本地磁盤中的一個具體的的物理地址，因此查詢效率很是優秀

　　　　　　　　於此同時，他的增刪蓋就特別的慢，每次變動數據，都要維護數據和索引信息，

　　　　　　　　若是索引列過多，查詢效率也會相對下降

　　　　　經常使用的優化手段爲：

　　　　　　禁用索引:

　　　　　　　　　　在插入數據時，會對插入的數據創建索引，咱們能夠禁用索引，在數據插入完成後，再開啓索引

　　　　　　　　　　若是咱們插入的表是一張空表的話，則無需操做，MyISAM引擎的表實在導入數據後才創建索引的

　　　　　　　　　　禁用索引： alter table table_name disable keys

　　　　　　　　　　開啓索引：alter table table_name enable keys

　　　　   　禁用惟一性檢查:　

　　　　　　　　　　惟一性檢查會下降咱們插入數據的速度

　　　　　　　　　　咱們在批量插入數據前禁用惟一性檢查，插入後開啓惟一性檢查

　　　　　　　　　　禁用惟一性檢查： set unique_checks = 0

　　　　　　　　　　開啓惟一性檢查： set unique_checks = 1　　　　　　

 　　　    　 採用批量的方式插入數據； 這個不作過多介紹，values () , () , ();

 　　　     　使用 load data infile 語句 批量插入數比 insert 快，暫時沒用過，不作介紹；

　　　InnoDB儲存引擎的出現可能就是爲了彌補 MyISAM不支持事務，外鍵而橫空出世的；

　　　　　　在MySQL5.5（含）及以上的默認儲存引擎，支持事務，外鍵，查詢效率相對下降；

　　　　　　InnoDB是出路據大數據量的最大性能設計，CPU的優化效率是其餘引擎不能匹敵的；

　　　　　　InnoDB是第三方開發的，被MySQL整合，在內存中緩存數據和索引以維持緩衝池；

　　　　　　InnoDB的特色：支持事務，支持外鍵，鎖定機制的改進，數據多版本的讀取，

　　　　InnoDB常見優化手段：　　　　　　　　　　　　　　

　　　　　　禁用惟一性檢查；

　　　　　　　　　　　用法和MyISAM 一致　　　　　　　　　　

　　　　　　禁用外鍵檢查；　　

　　　　　　　　　　　外鍵檢查影響插入數據的效率，先關閉，插入完成後再開啓便可

　　　　　　　　　　　關閉 ： set foreign_key_checks = 0;

　　　　　　　　　　　開啓 ： set foreign_key_checks = 1;

　　　　　　禁用自動提交；　

　　　　　　　　　　　禁止事務的自動提交　，插入完成後統一提交，提升效率

　　　　　　　　　　　禁用： set autocommit = 0;

　　　　　　　　　　　開啓： set autocommit = 1;

 

　　　　MySIAM 和 innoDB 的區別以及如何抉擇？

　　　　   　

　　　　　　若是咱們以查詢爲主，基本沒有什麼增刪改，對事務的要求也特別低，就能夠選擇MyISAM;

　　　　　　　　MyISAM在系統崩潰後，數據恢復很困難，是多能夠接受？

　　　　　　在MySQL5.5版本後，MySQL默認的儲存引擎已經默認爲InnoDB,說明InnoDB也有必定的優點；

查詢和插入數據的優化已經作了簡單的 說明，下面記錄一下服務器的優化

　　　　第一個就是服務器所在機器的性能決定MySQL數據庫的性能，內存，固態硬盤，處理器...

　　　　第二個就是軟性能的提高了，在機器給定的狀況下，優化MySQL的參數：

　　　　　　優化相關參數能夠提升資源利用率，從而提升服務器性能

　　　　　　MySQL的配置參數都在my.conf或者my.ini中，

　　　　　　找到該配置文件，搜索 SQL server  

　　　　　　

　　　　能夠優化的相關參數：

 　　　　　　

　　　　　　

　　　　　　

　　　　　　

　　　　　　

　　　　　　

　　　　　　

 　　　　　　

暫時就這麼多吧，往後有新的知識點再修復補全