产品中心
上一篇整理完了 MySQL 的性能优化方式 , 其中最常用的就是 explain .
这一篇来详细看看 explain 中各个参数的含义和扩展 , 整理出来便于使用时快速查询
在日常实践中 , 我们应该如何使用 explain 提供的查询来判断索引怎么配置呢?
以一个实际业务场景为例 : 首先场景里面的数据分布都很均衡 , 这就导致设置的索引在查询优化器的处理下 , 很难产生最好的效果.
先来看一下表结构 :
这里看起来好像万事大吉 , 你看索引不是生效了吗 , 只扫描了16行 ,nice!
但是 , 回想一下 B+Tree 的原则 , 在节点里面搜索条件是由小到大有序排列的 , 而带了这个 user_id 处 , 实际上已经快结束了 , 查询优化器理所当然的选择了通过 idx_user_id 进行查询
如果以开始ID做查询条件 ,可以发现实际上索引没有生效 , 而类型也是全表
这里看起来就很不错了 , 查询行数和索引都使用的很理想. 但是这里面会有一个致命的问题 , 如果是大批量数据查询 , 那么这里一定会出现深度分页的问题
首先数据结构的特点是什么? >> 四个组织分布很平均 , 也就是说如果 org_id 生效 ,我们至少可以只保存四分之一的查询量
初步总结
通过以上三个案例 , 基本上就可以看出 explain 的基本用法
要记住的一点是 , 索引并不是我们以为的样子 ,当多个索引同时存在的时候 , MySQL 会根据情况进行选择. 比如 :
如果这里把时间周期拉长 , 那么结果也会相应的转变 :
连表查询中主要关注的属性是 filtered , 来实际来看看这个属性 :
explain 的结果并不能作为最终决策行为 , explain 是执行计划 , 计划和实际是会存在偏差的, 毕竟 explain 没有真的执行.
哪怕我们最终只需要100行 , 按照 ID 排序的情况下只查几行 , 实际上执行计划的 row 仍然会很庞大.
explain 主要作为参考 , 在实际使用中 , 需要更多的经验思考. 可能最终的结果和explain的不一致.
例如上面的案例 , 按照 explain 的做法 , 用短时间周期最好 ,其次应该是 org_id .
但是根据业务场景 ,我会选择通过 > id 的方式循环查. 一个是业务原因 ,查询的量大 , 上述两种方式都不能避免深度翻页的问题.
到此这篇关于MySQL中explain使用快速查询手册的文章就介绍到这了,更多相关MySQL explain快速查询手册内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
<高性能MySQL>
<MySQL 是怎样运行的：从根儿上理解 MySQL>
