仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 1071|回复: 8
打印 上一主题 下一主题

[学习教程] MYSQL教程之MYSQL教程:explain利用先容

[复制链接]
谁可相欹 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:16:11 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
珍贵的资金可以用于其他业务的启动,诸如市场、广告或调研和开发等。</p>explain显现了mysql怎样利用索引来处置select语句和毗连表.能够匡助选择更好的索引和写出更优化的查询语句.
利用办法:在select语句前加上explain.如EXPLAINSELECT*FROM`users`
Explain列的注释:
table显现这一行的数据是关于哪张表的
type这是主要的列,显现毗连利用了何品种型。从最好到最差的毗连范例为const、eq_reg、ref、range、indexhe和ALL
possible_keys显现大概使用在这张表中的索引。假如为空,没有大概的索引。能够为相干的域从WHERE语句当选择一个符合的语句
key实践利用的索引。假如为NULL,则没有利用索引。很少的情形下,MYSQL会选择优化不敷的索引。这类情形下,能够在SELECT语句中利用USEINDEX(indexname)来强迫利用一个索引大概用IGNOREINDEX(indexname)来强迫MYSQL疏忽索引
key_len利用的索引的长度。在不丧失准确性的情形下,长度越短越好
ref显现索引的哪一列被利用了,假如大概的话,是一个常数
rowsMYSQL以为必需反省的用来前往哀求数据的行数
Extra关于MYSQL怎样剖析查询的分外信息。这里能够看到的坏的例子是Usingtemporary和Usingfilesort,意义MYSQL基本不克不及利用索引,了局是检索会很慢
Extra列前往的形貌的意义
Distinct一旦MYSQL找到了与行相团结婚配的行,就不再搜刮了
NotexistsMYSQL优化了LEFTJOIN,一旦它找到了婚配LEFTJOIN尺度的行,就不再搜刮了
Rangecheckedforeach
Record(indexmap:#)没有找到幻想的索引,因而关于夙昔面表中来的每个行组合,MYSQL反省利用哪一个索引,并用它来从表中前往行。这是利用索引的最慢的毗连之一
Usingfilesort看到这个的时分,查询就必要优化了。MYSQL必要举行分外的步骤来发明怎样对前往的行排序。它依据毗连范例和存储排序键值和婚配前提的全体行的行指针来排序全体行
Usingindex列数据是从仅仅利用了索引中的信息而没有读取实践的举动的表前往的,这产生在对表的全体的哀求列都是统一个索引的部分的时分
Usingtemporary看到这个的时分,查询必要优化了。这里,MYSQL必要创立一个一时表来存储了局,这一般产生在对分歧的列集举行ORDERBY上,而不是GROUPBY上
Whereused利用了WHERE从句来限定哪些即将与下一张表婚配大概是前往给用户。假如不想前往表中的全体行,而且毗连范例ALL或index,这就会产生,大概是查询有成绩
分歧毗连范例的注释(依照效力上下的按次排序)
system表只要一行:system表。这是const毗连范例的特别情形
const表中的一个纪录的最年夜值可以婚配这个查询(索引能够是主键或唯一索引)。由于只要一行,这个值实践就是常数,由于MYSQL先读这个值然后把它当作常数来看待
eq_ref在毗连中,MYSQL在查询时,夙昔面的表中,对每个纪录的团结都从表中读取一个纪录,它在查询利用了索引为主键或唯一键的全体时利用
ref这个毗连范例只要在查询利用了不是唯一或主键的键大概是这些范例的部分(好比,使用最右边前缀)时产生。关于之前的表的每个行团结,全体纪录都将从表中读出。这个范例严峻依附于依据索引婚配的纪录几—越少越好
range这个毗连范例利用索引前往一个局限中的行,好比利用>或<查找器材时产生的情形
index这个毗连范例对后面的表中的每个纪录团结举行完整扫描(比ALL更好,由于索引一样平常小于表数据)
ALL这个毗连范例关于后面的每个纪录团结举行完整扫描,这一样平常对照糟,应当只管制止
一个相关的问题是第三方支持的资格问题,尽管直接来自厂商的支持和服务可以一定程度上减缓这个问题,但是,对于有的企业来说,通过强有力的本地化支持显然更有吸引力。
小女巫 该用户已被删除
沙发
发表于 2015-1-19 06:28:08 | 只看该作者
对递归类的树遍历很有帮助。个人感觉这个真是太棒了!阅读清晰,非常有时代感。
灵魂腐蚀 该用户已被删除
板凳
发表于 2015-1-28 05:13:05 | 只看该作者
总感觉自己还是不会SQL
冷月葬花魂 该用户已被删除
地板
发表于 2015-2-5 16:54:09 | 只看该作者
比如日志传送、比如集群。。。
小魔女 该用户已被删除
5#
发表于 2015-2-13 01:39:45 | 只看该作者
但是随着数据量的增大,这种成本差距会逐渐减小,趋于相等。(500万数量级只相差10%左右)
admin 该用户已被删除
6#
发表于 2015-3-3 12:30:04 | 只看该作者
同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中,就能感觉到目前架构的尴尬。
再见西城 该用户已被删除
7#
发表于 2015-3-11 11:08:12 | 只看该作者
大家注意一点。如下面的例子:
不帅 该用户已被删除
8#
发表于 2015-3-18 11:41:55 | 只看该作者
一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。(有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。)
活着的死人 该用户已被删除
9#
发表于 2015-3-25 21:18:47 | 只看该作者
我个人认为就是孜孜不懈的学习
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-5-3 12:49

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表