首页 > 自考资讯 > 自考资讯

MySQL优化——理解讲解是第一步

2024-10-09

今天给各位分享MySQL优化——理解讲解是第一步的知识,其中也会对进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

今天我们主要介绍如何通过explain命令获取select语句的执行计划。通过explain我们可以知道以下信息:表的读取顺序、数据读取操作的类型、可以使用哪些索引、实际使用了哪些索引以及表之间的关系。参考,优化器查询每个表有多少行等信息。

explain例子

在select语句之前添加explain关键字。 MySQL会在查询上设置一个标记。执行查询时,会返回执行计划信息,而不是执行这条SQL(如果from包含子查询,仍然会执行子查询,将结果放入临时表中)。

expain中的信息主要集中在10列,分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra。下面解释了这些字段可能出现的情况。

id

我的理解是它标识了SQL执行的顺序。 SQL是按照从大到小的顺序执行的。

1、当ID相同时,执行顺序为从上到下。

2、如果是子查询,id的序号会递增。 id值越大,优先级越高,会最先执行。

3、如果ID相同,可以认为是一组,从上到下依次执行;所有组中,ID值越大,优先级越高,越早执行。

select_type

表示查询中每个select子句的类型

(1)SIMPLE(简单的SELECT,没有UNION或子查询等)

(2) PRIMARY(如果查询包含任何复杂的子部分,则最外层的select 被标记为PRIMARY)

(3) UNION(UNION 中的第二个或后续SELECT 语句)

(5)UNION RESULT(UNION的结果)

MySQL优化——理解讲解是第一步

(6)SUBQUERY(子查询中的第一个SELECT)

(8) DERIVED(派生表的SELECT,FROM子句的子查询)

(9)UNCACHEABLE SUBQUERY(子查询的结果无法被缓存,必须重新评估外部链接的第一行)

table

显示该行数据引用的是哪个表。有时它不是真正的表名。你看到的是derivativex(x是一个数字,我的理解是哪一步执行的结果)

mysql 解释select * from (select * from ( select * from t1 where id=2602) a) b;+----+------------+-------- ------+--------+--------------------+--------+----- ----+---|编号|选择类型|表|类型|可能的键|关键| key_len |参考|行|额外|| 1 |小学|派生2 |系统|空|空|空|空| 1 | | 2 |派生|派生3 |系统|空|空|空|空| 1 | | 3 |派生| t1 |常量|主,idx_t1_id |小学| 4 |方法,也称为“访问类型”。

常用的类型有:ALL、index、range、ref、eq_ref、const、system、NULL(从左到右,性能从最差到最好)

ALL:全表扫描,MySQL会遍历整个表来查找匹配的行

index: 全索引扫描,index与ALL的区别在于索引类型只遍历索引树

range: 仅检索给定范围内的行,使用索引来选择行

ref:表示上表的连接匹配条件,即使用哪些列或者常量来查找索引列上的值

eq_ref: 与ref 类似。不同的是,使用的索引是唯一索引。对于每个索引键值,表中只有一条记录匹配。简单来说,就是在多表连接中使用主键或者唯一键作为关联条件。

const、system: 当MySQL优化查询的某一部分并将其转换为常量时使用这些类型来访问。如果主键放在where列表中,MySQL可以将查询转换为常量。 System 是const 类型的特例。当查询的表只有一行时,使用system

NULL: MySQL在优化过程中分解语句,甚至在执行过程中不需要访问表或索引。例如,从索引列中选择最小值可以通过单独的索引查找来完成。

type

MySQL优化——理解讲解是第一步

表示MySQL可以使用哪个索引来查找表中的记录。如果查询涉及的字段有索引,则会列出该索引,但查询可能不会使用该索引。

该列完全独立于EXPLAIN 输出中显示的表的顺序。这意味着possible_keys中的某些键实际上不能按生成的表顺序使用。

如果该列为NULL,则没有关联的索引。在这种情况下,您可以通过检查WHERE 子句来查看它是否引用了某些列或适合建立索引的列,从而提高查询的性能。如果是这样,请创建适当的索引并使用EXPLAIN 再次检查查询

possible_keys

键列显示MySQL实际决定使用的键(索引)。

如果没有选择索引,则键为NULL。要强制MySQL 使用或忽略possible_keys 列上的索引,请在查询中使用FORCE INDEX、USE INDEX 或IGNORE INDEX。

Key

表示索引中使用的字节数。通过该列可以计算出查询中使用的索引的长度(key_len显示的值是索引字段可能的最大长度,而不是实际使用的长度,即key_len是根据表定义计算得到的) ,未从表中检索)

在不损失准确性的情况下,长度越短越好

key_len

表示上表的连接匹配条件,即使用哪些列或常量来查找索引列上的值

ref

表示MySQL根据表统计信息和索引选择来估计需要读取的行数以找到所需的记录。

rows

此列包含有关MySQL 查询解析的详细信息。有以下几种情况:

MySQL优化——理解讲解是第一步

