詳細介紹Mysql性能優(yōu)化之子查詢

記得在做項目的時候, 聽到過一句話, 盡量不要使用子查詢, 那么這一篇就來看一下, 這句話是否是正確的.

那在這之前, 需要介紹一些概念性東西和mysql對語句的大致處理.

當Mysql Server的連接線程接收到Client發(fā)送過來的SQL請求后, 會經(jīng)過一系列的分解Parse, 進行相應的分析, 然后Mysql會通過查詢優(yōu)化器模塊, 根據(jù)該Sql所涉及到的數(shù)據(jù)表的相關(guān)統(tǒng)計信息進行計算分析. 然后在得出一個Mysql自認為最合理最優(yōu)化的數(shù)據(jù)訪問方式, 也就是我們常說的”執(zhí)行計劃“, 然后根據(jù)所得到的執(zhí)行計劃通過調(diào)用存儲引擎接口來獲取相應數(shù)據(jù). 再對存儲引擎返回的數(shù)據(jù)進行相關(guān)的處理, 并一Client端所要求的格式作為結(jié)果集, 返回給Client.

注 : 這里所說的統(tǒng)計數(shù)據(jù), 是我們通過 Analyze table命令通知Mysql對表的相關(guān)數(shù)據(jù)作分析之后, 所獲取到的一些數(shù)據(jù)統(tǒng)計量. 這些數(shù)據(jù)對Mysql優(yōu)化器而言是非常重要的, 優(yōu)化器所生成的執(zhí)行計劃的好壞, 主要是由這些統(tǒng)計數(shù)據(jù)所決定的.

1. 建表

create?table?User(    Id?int?not?null?PRIMARY?key?auto_increment?,    NickName?varchar(50)?comment?'用戶昵稱',    Sex?int?comment?'性別',    Sign?varchar(50)?comment?'用戶簽名',    Birthday?datetime?comment?'用戶生日',    CreateTime?datetime?comment?'創(chuàng)建時間')?default?charset=utf8?comment?'用戶表';create?table?UserGroup(    Id?int?not?null?PRIMARY?key?auto_increment?,    UserId?int?not?null?comment?'user?Id',    GroupId?int?not?null?comment?'用戶組Id',    CreateTime?datetime?comment?'創(chuàng)建時間',    --?key?index_groupid(GroupId)?using?btree,  key?index_userid(groupid,?UserId)?using?btree  )?default?charset=utf8?comment?'用戶組表';

2. 準備數(shù)據(jù)

var?conStr?=?ConfigurationManager.ConnectionStrings["ConStr"].ToString();  using?(IDbConnection?conn?=?new?MySqlConnection(conStr))  {  ????Stopwatch?watch?=?new?Stopwatch();  ????var?sql?=?string.Empty;  ????var?names?=?new?string[]?{?"非",?"想",?"紅",?"帝",?"德",?"看",?"梅",?"插",?"兔"?};  ????Random?ran?=?new?Random();??  ????var?insertSql?=?@"?insert?into?User(NickName,Sex,Sign,?Birthday,?CreateTime)?values(@NickName,@Sex,@Sign,?@Birthday,?@CreateTime);?  ????INSERT?INTO?usergroup??(UserId,??GroupId,??CreateTime?)??VALUES?(LAST_INSERT_ID()?,???@GroupId,??@CreateTime);";  ????watch.Start();  ????if?(conn.State?==?ConnectionState.Closed)  ????{  ????????conn.Open();  ????}    ????var?tran?=?conn.BeginTransaction();  ????for?(int?i?=?0;?i?<p>這里我插入了5000條數(shù)據(jù), group分了99個組, 隨機的.?</p><p>3. 查詢sql</p><pre class="brush:sql;toolbar:false">explain  select?user.id,?user.nickname?from?usergroup?  left?join?user??on?usergroup.UserId?=?user.Id  where??usergroup.groupid?=?1?  order?by?usergroup.UserId?desc  limit?100,?20;    ?explain  select?user.id,?user.nickname  from?(select?id,?userid?from?usergroup?where?groupid?=?1?order?by?userid?limit?100,?20)?t  left?join??user?on?t.UserId?=?user.id?;    ?explain  select?user.id,?user.nickname  from?(select?id,?userid?from?usergroup?where?groupid?=?1?order?by?userid?)?t  left?join??user?on?t.UserId?=?user.id?  limit?100,?20;

第二句和第三句都使用到了子查詢, 不同之處再與, 第二句是先得到20條數(shù)據(jù), 然后以此來與user表關(guān)聯(lián)的

4. 分析

100000條數(shù)據(jù)情況下 :?

先看第一句

詳細介紹Mysql性能優(yōu)化之子查詢

再看第二句

詳細介紹Mysql性能優(yōu)化之子查詢

第三句

詳細介紹Mysql性能優(yōu)化之子查詢

從上面三幅圖看, 好像能看出點什么了.

首先看他們的 rows, 第二句最多, 加起來有1000多了, 另兩句加起來都是996. 但是我想說的是, 這里并不是看rows的和是多少. 正確的方式是, 從id大的語句開始看, id相同的語句, 從上到下依次執(zhí)行.

那先看第二句的id=2的語句和第一句的id=1的語句, 一模一樣的. 他們都是從usergroup表中篩選數(shù)據(jù), 并且能得到相同的結(jié)果集A.

看來他們都是基于相同的結(jié)果集去進行操作, 接下來就有區(qū)別了.

先看第一句, 再結(jié)果集A的基礎(chǔ)上, 去左連接表user, 并篩選出最后的數(shù)據(jù), 返回給客戶端.

那第二句呢, 是在A的基礎(chǔ)上, 再次篩選數(shù)據(jù), 得到需要的數(shù)據(jù), 然后拿這些數(shù)據(jù), 去與user表左連接, 得到最終結(jié)果.

從上面來看, 執(zhí)行計劃中, 第二種執(zhí)行計劃, 更加高效.?

?如果能夠通過子查詢, 大幅度縮小查詢范圍, 可以考慮使用子查詢語句.?

? 版權(quán)聲明
THE END
喜歡就支持一下吧
點贊8 分享