注意： 這樣配置是臨時的如果需要永久修改需要去配置文件(/etc/my.cnf)

explain查看分析SQL執(zhí)行計劃

通過慢查詢?nèi)罩径ㄎ怀霾樵冃瘦^低的SQL，可以使用explain查看SQL的執(zhí)行計劃

id

1. id 值相同時，被視為一組從上向下執(zhí)行。
2. 如果是子查詢，id 值會遞增，id 值越高，優(yōu)先級越高
3. id為NULL最后執(zhí)行

select_type

1. simple: 簡單的select, 查詢中不包含子查詢或者 union。例如: select name from student where id= 100
2. primary: 子查詢中最外層查詢, 查詢中若包含任何復(fù)雜的子部分, 最外層的select被標(biāo)記為primary
3. derived：在 from 的列表中包含的子查詢被標(biāo)記成 derived（派生表）。例如: explain select id from (select id,name from student) student1 where name= ‘name100’
4. subquery：在 select 或 where 列表中包含了子查詢，則子查詢被標(biāo)記成 subquery。例如: explain select id from student where score = (select score from student where
name=‘name100’);
5. union: union中的第二個或后面的select語句. 例如: EXPLAIN select id from student where id<12691055 UNION all select id from student where id<12691060;

table

顯示這一步所訪問數(shù)據(jù)庫中表名稱. 有時候不是真實的表名, 可能是簡稱

partitions

該字段看table所在的分區(qū), 值為NULL表示表未被分區(qū)

possible_keys

可能會使用到的索引(ps.其實不太重要)

重點關(guān)注的字段
type

表示連接類型，查看索引執(zhí)行情況的一個重要指標(biāo) 以下性能從好到壞依次：system > const > eq_ref > ref >
ref_or_null > index_merge > unique_subquery > index_subquery > range >
index > ALL
system：這種類型要求數(shù)據(jù)庫表中只有一條數(shù)據(jù)，是const類型的一個特例，一般情況下是不會出現(xiàn)的
const：通過一次索引就能找到數(shù)據(jù)，一般用于主鍵或唯一索引作為條件，這類掃描效率極高，速度非?？?br> eq_ref：常用于主鍵或唯一索引掃描，一般指使用主鍵的關(guān)聯(lián)查詢 ref : 常用于非主鍵和唯一索引掃描
ref_or_null：這種連接類型類似于ref，區(qū)別在于MySQL會額外搜索包含NULL值的行
index_merge：使用了索引合并優(yōu)化方法，查詢使用了兩個以上的索引
unique_subquery：類似于eq_ref，條件用了in子查詢
index_subquery：區(qū)別于unique_subquery，用于非唯一索引，可以返回重復(fù)值
range：常用于范圍查詢，比如：between … and 或 In 等操作 index：全索引掃描 ALL：全表掃描

key

實際使用到的索引

key_len

實際使用到的索引的長度

rows

該列表示MySQL估算找到我們所需的記錄，需要讀取的行數(shù)

filtered

該列是一個百分比，是滿足條件的記錄數(shù)量與我們查詢了多少記錄數(shù)量的比值

extra

該字段包含有關(guān)MySQL如何解析查詢的其他信息，它一般會出現(xiàn)這幾個值：
● Usingfilesort：表示按文件排序，一般是在指定的排序和索引排序不一致的情況才會出現(xiàn)，一般見于order by語句
● Using index：表示是否用了覆蓋索引
● Using temporary: 表示是否使用了臨時表,性能特別差，需要重點優(yōu)化，一般多見于groupby語句，或者union語句
● Using where : 表示使用了where條件過濾
● Using index condition：MySQL5.6之后新增的索引下推，在存儲引擎層進(jìn)行數(shù)據(jù)過濾，而不是在服務(wù)層過濾，利用索引現(xiàn)有的數(shù)據(jù)減少回表的數(shù)據(jù)

profile分析執(zhí)行耗時

explain只是看到SQL預(yù)估的執(zhí)行計劃，如果要了解SQL真正的執(zhí)行線程狀態(tài)及消耗的時間，需要使用profiling，開啟profiling參數(shù)后，后續(xù)執(zhí)行的SQL語句都會記錄其資源開銷，包括IO，上下文切換，CPU，內(nèi)存等等，可以根據(jù)這些開銷進(jìn)一步分析當(dāng)前慢SQL的瓶頸再進(jìn)一步進(jìn)行優(yōu)化

Optimizer Trace分析詳情

profile只能查看到SQL的執(zhí)行耗時，但無法看到SQL真正執(zhí)行的過程信息，不知道MySQL優(yōu)化器是如何選擇執(zhí)行計劃，這時候，可以使用Optimizer
Trace，它可以跟蹤執(zhí)行語句的解析優(yōu)化執(zhí)行的全過程

三個階段分為對應(yīng)：準(zhǔn)備階段、分析階段、執(zhí)行階段

確定問題采用響應(yīng)措施

● 多數(shù)慢SQL都跟索引有關(guān)，比如不加索引，索引不生效、不合理等，這時候，可以優(yōu)化索引
● 還可以優(yōu)化SQL語句，比如一些in元素過多問題(分批)，深分頁問題(基于上一次數(shù)據(jù)過濾等)，進(jìn)行時間分段查詢
● SQL沒辦法很好優(yōu)化，可以改用ES的方式，或者數(shù)倉
● 如果單表數(shù)據(jù)量過大導(dǎo)致慢查詢，可以考慮分庫分表
● 如果數(shù)據(jù)庫在刷臟頁導(dǎo)致慢查詢，考慮是否可以優(yōu)化一些參數(shù)
● 如果存量數(shù)據(jù)量太大，考慮是否可以讓部分?jǐn)?shù)據(jù)歸檔文章來源地址http://www.zghlxwxcb.cn/news/detail-472930.html

到了這里，關(guān)于MySQL-如何定位慢查詢SQL以及優(yōu)化的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！