1 Star 0 Fork 59

尘飞扬 / mysql45

forked from funnylog / mysql45 
加入 Gitee
与超过 1200万 开发者一起发现、参与优秀开源项目,私有仓库也完全免费 :)
免费加入
该仓库未声明开源许可证文件(LICENSE),使用请关注具体项目描述及其代码上游依赖。
克隆/下载
16讲“orderby”是怎么工作的.html 74.56 KB
一键复制 编辑 原始数据 按行查看 历史
funnylog 提交于 2020-09-18 15:06 . first commit
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<meta name="viewport"
content="width=device-width,initial-scale=1,maximum-scale=1,minimum-scale=1,user-scalable=no,viewport-fit=cover">
<meta name="format-detection" content="telephone=no">
<style type="text/css">
#watermark {
position: relative;
overflow: hidden;
}
#watermark .x {
position: absolute;
top: 800;
left: 400;
color: #3300ff;
font-size: 50px;
pointer-events: none;
opacity:0.3;
filter:Alpha(opacity=50);
}
</style>
<style type="text/css">
html{color:#333;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%;text-rendering:optimizelegibility;font-family:Helvetica Neue,PingFang SC,Verdana,Microsoft Yahei,Hiragino Sans GB,Microsoft Sans Serif,WenQuanYi Micro Hei,sans-serif}html.borderbox *,html.borderbox :after,html.borderbox :before{box-sizing:border-box}article,aside,blockquote,body,button,code,dd,details,dl,dt,fieldset,figcaption,figure,footer,form,h1,h2,h3,h4,h5,h6,header,hr,input,legend,li,menu,nav,ol,p,pre,section,td,textarea,th,ul{margin:0;padding:0}article,aside,details,figcaption,figure,footer,header,menu,nav,section{display:block}audio,canvas,video{display:inline-block}body,button,input,select,textarea{font:300 1em/1.8 PingFang SC,Lantinghei SC,Microsoft Yahei,Hiragino Sans GB,Microsoft Sans Serif,WenQuanYi Micro Hei,Helvetica,sans-serif}button::-moz-focus-inner,input::-moz-focus-inner{padding:0;border:0}table{border-collapse:collapse;border-spacing:0}fieldset,img{border:0}blockquote{position:relative;color:#999;font-weight:400;border-left:1px solid #1abc9c;padding-left:1em;margin:1em 3em 1em 2em}@media only screen and (max-width:640px){blockquote{margin:1em 0}}abbr,acronym{border-bottom:1px dotted;font-variant:normal}abbr{cursor:help}del{text-decoration:line-through}address,caption,cite,code,dfn,em,th,var{font-style:normal;font-weight:400}ol,ul{list-style:none}caption,th{text-align:left}q:after,q:before{content:""}sub,sup{font-size:75%;line-height:0;position:relative}:root sub,:root sup{vertical-align:baseline}sup{top:-.5em}sub{bottom:-.25em}a{color:#1abc9c}a:hover{text-decoration:underline}.typo a{border-bottom:1px solid #1abc9c}.typo a:hover{border-bottom-color:#555;color:#555}.typo a:hover,a,ins{text-decoration:none}.typo-u,u{text-decoration:underline}mark{background:#fffdd1;border-bottom:1px solid #ffedce;padding:2px;margin:0 5px}code,pre,pre tt{font-family:Courier,Courier New,monospace}pre{background:hsla(0,0%,97%,.7);border:1px solid #ddd;padding:1em 1.5em;display:block;-webkit-overflow-scrolling:touch}hr{border:none;border-bottom:1px solid #cfcfcf;margin-bottom:.8em;height:10px}.typo-small,figcaption,small{font-size:.9em;color:#888}b,strong{font-weight:700;color:#000}[draggable]{cursor:move}.clearfix:after,.clearfix:before{content:"";display:table}.clearfix:after{clear:both}.clearfix{zoom:1}.textwrap,.textwrap td,.textwrap th{word-wrap:break-word;word-break:break-all}.textwrap-table{table-layout:fixed}.serif{font-family:Palatino,Optima,Georgia,serif}.typo-dl,.typo-form,.typo-hr,.typo-ol,.typo-p,.typo-pre,.typo-table,.typo-ul,.typo dl,.typo form,.typo hr,.typo ol,.typo p,.typo pre,.typo table,.typo ul,blockquote{margin-bottom:1rem}h1,h2,h3,h4,h5,h6{font-family:PingFang SC,Helvetica Neue,Verdana,Microsoft Yahei,Hiragino Sans GB,Microsoft Sans Serif,WenQuanYi Micro Hei,sans-serif;color:#000;line-height:1.35}.typo-h1,.typo-h2,.typo-h3,.typo-h4,.typo-h5,.typo-h6,.typo h1,.typo h2,.typo h3,.typo h4,.typo h5,.typo h6{margin-top:1.2em;margin-bottom:.6em;line-height:1.35}.typo-h1,.typo h1{font-size:2em}.typo-h2,.typo h2{font-size:1.8em}.typo-h3,.typo h3{font-size:1.6em}.typo-h4,.typo h4{font-size:1.4em}.typo-h5,.typo-h6,.typo h5,.typo h6{font-size:1.2em}.typo-ul,.typo ul{margin-left:1.3em;list-style:disc}.typo-ol,.typo ol{list-style:decimal;margin-left:1.9em}.typo-ol ol,.typo-ol ul,.typo-ul ol,.typo-ul ul,.typo li ol,.typo li ul{margin-bottom:.8em;margin-left:2em}.typo-ol ul,.typo-ul ul,.typo li ul{list-style:circle}.typo-table td,.typo-table th,.typo table caption,.typo table td,.typo table th{border:1px solid #ddd;padding:.5em 1em;color:#666}.typo-table th,.typo table th{background:#fbfbfb}.typo-table thead th,.typo table thead th{background:hsla(0,0%,95%,.7)}.typo table caption{border-bottom:none}.typo-input,.typo-textarea{-webkit-appearance:none;border-radius:0}.typo-em,.typo em,caption,legend{color:#000;font-weight:inherit}.typo-em{position:relative}.typo-em:after{position:absolute;top:.65em;left:0;width:100%;overflow:hidden;white-space:nowrap;content:"\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB"}.typo img{max-width:100%}.common-content{font-weight:400;color:#353535;line-height:1.75rem;white-space:normal;word-break:normal;font-size:1rem}.common-content img{display:block;max-width:100%;background-color:#eee}.common-content audio,.common-content video{width:100%;background-color:#eee}.common-content center,.common-content font{margin-top:1rem;display:inline-block}.common-content center{width:100%}.common-content pre{margin-top:1rem;padding-left:0;padding-right:0;position:relative;overflow:hidden}.common-content pre code{font-size:.8rem;font-family:Consolas,Liberation Mono,Menlo,monospace,Courier;display:block;width:100%;box-sizing:border-box;padding-left:1rem;padding-right:1rem;overflow-x:auto}.common-content hr{border:none;margin-top:1.5rem;margin-bottom:1.5rem;border-top:1px solid #f5f5f5;height:1px;background:none}.common-content b,.common-content h1,.common-content h2,.common-content h3,.common-content h4,.common-content h5,.common-content strong{font-weight:700}.common-content h1,.common-content h2{font-size:1.125rem;margin-bottom:.45rem}.common-content h3,.common-content h4,.common-content h5{font-size:1rem;margin-bottom:.45rem}.common-content p{font-weight:400;color:#353535;margin-top:.15rem}.common-content .orange{color:#ff5a05}.common-content .reference{font-size:1rem;color:#888}.custom-rich-content h1{margin-top:0;font-weight:400;font-size:15.25px;border-bottom:1px solid #eee;line-height:2.8}.custom-rich-content li,.custom-rich-content p{font-size:14px;color:#888;line-height:1.6}table.hljs-ln{margin-bottom:0;border-spacing:0;border-collapse:collapse}table.hljs-ln,table.hljs-ln tbody,table.hljs-ln td,table.hljs-ln tr{box-sizing:border-box}table.hljs-ln td{padding:0;border:0}table.hljs-ln td.hljs-ln-numbers{min-width:15px;color:rgba(27,31,35,.3);text-align:right;white-space:nowrap;cursor:pointer;user-select:none}table.hljs-ln td.hljs-ln-code,table.hljs-ln td.hljs-ln-numbers{font-family:SFMono-Regular,Consolas,Liberation Mono,Menlo,Courier,monospace;font-size:12px;line-height:20px;vertical-align:top}table.hljs-ln td.hljs-ln-code{position:relative;padding-right:10px;padding-left:10px;overflow:visible;color:#24292e;word-wrap:normal;white-space:pre}video::-webkit-media-controls{overflow:hidden!important}video::-webkit-media-controls-enclosure{width:calc(100% + 32px);margin-left:auto}.button-cancel{color:#888;border:1px solid #888;border-radius:3px;margin-right:12px}.button-cancel,.button-primary{-ms-flex-positive:1;flex-grow:1;height:35px;display:inline-block;font-size:15px;text-align:center;line-height:36px}.button-primary{color:#fff;background-color:#ff5a05;border-radius:3px}@font-face{font-family:iconfont;src:url(//at.alicdn.com/t/font_372689_bwwwtosxtzp.eot);src:url(//at.alicdn.com/t/font_372689_bwwwtosxtzp.eot#iefix) format("embedded-opentype"),url(//at.alicdn.com/t/font_372689_bwwwtosxtzp.woff) format("woff"),url(//at.alicdn.com/t/font_372689_bwwwtosxtzp.ttf) format("truetype"),url(//at.alicdn.com/t/font_372689_bwwwtosxtzp.svg#iconfont) format("svg")}@font-face{font-family:player-font;src:url(//at.alicdn.com/t/font_509397_1cyjv4o90qiod2t9.eot);src:url(//at.alicdn.com/t/font_509397_1cyjv4o90qiod2t9.eot#iefix) format("embedded-opentype"),url(//at.alicdn.com/t/font_509397_1cyjv4o90qiod2t9.woff) format("woff"),url(//at.alicdn.com/t/font_509397_1cyjv4o90qiod2t9.ttf) format("truetype"),url(//at.alicdn.com/t/font_509397_1cyjv4o90qiod2t9.svg#player-font) format("svg")}.iconfont{font-family:iconfont!important;font-size:16px;font-style:normal;-webkit-font-smoothing:antialiased;-webkit-text-stroke-width:.2px;-moz-osx-font-smoothing:grayscale}html{background:#fff;min-height:100%;-webkit-tap-highlight-color:rgba(0,0,0,0)}body{width:100%}body.fixed{overflow:hidden;position:fixed;width:100vw;height:100vh}i{font-style:normal}a{word-wrap:break-word;-webkit-tap-highlight-color:rgba(0,0,0,0)}a:hover{text-decoration:none}.fade-enter-active,.fade-leave-active{transition:opacity .3s}.fade-enter,.fade-leave-to{opacity:0}.MathJax,.MathJax_CHTML,.MathJax_MathContainer,.MathJax_MathML,.MathJax_PHTML,.MathJax_PlainSource,.MathJax_SVG{outline:0}.ios-app-switch .js-audit{display:none}._loading_wrap_{position:fixed;width:100vw;height:100vh;top:50%;left:50%;transform:translate(-50%,-50%);z-index:999}._loading_div_class_,._loading_wrap_{display:-ms-flexbox;display:flex;-ms-flex-pack:center;justify-content:center;-ms-flex-align:center;align-items:center}._loading_div_class_{word-wrap:break-word;padding:.5rem .75rem;text-align:center;z-index:9999;font-size:.6rem;max-width:60%;color:#fff;border-radius:.25rem;-ms-flex-direction:column;flex-direction:column}._loading_div_class_ .message{color:#353535;font-size:16px;line-height:3}.spinner{animation:circle-rotator 1.4s linear infinite}.spinner *{line-height:0;box-sizing:border-box}@keyframes circle-rotator{0%{transform:rotate(0deg)}to{transform:rotate(270deg)}}.path{stroke-dasharray:187;stroke-dashoffset:0;transform-origin:center;animation:circle-dash 1.4s ease-in-out infinite,circle-colors 5.6s ease-in-out infinite}@keyframes circle-colors{0%{stroke:#ff5a05}to{stroke:#ff5a05}}@keyframes circle-dash{0%{stroke-dashoffset:187}50%{stroke-dashoffset:46.75;transform:rotate(135deg)}to{stroke-dashoffset:187;transform:rotate(450deg)}}.confirm-box-wrapper,.confirm-box-wrapper .mask{position:absolute;top:0;left:0;right:0;bottom:0}.confirm-box-wrapper .mask{background:rgba(0,0,0,.6)}.confirm-box-wrapper .confirm-box{position:fixed;top:50%;left:50%;width:267px;background:#fff;transform:translate(-50%,-50%);border-radius:7px}.confirm-box-wrapper .confirm-box .head{margin:0 18px;font-size:18px;text-align:center;line-height:65px;border-bottom:1px solid #d9d9d9}.confirm-box-wrapper .confirm-box .body{padding:18px;padding-bottom:0;color:#353535;font-size:12.5px;max-height:150px;overflow:auto}.confirm-box-wrapper .confirm-box .foot{display:-ms-flexbox;display:flex;-ms-flex-direction:row;flex-direction:row;padding:18px}.confirm-box-wrapper .confirm-box .foot .button-cancel{border:1px solid #d9d9d9}.hljs{display:block;overflow-x:auto;padding:.5em;color:#333;background:#f8f8f8}.hljs-comment,.hljs-quote{color:#998;font-style:italic}.hljs-keyword,.hljs-selector-tag,.hljs-subst{color:#333;font-weight:700}.hljs-literal,.hljs-number,.hljs-tag .hljs-attr,.hljs-template-variable,.hljs-variable{color:teal}.hljs-doctag,.hljs-string{color:#d14}.hljs-section,.hljs-selector-id,.hljs-title{color:#900;font-weight:700}.hljs-subst{font-weight:400}.hljs-class .hljs-title,.hljs-type{color:#458;font-weight:700}.hljs-attribute,.hljs-name,.hljs-tag{color:navy;font-weight:400}.hljs-link,.hljs-regexp{color:#009926}.hljs-bullet,.hljs-symbol{color:#990073}.hljs-built_in,.hljs-builtin-name{color:#0086b3}.hljs-meta{color:#999;font-weight:700}.hljs-deletion{background:#fdd}.hljs-addition{background:#dfd}.hljs-emphasis{font-style:italic}.hljs-strong{font-weight:700}
</style>
<style type="text/css">
.button-cancel[data-v-87ffcada]{color:#888;border:1px solid #888;border-radius:3px;margin-right:12px}.button-cancel[data-v-87ffcada],.button-primary[data-v-87ffcada]{-webkit-box-flex:1;-ms-flex-positive:1;flex-grow:1;height:35px;display:inline-block;font-size:15px;text-align:center;line-height:36px}.button-primary[data-v-87ffcada]{color:#fff;background-color:#ff5a05;border-radius:3px}.pd[data-v-87ffcada]{padding-left:1.375rem;padding-right:1.375rem}.article[data-v-87ffcada]{max-width:70rem;margin:0 auto}.article .article-unavailable[data-v-87ffcada]{color:#fa8919;font-size:15px;font-weight:600;line-height:24px;border-radius:5px;padding:12px;background-color:#f6f7fb;margin-top:20px}.article .article-unavailable .iconfont[data-v-87ffcada]{font-size:12px}.article .main[data-v-87ffcada]{padding:1.25rem 0;margin-bottom:52px}.article-title[data-v-87ffcada]{color:#353535;font-weight:400;line-height:1.65rem;font-size:1.34375rem}.article-info[data-v-87ffcada]{color:#888;font-size:.9375rem;margin-top:1.0625rem}.article-content[data-v-87ffcada]{margin-top:1.0625rem}.article-content.android video[data-v-87ffcada]::-webkit-media-controls-fullscreen-button{display:none}.copyright[data-v-87ffcada]{color:#b2b2b2;padding-bottom:20px;margin-top:20px;font-size:13px}.audio-player[data-v-87ffcada]{width:100%;margin:20px 0}.to-comment[data-v-87ffcada]{overflow:hidden;padding-top:10px;margin-bottom:-30px}.to-comment a.button-primary[data-v-87ffcada]{float:right;height:20px;font-size:12px;line-height:20px;padding:4px 8px;cursor:pointer}.article-comments[data-v-87ffcada]{margin-top:2rem}.article-comments h2[data-v-87ffcada]{text-align:center;color:#888;position:relative;z-index:1;margin-bottom:1rem}.article-comments h2[data-v-87ffcada]:before{border-top:1px dotted #888;content:"";position:absolute;top:56%;left:0;width:100%;z-index:-1}.article-comments h2 span[data-v-87ffcada]{font-size:15.25px;font-weight:400;padding:0 1rem;background:#fff;display:inline-block}.article-sub-bottom[data-v-87ffcada]{z-index:10;cursor:pointer}.switch-btns[data-v-87ffcada]{height:76px;cursor:pointer;padding-top:24px;padding-bottom:24px;border-bottom:10px solid #f6f7fb;position:relative}.switch-btns[data-v-87ffcada]:before{content:" ";height:1px;background:#e8e8e8;position:absolute;top:0;left:0;-webkit-box-sizing:border-box;box-sizing:border-box;left:1.375rem;right:1.375rem}.switch-btns .btn[data-v-87ffcada]{height:38px;display:-webkit-box;display:-ms-flexbox;display:flex;-webkit-box-align:center;-ms-flex-align:center;align-items:center}.switch-btns .btn .tag[data-v-87ffcada]{-webkit-box-flex:0;-ms-flex:0 0 62px;flex:0 0 62px;text-align:center;color:#888;font-size:14px;border-radius:10px;height:22px;line-height:22px;background:#f6f7fb;font-weight:400}.switch-btns .btn .txt[data-v-87ffcada]{margin-left:10px;-webkit-box-flex:1;-ms-flex:1 1 auto;flex:1 1 auto;color:#888;font-size:15px;height:22px;line-height:22px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;font-weight:400}@media (max-width:769px){.article .breadcrumb[data-v-87ffcada]{padding-top:10px;padding-bottom:10px}}
</style>
<style type="text/css">
.comment-item{list-style-position:inside;width:100%;display:-webkit-box;display:-ms-flexbox;display:flex;-webkit-box-orient:horizontal;-webkit-box-direction:normal;-ms-flex-direction:row;flex-direction:row;margin-bottom:1rem}.comment-item a{border-bottom:none}.comment-item .avatar{width:2.625rem;height:2.625rem;-ms-flex-negative:0;flex-shrink:0;border-radius:50%}.comment-item .info{margin-left:.5rem;-webkit-box-flex:1;-ms-flex-positive:1;flex-grow:1}.comment-item .info .hd{width:100%;display:-webkit-box;display:-ms-flexbox;display:flex;-webkit-box-orient:horizontal;-webkit-box-direction:normal;-ms-flex-direction:row;flex-direction:row;-webkit-box-pack:justify;-ms-flex-pack:justify;justify-content:space-between;-webkit-box-align:center;-ms-flex-align:center;align-items:center}.comment-item .info .hd .username{color:#888;font-size:15.25px;font-weight:400;line-height:1.2}.comment-item .info .hd .control{display:-webkit-box;display:-ms-flexbox;display:flex;-webkit-box-orient:horizontal;-webkit-box-direction:normal;-ms-flex-direction:row;flex-direction:row;-webkit-box-align:center;-ms-flex-align:center;align-items:center}.comment-item .info .hd .control .btn-share{color:#888;font-size:.75rem;margin-right:1rem}.comment-item .info .hd .control .btn-praise{display:-webkit-box;display:-ms-flexbox;display:flex;-webkit-box-orient:horizontal;-webkit-box-direction:normal;-ms-flex-direction:row;flex-direction:row;-webkit-box-align:center;-ms-flex-align:center;align-items:center;font-size:15.25px;text-decoration:none}.comment-item .info .hd .control .btn-praise i{color:#888;display:inline-block;font-size:.75rem;margin-right:.3rem;margin-top:-.01rem}.comment-item .info .hd .control .btn-praise i.on,.comment-item .info .hd .control .btn-praise span{color:#ff5a05}.comment-item .info .bd{color:#353535;font-size:15.25px;font-weight:400;white-space:normal;word-break:break-all;line-height:1.6}.comment-item .info .time{color:#888;font-size:9px;line-height:1}.comment-item .info .reply .reply-hd{font-size:15.25px}.comment-item .info .reply .reply-hd span{margin-left:-12px;color:#888;font-weight:400}.comment-item .info .reply .reply-hd i{color:#ff5a05;font-size:15.25px}.comment-item .info .reply .reply-content{color:#353535;font-size:15.25px;font-weight:400;white-space:normal;word-break:break-all}.comment-item .info .reply .reply-time{color:#888;font-size:9px}
</style>
</head>
<body>
<div id="app">
<div data-v-87ffcada="" class="article" id="watermark">
<div data-v-87ffcada="" class="main main-app">
<h1 data-v-87ffcada="" class="article-title pd">
16讲“orderby”是怎么工作的
</h1>
<div data-v-87ffcada="" class="article-content typo common-content pd"><img data-v-87ffcada=""
src="https://static001.geekbang.org/resource/image/71/37/716e55f77ce1ac695121595a1eb4d937.jpg">
<div>
<audio controls="controls" height="100" width="100">
<source src="16讲“orderby”是怎么工作的.mp3" type="audio/mp3" />
<embed height="100" width="100" src="16讲“orderby”是怎么工作的.mp3" />
</audio>
</div>
<div data-v-87ffcada="" id="article-content" class="">
<div class="text">
<p>在你开发应用的时候,一定会经常碰到需要根据指定的字段排序来显示结果的需求。还是以我们前面举例用过的市民表为例,假设你要查询城市是“杭州”的所有人名字,并且按照姓名排序返回前1000个人的姓名、年龄。</p><p>假设这个表的部分定义是这样的:</p><pre><code>CREATE TABLE `t` (
`id` int(11) NOT NULL,
`city` varchar(16) NOT NULL,
`name` varchar(16) NOT NULL,
`age` int(11) NOT NULL,
`addr` varchar(128) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `city` (`city`)
) ENGINE=InnoDB;
</code></pre><p>这时,你的SQL语句可以这么写:</p><pre><code>select city,name,age from t where city='杭州' order by name limit 1000 ;
</code></pre><p>这个语句看上去逻辑很清晰,但是你了解它的执行流程吗?今天,我就和你聊聊这个语句是怎么执行的,以及有什么参数会影响执行的行为。</p><h1>全字段排序</h1><p>前面我们介绍过索引,所以你现在就很清楚了,为避免全表扫描,我们需要在city字段加上索引。</p><p>在city字段上创建索引之后,我们用explain命令来看看这个语句的执行情况。</p><p><img src="https://static001.geekbang.org/resource/image/82/03/826579b63225def812330ef6c344a303.png" alt=""></p><center><span class="reference">图1 使用explain命令查看语句的执行情况</span></center><p>Extra这个字段中的“Using filesort”表示的就是需要排序,MySQL会给每个线程分配一块内存用于排序,称为sort_buffer。</p><p>为了说明这个SQL查询语句的执行过程,我们先来看一下city这个索引的示意图。</p><p><img src="https://static001.geekbang.org/resource/image/53/3e/5334cca9118be14bde95ec94b02f0a3e.png" alt=""></p><center><span class="reference">图2 city字段的索引示意图</span></center><p>从图中可以看到,满足city='杭州’条件的行,是从ID_X到ID_(X+N)的这些记录。</p><p>通常情况下,这个语句执行流程如下所示 :</p><!-- [[[read_end]]] --><ol>
<li>
<p>初始化sort_buffer,确定放入name、city、age这三个字段;</p>
</li>
<li>
<p>从索引city找到第一个满足city='杭州’条件的主键id,也就是图中的ID_X;</p>
</li>
<li>
<p>到主键id索引取出整行,取name、city、age三个字段的值,存入sort_buffer中;</p>
</li>
<li>
<p>从索引city取下一个记录的主键id;</p>
</li>
<li>
<p>重复步骤3、4直到city的值不满足查询条件为止,对应的主键id也就是图中的ID_Y;</p>
</li>
<li>
<p>对sort_buffer中的数据按照字段name做快速排序;</p>
</li>
<li>
<p>按照排序结果取前1000行返回给客户端。</p>
</li>
</ol><p>我们暂且把这个排序过程,称为全字段排序,执行流程的示意图如下所示,下一篇文章中我们还会用到这个排序。</p><p><img src="https://static001.geekbang.org/resource/image/6c/72/6c821828cddf46670f9d56e126e3e772.jpg" alt=""></p><center><span class="reference">图3 全字段排序</span></center><p>图中“按name排序”这个动作,可能在内存中完成,也可能需要使用外部排序,这取决于排序所需的内存和参数sort_buffer_size。</p><p>sort_buffer_size,就是MySQL为排序开辟的内存(sort_buffer)的大小。如果要排序的数据量小于sort_buffer_size,排序就在内存中完成。但如果排序数据量太大,内存放不下,则不得不利用磁盘临时文件辅助排序。</p><p>你可以用下面介绍的方法,来确定一个排序语句是否使用了临时文件。</p><pre><code>/* 打开optimizer_trace,只对本线程有效 */
SET optimizer_trace='enabled=on';
/* @a保存Innodb_rows_read的初始值 */
select VARIABLE_VALUE into @a from performance_schema.session_status where variable_name = 'Innodb_rows_read';
/* 执行语句 */
select city, name,age from t where city='杭州' order by name limit 1000;
/* 查看 OPTIMIZER_TRACE 输出 */
SELECT * FROM `information_schema`.`OPTIMIZER_TRACE`\G
/* @b保存Innodb_rows_read的当前值 */
select VARIABLE_VALUE into @b from performance_schema.session_status where variable_name = 'Innodb_rows_read';
/* 计算Innodb_rows_read差值 */
select @b-@a;
</code></pre><p>这个方法是通过查看 OPTIMIZER_TRACE 的结果来确认的,你可以从 number_of_tmp_files中看到是否使用了临时文件。</p><p><img src="https://static001.geekbang.org/resource/image/89/95/89baf99cdeefe90a22370e1d6f5e6495.png" alt=""></p><center><span class="reference">图4 全排序的OPTIMIZER_TRACE部分结果</span></center><p>number_of_tmp_files表示的是,排序过程中使用的临时文件数。你一定奇怪,为什么需要12个文件?内存放不下时,就需要使用外部排序,外部排序一般使用归并排序算法。可以这么简单理解,<strong>MySQL将需要排序的数据分成12份,每一份单独排序后存在这些临时文件中。然后把这12个有序文件再合并成一个有序的大文件。</strong></p><p>如果sort_buffer_size超过了需要排序的数据量的大小,number_of_tmp_files就是0,表示排序可以直接在内存中完成。</p><p>否则就需要放在临时文件中排序。sort_buffer_size越小,需要分成的份数越多,number_of_tmp_files的值就越大。</p><p>接下来,我再和你解释一下图4中其他两个值的意思。</p><p>我们的示例表中有4000条满足city='杭州’的记录,所以你可以看到 examined_rows=4000,表示参与排序的行数是4000行。</p><p>sort_mode 里面的packed_additional_fields的意思是,排序过程对字符串做了“紧凑”处理。即使name字段的定义是varchar(16),在排序过程中还是要按照实际长度来分配空间的。</p><p>同时,最后一个查询语句select @b-@a 的返回结果是4000,表示整个执行过程只扫描了4000行。</p><p>这里需要注意的是,为了避免对结论造成干扰,我把internal_tmp_disk_storage_engine设置成MyISAM。否则,select @b-@a的结果会显示为4001。</p><p>这是因为查询OPTIMIZER_TRACE这个表时,需要用到临时表,而internal_tmp_disk_storage_engine的默认值是InnoDB。如果使用的是InnoDB引擎的话,把数据从临时表取出来的时候,会让Innodb_rows_read的值加1。</p><h1>rowid排序</h1><p>在上面这个算法过程里面,只对原表的数据读了一遍,剩下的操作都是在sort_buffer和临时文件中执行的。但这个算法有一个问题,就是如果查询要返回的字段很多的话,那么sort_buffer里面要放的字段数太多,这样内存里能够同时放下的行数很少,要分成很多个临时文件,排序的性能会很差。</p><p>所以如果单行很大,这个方法效率不够好。</p><p>那么,<strong>如果MySQL认为排序的单行长度太大会怎么做呢?</strong></p><p>接下来,我来修改一个参数,让MySQL采用另外一种算法。</p><pre><code>SET max_length_for_sort_data = 16;
</code></pre><p>max_length_for_sort_data,是MySQL中专门控制用于排序的行数据的长度的一个参数。它的意思是,如果单行的长度超过这个值,MySQL就认为单行太大,要换一个算法。</p><p>city、name、age 这三个字段的定义总长度是36,我把max_length_for_sort_data设置为16,我们再来看看计算过程有什么改变。</p><p>新的算法放入sort_buffer的字段,只有要排序的列(即name字段)和主键id。</p><p>但这时,排序的结果就因为少了city和age字段的值,不能直接返回了,整个执行流程就变成如下所示的样子:</p><ol>
<li>
<p>初始化sort_buffer,确定放入两个字段,即name和id;</p>
</li>
<li>
<p>从索引city找到第一个满足city='杭州’条件的主键id,也就是图中的ID_X;</p>
</li>
<li>
<p>到主键id索引取出整行,取name、id这两个字段,存入sort_buffer中;</p>
</li>
<li>
<p>从索引city取下一个记录的主键id;</p>
</li>
<li>
<p>重复步骤3、4直到不满足city='杭州’条件为止,也就是图中的ID_Y;</p>
</li>
<li>
<p>对sort_buffer中的数据按照字段name进行排序;</p>
</li>
<li>
<p>遍历排序结果,取前1000行,并按照id的值回到原表中取出city、name和age三个字段返回给客户端。</p>
</li>
</ol><p>这个执行流程的示意图如下,我把它称为rowid排序。</p><p><img src="https://static001.geekbang.org/resource/image/dc/6d/dc92b67721171206a302eb679c83e86d.jpg" alt=""></p><center><span class="reference">图5 rowid排序</span></center><p>对比图3的全字段排序流程图你会发现,rowid排序多访问了一次表t的主键索引,就是步骤7。</p><p>需要说明的是,最后的“结果集”是一个逻辑概念,实际上MySQL服务端从排序后的sort_buffer中依次取出id,然后到原表查到city、name和age这三个字段的结果,不需要在服务端再耗费内存存储结果,是直接返回给客户端的。</p><p>根据这个说明过程和图示,你可以想一下,这个时候执行select @b-@a,结果会是多少呢?</p><p>现在,我们就来看看结果有什么不同。</p><p>首先,图中的examined_rows的值还是4000,表示用于排序的数据是4000行。但是select @b-@a这个语句的值变成5000了。</p><p>因为这时候除了排序过程外,在排序完成后,还要根据id去原表取值。由于语句是limit 1000,因此会多读1000行。</p><p><img src="https://static001.geekbang.org/resource/image/27/9b/27f164804d1a4689718291be5d10f89b.png" alt=""></p><center><span class="reference">图6 rowid排序的OPTIMIZER_TRACE部分输出</span></center><p>从OPTIMIZER_TRACE的结果中,你还能看到另外两个信息也变了。</p><ul>
<li>sort_mode变成了&lt;sort_key, rowid&gt;,表示参与排序的只有name和id这两个字段。</li>
<li>number_of_tmp_files变成10了,是因为这时候参与排序的行数虽然仍然是4000行,但是每一行都变小了,因此需要排序的总数据量就变小了,需要的临时文件也相应地变少了。</li>
</ul><h1>全字段排序 VS rowid排序</h1><p>我们来分析一下,从这两个执行流程里,还能得出什么结论。</p><p>如果MySQL实在是担心排序内存太小,会影响排序效率,才会采用rowid排序算法,这样排序过程中一次可以排序更多行,但是需要再回到原表去取数据。</p><p>如果MySQL认为内存足够大,会优先选择全字段排序,把需要的字段都放到sort_buffer中,这样排序后就会直接从内存里面返回查询结果了,不用再回到原表去取数据。</p><p>这也就体现了MySQL的一个设计思想:<strong>如果内存够,就要多利用内存,尽量减少磁盘访问。</strong></p><p>对于InnoDB表来说,rowid排序会要求回表多造成磁盘读,因此不会被优先选择。</p><p>这个结论看上去有点废话的感觉,但是你要记住它,下一篇文章我们就会用到。</p><p>看到这里,你就了解了,MySQL做排序是一个成本比较高的操作。那么你会问,是不是所有的order by都需要排序操作呢?如果不排序就能得到正确的结果,那对系统的消耗会小很多,语句的执行时间也会变得更短。</p><p>其实,并不是所有的order by语句,都需要排序操作的。从上面分析的执行过程,我们可以看到,MySQL之所以需要生成临时表,并且在临时表上做排序操作,<strong>其原因是原来的数据都是无序的。</strong></p><p>你可以设想下,如果能够保证从city这个索引上取出来的行,天然就是按照name递增排序的话,是不是就可以不用再排序了呢?</p><p>确实是这样的。</p><p>所以,我们可以在这个市民表上创建一个city和name的联合索引,对应的SQL语句是:</p><pre><code>alter table t add index city_user(city, name);
</code></pre><p>作为与city索引的对比,我们来看看这个索引的示意图。</p><p><img src="https://static001.geekbang.org/resource/image/f9/bf/f980201372b676893647fb17fac4e2bf.png" alt=""></p><center><span class="reference">图7 city和name联合索引示意图</span></center><p>在这个索引里面,我们依然可以用树搜索的方式定位到第一个满足city='杭州’的记录,并且额外确保了,接下来按顺序取“下一条记录”的遍历过程中,只要city的值是杭州,name的值就一定是有序的。</p><p>这样整个查询过程的流程就变成了:</p><ol>
<li>
<p>从索引(city,name)找到第一个满足city='杭州’条件的主键id;</p>
</li>
<li>
<p>到主键id索引取出整行,取name、city、age三个字段的值,作为结果集的一部分直接返回;</p>
</li>
<li>
<p>从索引(city,name)取下一个记录主键id;</p>
</li>
<li>
<p>重复步骤2、3,直到查到第1000条记录,或者是不满足city='杭州’条件时循环结束。</p>
</li>
</ol><p><img src="https://static001.geekbang.org/resource/image/3f/92/3f590c3a14f9236f2d8e1e2cb9686692.jpg" alt=""></p><center><span class="reference">图8 引入(city,name)联合索引后,查询语句的执行计划</span></center><p>可以看到,这个查询过程不需要临时表,也不需要排序。接下来,我们用explain的结果来印证一下。</p><p><img src="https://static001.geekbang.org/resource/image/fc/8a/fc53de303811ba3c46d344595743358a.png" alt=""></p><center><span class="reference">图9 引入(city,name)联合索引后,查询语句的执行计划</span></center><p>从图中可以看到,Extra字段中没有Using filesort了,也就是不需要排序了。而且由于(city,name)这个联合索引本身有序,所以这个查询也不用把4000行全都读一遍,只要找到满足条件的前1000条记录就可以退出了。也就是说,在我们这个例子里,只需要扫描1000次。</p><p>既然说到这里了,我们再往前讨论,<strong>这个语句的执行流程有没有可能进一步简化呢?</strong>不知道你还记不记得,我在第5篇文章<a href="https://time.geekbang.org/column/article/69636">《 深入浅出索引(下)》</a>中,和你介绍的覆盖索引。</p><p>这里我们可以再稍微复习一下。<strong>覆盖索引是指,索引上的信息足够满足查询请求,不需要再回到主键索引上去取数据。</strong></p><p>按照覆盖索引的概念,我们可以再优化一下这个查询语句的执行流程。</p><p>针对这个查询,我们可以创建一个city、name和age的联合索引,对应的SQL语句就是:</p><pre><code>alter table t add index city_user_age(city, name, age);
</code></pre><p>这时,对于city字段的值相同的行来说,还是按照name字段的值递增排序的,此时的查询语句也就不再需要排序了。这样整个查询语句的执行流程就变成了:</p><ol>
<li>
<p>从索引(city,name,age)找到第一个满足city='杭州’条件的记录,取出其中的city、name和age这三个字段的值,作为结果集的一部分直接返回;</p>
</li>
<li>
<p>从索引(city,name,age)取下一个记录,同样取出这三个字段的值,作为结果集的一部分直接返回;</p>
</li>
<li>
<p>重复执行步骤2,直到查到第1000条记录,或者是不满足city='杭州’条件时循环结束。</p>
</li>
</ol><p><img src="https://static001.geekbang.org/resource/image/df/d6/df4b8e445a59c53df1f2e0f115f02cd6.jpg" alt=""></p><center><span class="reference">图10 引入(city,name,age)联合索引后,查询语句的执行流程</span></center><p>然后,我们再来看看explain的结果。</p><p><img src="https://static001.geekbang.org/resource/image/9e/23/9e40b7b8f0e3f81126a9171cc22e3423.png" alt=""></p><center><span class="reference">图11 引入(city,name,age)联合索引后,查询语句的执行计划</span></center><p>可以看到,Extra字段里面多了“Using index”,表示的就是使用了覆盖索引,性能上会快很多。</p><p>当然,这里并不是说要为了每个查询能用上覆盖索引,就要把语句中涉及的字段都建上联合索引,毕竟索引还是有维护代价的。这是一个需要权衡的决定。</p><h1>小结</h1><p>今天这篇文章,我和你介绍了MySQL里面order by语句的几种算法流程。</p><p>在开发系统的时候,你总是不可避免地会使用到order by语句。你心里要清楚每个语句的排序逻辑是怎么实现的,还要能够分析出在最坏情况下,每个语句的执行对系统资源的消耗,这样才能做到下笔如有神,不犯低级错误。</p><p>最后,我给你留下一个思考题吧。</p><p>假设你的表里面已经有了city_name(city, name)这个联合索引,然后你要查杭州和苏州两个城市中所有的市民的姓名,并且按名字排序,显示前100条记录。如果SQL查询语句是这么写的 :</p><pre><code>mysql&gt; select * from t where city in ('杭州',&quot;苏州&quot;) order by name limit 100;
</code></pre><p>那么,这个语句执行的时候会有排序过程吗,为什么?</p><p>如果业务端代码由你来开发,需要实现一个在数据库端不需要排序的方案,你会怎么实现呢?</p><p>进一步地,如果有分页需求,要显示第101页,也就是说语句最后要改成 “limit 10000,100”, 你的实现方法又会是什么呢?</p><p>你可以把你的思考和观点写在留言区里,我会在下一篇文章的末尾和你讨论这个问题。感谢你的收听,也欢迎你把这篇文章分享给更多的朋友一起阅读。</p><h1>上期问题时间</h1><p>上期的问题是,当MySQL去更新一行,但是要修改的值跟原来的值是相同的,这时候MySQL会真的去执行一次修改吗?还是看到值相同就直接返回呢?</p><p>这是第一次我们课后问题的三个选项都有同学选的,所以我要和你需要详细说明一下。</p><p>第一个选项是,MySQL读出数据,发现值与原来相同,不更新,直接返回,执行结束。这里我们可以用一个锁实验来确认。</p><p>假设,当前表t里的值是(1,2)。</p><p><img src="https://static001.geekbang.org/resource/image/6d/90/6d9d8837560d01b57d252c470157ea90.png" alt=""></p><center><span class="reference">图12 锁验证方式</span></center><p>session B的update 语句被blocked了,加锁这个动作是InnoDB才能做的,所以排除选项1。</p><p>第二个选项是,MySQL调用了InnoDB引擎提供的接口,但是引擎发现值与原来相同,不更新,直接返回。有没有这种可能呢?这里我用一个可见性实验来确认。</p><p>假设当前表里的值是(1,2)。</p><p><img src="https://static001.geekbang.org/resource/image/44/96/441682b64a3f5dd50f35b12ca4b87c96.png" alt=""></p><center><span class="reference">图13 可见性验证方式</span></center><p>session A的第二个select 语句是一致性读(快照读),它是不能看见session B的更新的。</p><p>现在它返回的是(1,3),表示它看见了某个新的版本,这个版本只能是session A自己的update语句做更新的时候生成。(如果你对这个逻辑有疑惑的话,可以回顾下第8篇文章<a href="https://time.geekbang.org/column/article/70562">《事务到底是隔离的还是不隔离的?》</a>中的相关内容)</p><p>所以,我们上期思考题的答案应该是选项3,即:InnoDB认真执行了“把这个值修改成(1,2)"这个操作,该加锁的加锁,该更新的更新。</p><p>然后你会说,MySQL怎么这么笨,就不会更新前判断一下值是不是相同吗?如果判断一下,不就不用浪费InnoDB操作,多去更新一次了?</p><p>其实MySQL是确认了的。只是在这个语句里面,MySQL认为读出来的值,只有一个确定的 (id=1), 而要写的是(a=3),只从这两个信息是看不出来“不需要修改”的。</p><p>作为验证,你可以看一下下面这个例子。</p><p><img src="https://static001.geekbang.org/resource/image/63/c1/63dd6df32dacdb827d256e5acb9837c1.png" alt=""></p><center><span class="reference">图14 可见性验证方式--对照</span></center><p><strong>补充说明:</strong></p><p>上面我们的验证结果都是在binlog_format=statement格式下进行的。</p><p>@didiren 补充了一个case, 如果是binlog_format=row 并且binlog_row_image=FULL的时候,由于MySQL需要在binlog里面记录所有的字段,所以在读数据的时候就会把所有数据都读出来了。</p><p>根据上面说的规则,“既然读了数据,就会判断”, 因此在这时候,select * from t where id=1,结果就是“返回 (1,2)”。</p><p>同理,如果是binlog_row_image=NOBLOB, 会读出除blob 外的所有字段,在我们这个例子里,结果还是“返回 (1,2)”。</p><p>对应的代码如图15所示。这是MySQL 5.6版本引入的,在此之前我没有看过。所以,特此说明。</p><p><img src="https://static001.geekbang.org/resource/image/d4/89/d413b9235d56c62f9829750a68b06b89.png" alt=""></p><center><span class="reference">图15 binlog_row_image=FULL读字段逻辑</span></center><p>类似的,@mahonebags 同学提到了timestamp字段的问题。结论是:如果表中有timestamp字段而且设置了自动更新的话,那么更新“别的字段”的时候,MySQL会读入所有涉及的字段,这样通过判断,就会发现不需要修改。</p><p>这两个点我会在后面讲更新性能的文章中再展开。</p><p>评论区留言点赞板:</p><blockquote>
<p>@Gavin 、@melon、@阿建 等同学提到了锁验证法;<br>
@郭江伟 同学提到了两个点,都非常好,有去实际验证。结论是这样的:<br>
第一,hexdump看出来没改应该是WAL机制生效了,要过一会儿,或者把库shutdown看看。<br>
第二,binlog没写是MySQL Server层知道行的值没变,所以故意不写的,这个是在row格式下的策略。你可以把binlog_format 改成statement再验证下。</p>
</blockquote><p><img src="https://static001.geekbang.org/resource/image/09/77/09c1073f99cf71d2fb162a716b5fa577.jpg" alt=""></p>
</div>
</div>
</div>
<div data-v-87ffcada="" class="article-comments pd"><h2 data-v-87ffcada=""><span
data-v-87ffcada="">精选留言</span></h2>
<ul data-v-87ffcada="">
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/f8/70/f3a33a14.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">某、人</span>
</div>
<div class="bd">回答下@发条橙子同学的问题:<br>问题一:<br>1)无条件查询如果只有order by create_time,即便create_time上有索引,也不会使用到。<br>因为优化器认为走二级索引再去回表成本比全表扫描排序更高。<br>所以选择走全表扫描,然后根据老师讲的两种方式选择一种来排序<br>2)无条件查询但是是order by create_time limit m.如果m值较小,是可以走索引的.<br>因为优化器认为根据索引有序性去回表查数据,然后得到m条数据,就可以终止循环,那么成本比全表扫描小,则选择走二级索引。<br>即便没有二级索引,mysql针对order by limit也做了优化,采用堆排序。这部分老师明天会讲<br><br>问题二:<br>如果是group by a,a上不能使用索引的情况,是走rowid排序。<br>如果是group by limit,不能使用索引的情况,是走堆排序<br>如果是只有group by a,a上有索引的情况,又根据选取值不同,索引的扫描方式又有不同<br>select * from t group by a --走的是索引全扫描,至于这里为什么选择走索引全扫描,还需要老师解惑下<br>select a from t group by a --走的是索引松散扫描,也就说只需要扫描每组的第一行数据即可,不用扫描每一行的值<br><br>问题三:<br>bigint和int加数字都不影响能存储的值。<br>bigint(1)和bigint(19)都能存储2^64-1范围内的值,int是2^32-1。只是有些前端会根据括号里来截取显示而已。建议不加varchar()就必须带,因为varchar()括号里的数字代表能存多少字符。假设varchar(2),就只能存两个字符,不管是中文还是英文。目前来看varchar()这个值可以设得稍稍大点,因为内存是按照实际的大小来分配内存空间的,不是按照值来预分配的。<br><br>老师我有几个问题:<br>1.我还是想在确认之前问的问题。一个长连接,一条sql申请了sort_buffer_size等一系列的会话级别的内存,sql成功执行完,该连接变为sleep状态。这些内存只是内容会被情况,但是占用的内存空间不会释放?<br>2.假设要给a值加1,执行器先找引擎取a=1的行,然后执行器给a+1,在调用接口写入a+1了数据。那么加锁不应该是在执行器第一次去取数据时,引擎层就加该加的锁?为什么要等到第二次调用写入数据时,才加锁。第一次和第二次之间,难道不会被其他事务修改吗?如果没有锁保证<br>3.始终没太明白堆排序是采用的什么算法使得只需要对limit的数据进行排序就可以,而不是排序所有的数据在取前m条。--不过这里期待明天的文章 <br></div>
<span class="time">2018-12-20 17:17</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">发条橙子同学的问题:<br>问题1:你回答得比我回复的答案还好!👍🏿<br>问题2:这个后面我们展开哈,要配图才能说得清😄<br>问题3:回答得也很好,需要注意的是255这个边界。小于255都需要一个字节记录长度,超过255就需要两个字节<br><br>你的问题:#好问题_#<br>1. 排序相关的内存在排序后就free掉还给系统了<br>2. 读的时候加了写锁的<br>3. 堆排序要读所有行的,只读一次,我估计你已经理解对了😄<br><br></p>
<p class="reply-time">2018-12-20 18:52</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/eb/20/a02c4f61.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">didiren</span>
</div>
<div class="bd">刚才又测了一下,在binlog-row-image=full的情况下,第二次update是不写redolog的,说明update并没有发生<br>这样我就理解了,当full时,mysql需要读到在更新时读到a值,所以会判断a值不变,不需要更新,与你给出的update t set a=3 where id=1 and a=3原理相同,但binlog-row-image会影响查询结果还是会让人吃一惊 <br></div>
<span class="time">2018-12-19 17:24</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">是的。<br><br>这个我也盲点了。<br><br>但是细想MySQL 选择这个策略又是合理的。<br><br>我需要再更新一下专栏内容</p>
<p class="reply-time">2018-12-19 19:03</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="" class="avatar">
<div class="info">
<div class="hd"><span class="username">null</span>
</div>
<div class="bd">re: 问题3:回答得也很好,需要注意的是255这个边界。小于255都需要一个字节记录长度,超过255就需要两个字节<br><br>11 月过数据库设计方案,总监现场抛了一个问题,就是关于 varchar 255 的。现在回看,木有人回答到点上,都说是历史原因。<br>下回再问,就可以分享这一点了。ꉂ ೭(˵¯̴͒ꇴ¯̴͒˵)౨”哇哈哈~ <br></div>
<span class="time">2018-12-21 09:45</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">最怕的回答“历史原因”、“大家都这么做的所以…”、“别人要求的” 😄</p>
<p class="reply-time">2018-12-21 10:41</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/03/f7/3a493bec.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">老杨同志</span>
</div>
<div class="bd">1)<br>mysql&gt; select * from t where city in (&#39;杭州&#39;,&quot; 苏州 &quot;) order by name limit 100;<br>需要排序<br>原因是索引顺序城市、名称 与 单独按name排序的顺序不一致。<br><br>2)如果不想mysql排序<br>方案a<br>可以执行两条语句<br>select * from t where city = &#39;杭州&#39; limit 100;<br>select * from t where city = &#39;苏州&#39; limit 100;<br>然后把200条记录在java中排序。<br>方案b<br>分别取前100,然后在数据端对200条数据进行排序。可以sort buffer就可以完成排序了。<br>少了一次应用程序与数据库的网络交互<br>select * from (<br> select * from t where city = &#39;杭州&#39; limit 100<br> union all<br> select * from t where city = &#39;苏州&#39; limit 100<br>) as tt order by name limit 100<br><br><br>3)对分页的优化。<br> 没有特别好的办法。如果业务允许不提供排序功能,不提供查询最后一页,只能一页一页的翻,基本上前几页的数据已经满足客户需求。<br> 为了意义不大的功能优化,可能会得不偿失。<br> 如果一定要优化可以 select id from t where city in (&#39;杭州&#39;,&quot; 苏州 &quot;) order by name limit 10000,100<br> 因为有city\name索引,上面的语句走覆盖索引就可以完成,不用回表。<br> 最后使用 select * from t where id in (); 取得结果<br> 对于这个优化方法,我不好确定的是临界点,前几页直接查询就可以,最后几页使用这个优化方法。<br> 但是中间的页码应该怎么选择不太清楚<br> <br></div>
<span class="time">2018-12-19 10:04</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">从业务上砍掉功能,这个意识很好👌👍🏿</p>
<p class="reply-time">2018-12-19 12:28</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/f7/95/3ebafd36.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">波波</span>
</div>
<div class="bd">笔记:<br>1.MySQL会为每个线程分配一个内存(sort_buffer)用于排序该内存大小为sort_buffer_size<br> 1&gt;如果排序的数据量小于sort_buffer_size,排序将会在内存中完成<br> 2&gt;如果排序数据量很大,内存中无法存下这么多数据,则会使用磁盘临时文件来辅助排序,也称外部排序<br> 3&gt;在使用外部排序时,MySQL会分成好几份单独的临时文件用来存放排序后的数据,然后在将这些文件合并成一个大文件<br><br><br>2.mysql会通过遍历索引将满足条件的数据读取到sort_buffer,并且按照排序字段进行快速排序<br> 1&gt;如果查询的字段不包含在辅助索引中,需要按照辅助索引记录的主键返回聚集索引取出所需字段<br> 2&gt;该方式会造成随机IO,在MySQL5.6提供了MRR的机制,会将辅助索引匹配记录的主键取出来在内存中进行排序,然后在回表<br> 3&gt;按照情况建立联合索引来避免排序所带来的性能损耗,允许的情况下也可以建立覆盖索引来避免回表<br><br>全字段排序<br>1.通过索引将所需的字段全部读取到sort_buffer中<br>2.按照排序字段进行排序<br>3.将结果集返回给客户端<br><br><br>缺点:<br>1.造成sort_buffer中存放不下很多数据,因为除了排序字段还存放其他字段,对sort_buffer的利用效率不高<br>2.当所需排序数据量很大时,会有很多的临时文件,排序性能也会很差<br><br>优点:MySQL认为内存足够大时会优先选择全字段排序,因为这种方式比rowid 排序避免了一次回表操作<br><br><br>rowid排序<br>1.通过控制排序的行数据的长度来让sort_buffer中尽可能多的存放数据,max_length_for_sort_data<br>2.只将需要排序的字段和主键读取到sort_buffer中,并按照排序字段进行排序<br>3.按照排序后的顺序,取id进行回表取出想要获取的数据<br>4.将结果集返回给客户端<br><br>优点:更好的利用内存的sort_buffer进行排序操作,尽量减少对磁盘的访问<br><br>缺点:回表的操作是随机IO,会造成大量的随机读,不一定就比全字段排序减少对磁盘的访问<br><br><br>3.按照排序的结果返回客户所取行数 <br></div>
<span class="time">2018-12-19 13:33</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">👍🏿</p>
<p class="reply-time">2018-12-21 14:11</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/10/1d/13/31ea1b0b.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username"></span>
</div>
<div class="bd">由于city有两个值,相当于匹配到了索引树的两段区域,虽然各自都是按name排序,但整体需要做一次归并,当然只是limit100,所以够数就行。再然后如果需要不做排序,业务端就按city不同的取值查询两次,每次都limit100,然后业务端做归并处理喽。再然后要做分页的话,好吧,我的思路是先整出一张临时的结果表,create table as select rownumber,* from t where city=x order by name(写的不对哈,只是表达意思,rownumber为行数,并为主键)然后直接从这张表中按rownumber进行分页查询就好。 <br></div>
<span class="time">2018-12-19 08:31</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">分页这个再考虑考虑哈😄</p>
<p class="reply-time">2018-12-19 09:39</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/e2/9d/fbbd4611.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">cyberbit</span>
</div>
<div class="bd"><br>1.不会有排序,这种情况属于《高性能mysql》里提到的“in技法”,符合索引的最左原则,是2个等值查询,可以用到右边的索引列。<br>2.分页查询,可以用延迟关联来优化:<br>select * from t join <br>(select id from t where city in(&#39;杭州&#39;,&#39;苏州&#39;) order by name limit 10000,100) t_id<br>on t.id=t_id.id;<br><br> <br></div>
<span class="time">2018-12-19 11:54</span>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/07/1e/bdbe93f4.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">尘封</span>
</div>
<div class="bd">请问,第7步中遍历排序结果,取前 1000 行,并按照 id 的值回到原表中取出 city、name 和 age 三个字段返回给客户端:这里会把id再进行排序吗?转随机io为顺序io? <br></div>
<span class="time">2018-12-19 01:30</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">要是排序就结果不符合order by 的语义逻辑了…</p>
<p class="reply-time">2018-12-19 09:39</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/14/4f/fb/f0c5c4cf.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">赵海亮</span>
</div>
<div class="bd">老师你好,全字段排序那一节,我做了实验,我的排序缓存大小是1M, examined rows 是7715892,查询的三个字段都有数据,那么如果这些数据都放到缓存应该需要(4+8+11)*7715892等于160M,但是我看了都没有用到临时表,这是为什么?<br><br>CREATE TABLE `phone_call_logs` (<br> `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT &#39;主键ID&#39;,<br> `city_id` int(11) NOT NULL DEFAULT &#39;11&#39;,<br> `call_sender` varchar(40) DEFAULT NULL COMMENT &#39;电话主叫号码&#39;,<br> `phone_id` bigint(20) NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;手机id&#39;,<br> PRIMARY KEY (`id`),<br> KEY `idx_city` (`city_id`)<br>) ENGINE=InnoDB AUTO_INCREMENT=64551193;<br>----------------sort_buffer_size=1M----------------------------<br>root:(none)&gt; show variables like &#39;sort_buffer_size&#39;;<br>+------------------+---------+<br>| Variable_name | Value |<br>+------------------+---------+<br>| sort_buffer_size | 1048576 |<br>+------------------+---------+<br>1 row in set (0.00 sec)<br>---------------查询sql---------------------<br> select city_id,phone_id,call_sender from phone_call_logs where city_id=11 order by phone_id desc limit 1000;<br><br><br>-----------------------执行计划结果---------------------------------------------<br><br> &quot;filesort_priority_queue_optimization&quot;: {<br> &quot;limit&quot;: 1000,<br> &quot;rows_estimate&quot;: 146364461,<br> &quot;row_size&quot;: 146,<br> &quot;memory_available&quot;: 1048576,<br> &quot;chosen&quot;: true<br> },<br> &quot;filesort_execution&quot;: [<br> ],<br> &quot;filesort_summary&quot;: {<br> &quot;rows&quot;: 1001,<br> &quot;examined_rows&quot;: 7715892,<br> &quot;number_of_tmp_files&quot;: 0,<br> &quot;sort_buffer_size&quot;: 154160,<br> &quot;sort_mode&quot;: &quot;&lt;sort_key, additional_fields&gt;&quot;<br> <br></div>
<span class="time">2018-12-19 19:41</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">好问题,明天见 😁<br>(明天的一篇也是跟排序有关的哦)</p>
<p class="reply-time">2018-12-20 00:29</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/eb/20/a02c4f61.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">didiren</span>
</div>
<div class="bd">感谢!针对我之前提出的疑问,我又详细的做了实验,发现一个新的问题,我感觉是个bug,希望解答<br># SessionA<br>mysql&gt; show variables like &#39;%binlog_row_image%&#39;;<br>| Variable_name | Value |<br>| binlog_row_image | FULL |<br>mysql&gt; create table t (id int not null primary key auto_increment,<br> -&gt; a int default null)<br> -&gt; engine=innodb;<br>mysql&gt; insert into t values(1,2);<br>mysql&gt; set tx_isolation = &#39;repeatable-read&#39;;<br>mysql&gt; begin;<br>mysql&gt; select * from t where id = 1;<br>| id | a |<br>| 1 | 2 |<br>此时在另一个SessionB执行update t set a=3 where id = 1;成功更新一条记录。通过show engine innodb status看,Log sequence number 2573458<br>然后在SessionA继续。。<br>mysql&gt; update t set a=3 where id = 1;<br>Rows matched: 1 Changed: 0 Warnings: 0<br>Log sequence number 2573467<br>mysql&gt; select * from t where id = 1;<br>| id | a |<br>| 1 | 2 |<br><br>这里与你给出的答案里的实验结果不同<br>可以看到redolog是记录了第二次的update的,但是select却没有看到更新后的值,于是我又换了一个平时测试用的实例,同样的步骤却得到了与你的答案相同的结果<br>然后我对比了2个实例的参数,发现当binlog-row-image=minimal时第二次查询结果a=3,当binlog-row-image=full时第二次查询结果a=2,而且不论哪个参数,redolog都会因为SessionA的update增长,说明redolog都做了记录,update是发生了的,但是binlog-row-image参数会影响查询结果,难以理解,我用的mysql版本是官方的5.7.13<br><br>下面是binlog-row-image = minimal的实验结果<br>mysql&gt; set binlog_row_image=MINIMAL;<br>mysql&gt; drop table t;<br>mysql&gt; create table t (id int not null primary key auto_increment,<br> -&gt; a int default null)<br> -&gt; engine=innodb;<br>insert into t values(1,2);<br>mysql&gt; insert into t values(1,2);<br>mysql&gt; set tx_isolation = &#39;repeatable-read&#39;;<br>mysql&gt; begin;<br>mysql&gt; select * from t where id = 1;<br>| id | a |<br>| 1 | 2 |<br>此时在另一个SessionB执行update t set a=3 where id = 1;成功更新一条记录。<br>mysql&gt; update t set a=3 where id = 1;<br>Rows matched: 1 Changed: 0 Warnings: 0<br>mysql&gt; select * from t where id = 1; <br>| id | a |<br>| 1 | 3 | <br></div>
<span class="time">2018-12-19 17:01</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">!!!<br><br>你说的对<br><br>我验证的是statement格式。<br><br>MySQL 看来选了不错吧路径。<br><br>这个我之前真不知道😓<br><br>多谢<br><br><br></p>
<p class="reply-time">2018-12-19 19:02</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/e1/e7/d1b2e914.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">明亮</span>
</div>
<div class="bd">需要排序,可以将原来的索引中name字段放前面,city字段放后面,来建索引就可以了 <br></div>
<span class="time">2018-12-19 08:08</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">这样不太好哈,变成全索引扫描了</p>
<p class="reply-time">2018-12-19 09:36</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/12/36/ec/ca162d6b.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">edcSam</span>
</div>
<div class="bd">类如图二的索引图,我一直有一个困惑。city的索引图上,有小一些的长方形和大一些的长方形。有时候箭头源自于小长方形,有些箭头又源自于大长方形。这究竟是什么含义? <br></div>
<span class="time">2019-01-12 09:34</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">原意是要宽的表示数据项,窄的表示指针<br>我们修改下图哈,不容易引起疑问。<br>👍细致</p>
<p class="reply-time">2019-01-12 12:53</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="http://thirdwx.qlogo.cn/mmopen/vi_32/JKKWS6TzhncvAA0p0NDiaATPIvMicSM76vNAg9IG1ibibcJYPAiaicYjZfq4gAV8GRtcTpOibfRD8vzqHBtL0ibmhwQsbg/132" class="avatar">
<div class="info">
<div class="hd"><span class="username">唐名之</span>
</div>
<div class="bd">1:用@cyberbit 提供的方式,执行计划是不会使用到排序,但执行时间比使用排序消耗的多;<br>2:分页limit过大时会导致大量排序,可以记录上一页最后的ID,下一页查询条件带上 where ID&gt;上一页最后ID limit 100 <br></div>
<span class="time">2019-01-09 14:56</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">1. 为什么这么说呢?<br>2. 对的</p>
<p class="reply-time">2019-01-10 19:27</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="" class="avatar">
<div class="info">
<div class="hd"><span class="username">felix</span>
</div>
<div class="bd">MySQL对limit有什么优化吗?是只能配合索引使用吗?谢谢 <br></div>
<span class="time">2019-01-04 09:09</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">没有一定要配合索引哦<br><br>下一篇有讲到一个limit 排序优化</p>
<p class="reply-time">2019-01-04 09:38</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/10/43/2f/4ff46e78.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">🐒 刘会俊🐒</span>
</div>
<div class="bd">接上一次的留言。谢谢老师的回复,昨天找到原因了,因为我造的总数据只有6条,使用select city,name,age from t where city=&#39;杭州&#39; order by name limit 1000的时候,使用explain分析的结果中,type为ALL,优化器认为6条数据走全表扫描比用city索引再回表的方式快,所以没有走city索引,看到的结果里examined_rows就是总的6条数据了,我用了force index(city)结果就跟您的一样了。不好意思老师,我是个开发,数据库的一些参数和知识不太熟悉,提了一些弱智问题请您见谅。 <br></div>
<span class="time">2019-01-03 08:38</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content"><br>把问题描述清楚大家就共同学习到啦😄<br>🤝</p>
<p class="reply-time">2019-01-03 10:03</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/10/43/2f/4ff46e78.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">🐒 刘会俊🐒</span>
</div>
<div class="bd">老师,我使用那一条建表语句和查询语句,最后使用explain得出的结果是using where;using filesort,然后我发现select * from information_schema.optimizer_trace\G;得到的结果是 <br>&quot;filesort_summary&quot;: {<br> &quot;rows&quot;: 4,<br> &quot;examined_rows&quot;: 6,<br> &quot;number_of_tmp_files&quot;: 0,<br> &quot;sort_buffer_size&quot;: 71880,<br> &quot;sort_mode&quot;: &quot;&lt;sort_key, packed_additional_fields&gt;&quot;<br> }<br>表里只有4条符合的数据,我没搞懂为什么examined_rows是6,因为6是总数据量为6条。 <br></div>
<span class="time">2019-01-02 16:10</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">哪个查询语句…</p>
<p class="reply-time">2019-01-02 17:38</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/10/bd/ed/95e8a314.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">过去、今日</span>
</div>
<div class="bd">进行排序后的临时文件分成几份是和sort_buffer_size有关,那数据库设置这个值会不会越大越好? <br></div>
<span class="time">2018-12-31 18:25</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">好问题<br><br>不能哦,并发起来的时候内存占用过大,会到自己系统OOM的</p>
<p class="reply-time">2018-12-31 20:29</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/ee/49/8c1e831f.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">吴鸿达</span>
</div>
<div class="bd">波波可是百度dba😁 <br></div>
<span class="time">2018-12-28 22:02</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">额感觉你知道些什么😄</p>
<p class="reply-time">2018-12-28 22:44</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/e9/ab/37903736.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">J!</span>
</div>
<div class="bd">order by 主键 desc limit 1也会索引全表? <br></div>
<span class="time">2018-12-27 21:16</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">索引全表是什么意思</p>
<p class="reply-time">2018-12-27 22:11</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/12/75/d9/24786b20.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">小岭哥</span>
</div>
<div class="bd">为什么建立组合索引之后会天然的按照name递增排序呢 <br></div>
<span class="time">2018-12-26 07:14</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">因为索引要求“有序”</p>
<p class="reply-time">2018-12-26 09:56</p>
</div>
</div>
</li>
</ul>
</div>
</div>
</div>
</div>
</body>
</html>
1
https://gitee.com/jojoecfy/mysql45.git
git@gitee.com:jojoecfy/mysql45.git
jojoecfy
mysql45
mysql45
master

搜索帮助