使用where:列数据从表中返回,只使用索引中的信息,而不读取实际操作。当表的所有请求列都属于同一索引时,就会发生这种情况,表明MySQL 服务器将在过滤行之前检索行。

使用临时表:表示MySQL需要使用临时表来存储结果集,这在排序和分组查询中很常见。

使用filesort:MySQL中使用索引无法完成的排序操作称为“文件排序”

使用join buffer:改变的值强调获取join条件时不使用索引,需要一个join buffer来存储中间结果。如果出现这个值,你应该注意,根据查询的具体条件,你可能需要添加索引来提高性能。

不可能的where:该值强调where 语句将导致没有符合条件的行。

选择优化掉的表:该值意味着仅使用索引,优化器可能只从聚合函数结果中返回一行

Extra

• EXPLAIN 未告诉您触发器、存储过程或用户定义函数对查询的影响

• EXPLAIN 不考虑各种缓存

• EXPLAIN无法显示MySQL在执行查询时所做的优化工作

• 一些统计数据是估计值,并不准确

• EXPALIN 只能解释SELECT 操作,其他操作必须重写为SELECT 然后查看执行计划。

用户评论

鹿先森,教魔方

真的!我之前总是莫名其妙的查询语句慢,后来学习了explain,才发现原来是表太多关联,导致查询效率极低

    有10位网友表示赞同!

寻鱼水之欢

说的对啊!以前也觉得数据库访问速度很慢,看了你的文章才了解到explain的重要性,感觉像开了个新世界的大门一样!

    有15位网友表示赞同!

何年何念

我一直在用数据库优化工具,但每次都搞不明白哪里需要优化的重点。学习掌握explain这技巧好像更有针对性更有效率,一定要好好研究一下!

    有16位网友表示赞同!

暮光薄凉

我也很赞同你的观点。平时写代码的时候,总是觉得SQL语句执行慢,还没意识到去看explain的必要性。看来以后一定要多参考你的建议。

    有10位网友表示赞同!

米兰

解释说明真的很重要,可是看懂explain真的太难了,很多时候都是一头雾水...感觉这个方法适合有一定实践基础后再去学习吧...

    有14位网友表示赞同!

折木

我觉得对于初学者来说,了解explain的原理确实很重要,但一开始先掌握一些常用的SQL优化技巧可能会更加直观和容易上手。 explain 可以在后期深耕的过程中再深入学习理解。

    有8位网友表示赞同!

落花忆梦

学习看懂explain的确是一步到位的好方法!不过,我最近在用的数据库管理工具自带的性能诊断功能还挺好用,可以自动分析查询计划,是不是也可以推荐一下?

    有7位网友表示赞同!

爱你心口难开

确实是这样!对于一些相对简单、重复的SQL语句,掌握一些常用优化技巧就能提升效率。复杂的操作还是要看懂explain才能找到真正的瓶颈所在。

    有19位网友表示赞同!

陌離

我更喜欢使用 profiling工具来跟踪数据库性能问题,感觉比纯看explain更直观一点

    有17位网友表示赞同!

你很爱吃凉皮

学习看懂explain是很有用的,但也要结合实际情况进行操作,并不是所有情况下都适合直接根据 explain结果进行优化

    有15位网友表示赞同!

桃洛憬

我看过很多文章介绍mysql 优化,但是大部分都没提到explain这个方面。感谢你的分享,以后要认真学习一下这方面的知识!

    有18位网友表示赞同!

♂你那刺眼的温柔

我之前也关注过MySQL优化,学习过一些索引的知识,但感觉效果还是有限。看來还需要深入研究一下Explain分析的功能!

    有20位网友表示赞同!

半梦半醒i

学习看懂 explain 确实是一个重要的技巧,但我觉得最关键的是要有清晰的目标和需求,否则盲目优化可能会适得其反!

    有18位网友表示赞同!

你是梦遥不可及

这篇文章让我意识到,MySQL 优化是一个持续学习的过程,需要不断掌握新知识和技能才能更好地提升数据库性能!

    有9位网友表示赞同!

蔚蓝的天空〃没有我的翅膀

对于一些大型系统来说,仅仅依靠 Explain 分析可能无法解决所有问题,还需要结合其他工具和技术进行全面诊断!

    有6位网友表示赞同!

慑人的傲气

看懂Explain的确可以帮助我们快速定位到 SQL语句的性能瓶颈,不过还需要根据实际情况调整优化方案,避免过分追求效率导致代码复杂度过高!

    有9位网友表示赞同!

殃樾晨

文章提到的 MySQL 优化 - 看懂 Explain 是第一步,其实也是一个很有意思的过程,需要不断实践和探索才能真正掌握!

    有13位网友表示赞同!

陌颜

同意!学习看懂Explain需要一定的数据库基础知识,建议先花时间学习一些关系型数据库的基本概念。一旦理解了数据库的底层原理,就能更容易理解 Explain 分析的结果。

    有17位网友表示赞同!

猜你喜欢