MySQL SQL語句分析查詢優化

如何獲取有性能問題的SQL

一、經過用戶反饋獲取存在性能問題的SQL
二、經過慢查詢日誌獲取性能問題的SQL
三、實時獲取存在性能問題的SQL

使用慢查詢日誌獲取有性能問題的SQL

首先介紹下慢查詢相關的參數

一、slow_query_log      啓動定製記錄慢查詢日誌
    設置的方法，能夠經過MySQL命令行設置set global slow_query_log=on
    或者修改/etc/my.cnf文件，添加slow_query_log=on

二、slow_query_log_file 指定慢查詢日誌的存儲路徑及文件
    建議日誌存儲和數據存儲分開存儲

三、long_query_time   指定記錄慢查詢日誌SQL執行時間的閾值
    ① 記錄全部符合條件的SQL
    ② 數據修改語句
    ③ 包括查詢語句
    ④ 已經回滾的SQL
    
    注意：
        時間能夠精確到微秒，存儲的單位是秒，默認值爲10秒，例如咱們想查詢1微秒的值，這裏就要設置成0.001秒

四、log_queries_not_using_indexes 是否記錄未使用索引的SQL

五、log_output 設置慢日誌查詢的保存格式(若是須要保存爲文件請修改爲FILE)

慢查詢使用日誌中記錄的信息

一、第一行記錄的信息爲使用sbtest作的測試
二、第二行記錄的信息爲慢查詢日誌的時間
三、第三行記錄的信息爲所使用鎖的時間
四、第四行記錄的信息爲返回的數據行數
五、第五行記錄的信息爲掃描數據的行數
六、第六行記錄的信息爲時間戳
七、第七行記錄的信息爲查詢的SQL語句

使用慢查詢獲取有性能問題的SQL

常使用的慢查詢日誌分析工具(mysqldumpslow)

介紹：彙總除查詢條件外其餘徹底相同的SQL，並將分析結果按照參數中所指定的順序輸出

慢查詢日誌實例

慢查詢的相關配置設置

命令行執行參數查看分析的結果

]# cd /var/lib/mysql/log
]# mysqldumpslow -s r -t 10 slow-mysql

常使用的慢查詢日誌分析工具(pt-query-digest)

使用工具前，須要先安裝該工具，若是已有，可略過下面的安裝步驟
一、perl模塊
    ]# yum install -y perl-CPAN perl-Time-HiRes perl-IO-Socket-SSL perl-DBD-mysql perl-Digest-MD5
二、切換至src目錄下載rpm包
    ]# cd /usr/local/src
    ]# wget https://www.percona.com/downloads/percona-toolkit/3.0.7/binary/redhat/7/x86_64/percona-toolkit-3.0.7-1.el7.x86_64.rpm

三、安裝工具包
    ]# rpm -ivh percona-toolkit-3.0.7-1.el7.x86_64.rpm

執行命令分析慢查詢日誌

]# pt-query-digest --user=root --password=redhat --host=127.0.0.1 slow-mysql > slow.rep

分析的結果以下

MySQL服務器處理查詢請求的整個過程

一、客戶端發送SQL請求給服務器
二、服務器檢查是否存在在緩存服務器中命中該SQL
三、服務器端進行SQL解析，預處理，再由優化器對應執行計劃
四、根據執行計劃，調用存儲引擎API來查詢數據
五、將結果返回給客戶端

查詢緩存對SQL性能的影響

一、優先檢查整個查詢是否命中查詢緩存中的數據
二、經過一個對大小寫敏感的哈希查找實現的

查詢緩存的優化參數

query_cache_type  設置查詢緩存是否可用
    ON，OFF，DEMAND

    注意：DEMAND表示只有在查詢語句中使用SQL——CACHE和SQL_NO_CACHE來控制是否須要緩存
    
query_cache_size   設置查詢緩存的內存大小

query_cache_limit   設置查詢緩存可用存儲的最大值

query_cache_wlock_invalidate    設置數據表被鎖後是否返回緩存中的數據(默認是關閉的，建議也是關閉的此選項)

query_cache_min_res_unit   設置查詢緩存分配的內存塊最小的值

會形成MySQL生成錯誤的執行計劃的緣由

一、統計信息不許確
二、執行計劃中的成本估算不等同於實際的執行計劃的成本
三、MySQL優化器所認爲的最優可能與你所認爲的最優不同 
四、MySQL從不考慮其餘併發的查詢，這可能會影響當前查詢數據
五、MySQL有時候也會基於一些固定的規則來生成執行計劃
六、MySQL不會考慮不受其控制的成本

MySQL優化器可優化的SQL類型

一、從新定義表的關聯順序
    優化器會根據統計信息來決定表的關聯順序

二、將外連接轉換成內鏈接
    where條件和庫表結構等

三、使用等價變換規則
    (5=5 and a > 5)將會被改寫成 a > 5

四、優化count(), min()和max()
    select tables optimized away
    優化器已經從執行計劃中移除了該表，並以一個常數取而代之

五、將一個表達式轉換爲常數表達式

六、使用等價變換規則

七、子查詢優化

八、對in()條件進行優化

如何肯定查詢處理各個階段所消耗的時間

使用profile

    set profiling = 1;
執行查詢：
    show profiles;

    show profile for query N;
    查詢的每一個階段所消耗的時間

使用profile查看語句所消耗的時間

特定的SQL查詢優化

一、利用主從切換的原理進行大表的表結構修改，例如，如今從服務器上修改，修改完畢之後，進行主從切換，再在原來老的主上進行大表的修改，存在必定的風險。
二、在主服務器上建立於一個新的表，表結構就是將要修改大表後表結構，再把老表的數據從新導入到新表中，並在老表中創建一系列的觸發器，把老表的數據同步更新到新表中，當老表中的數據所有同步到新表之後，再對老表加排它鎖，把新表改爲老表的名稱，刪除重命名的老表，以下圖所示

使用pt-online-schema-change命令來修改大表，具體操做以下圖所示

上圖的參數解釋

--alter       所使用的sql語句
    --user        數據庫的登陸用戶
    --password    登陸用戶的密碼
    D             指定全部修改表的數據庫名稱
    t             表的名稱
    --charset     指定數據庫的字符串
    --excute      執行

原創做品，轉載請註明出處：http://www.cnblogs.com/demon89/p/8508433.html