MySQL数据库——索引(4)-SQL性能分析-profile详情、explain(profile查看指令,explain执行计划中各个字段的含义)

本文介绍了如何在MySQL中进行SQL性能分析,包括开启profiling来记录SQL执行时间,使用showprofiles查看耗时和详细信息,以及通过EXPLAIN命令理解SQL执行计划的各个字段含义,如id、select_type、type等,帮助优化查询性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录

SQL性能分析

profile详情

查看指令

explain

语法

Explain 执行计划中各个字段的含义


SQL性能分析(下)

profile详情

show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。

通过have_profiling参数,能够看到当前MySQL是否支持profile操作:

SELECT @@have_profiling;

可以看到,当前MySQL是支持 profile操作的,但是开关是关闭的。

可以通过set语句在session/global级别开启profiling: 

SET profiling = 1;

开启了之后,我们所执行的SQL语句,都会被MySQL记录,并记录执行时间。

查看指令

-- 查看每一条SQL的耗时基本情况

show profiles;

-- 查看指定query_id的SQL语句各个阶段的耗时情况

show profile for query query_id;

-- 查看指定query_id的SQL语句CPU的使用情况

show profile cpu for query query_id;

explain

EXPLAIN 或者 DESC命令获取 MySQL 如何执行 SELECT 语句的信息,包括在 SELECT 语句执行过程中表如何连接和连接的顺序。

语法

-- 直接在select语句之前加上关键字 explain / desc

EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件 ;

Explain 执行计划中各个字段的含义

  • id

select查询的序列号,表示查询中执行select子句或者是操作表的顺序

(id相同,执行顺序从上到下;id不同,值越大,越先执行)

  • select_type

表示 SELECT 的类型,常见的取值有 SIMPLE(简单表,即不使用表连接或者子查询)、PRIMARY(主查询,即外层的查询)、UNION(UNION 中的第二个或者后面的查询语句)、SUBQUERY(SELECT/WHERE之后包含了子查询)等

  • type

表示连接类型,性能由好到差的连接类型为NULL、system、const、eq_ref、ref、range、index、all 。

1、system:表仅有一行(=系统表)。这是const联接类型的一个特例。
2、const:表最多有一个匹配行,它将在查询开始时被读取。因为仅有一行,在这行的列值可被优化器剩余部分认为是常数。
const用于用常数值比较PRIMARY KEY或UNIQUE索引的所有部分时。
3、eq_ref:对于每个来自于前面的表的行组合,从该表中读取一行。这可能是最好的联接类型,除了const类型。它用在一个索引的所有部分被联接使用并且索引是UNIQUE或PRIMARY KEY。eq_ref可以用于使用= 操作符比较的带索引的列。比较值可以为常量或一个使用在该表前面所读取的表的列的表达式。
4、ref:对于每个来自于前面的表的行组合,所有有匹配索引值的行将从这张表中读取。如果联接只使用键的最左边的前缀,或如果键不是UNIQUE或PRIMARY KEY(换句话说,如果联接不能基于关键字选择单个行的话),则使用ref。如果使用的键仅仅匹配少量行,该联接类型是不错的。ref可以用于使用=或<=>操作符的带索引的列。
5、range:只检索给定范围的行,使用一个索引来选择行。key列显示使用了哪个索引。key_len包含所使用索引的最长关键元素。在该类型中ref列为NULL。当使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符,用常量比较关键字列时,可以使用range
6、index:该联接类型与ALL相同,除了只有索引树被扫描。这通常比ALL快,因为索引文件通常比数据文件小。
7、all:对于每个来自于先前的表的行组合,进行完整的表扫描。如果表是第一个没标记const的表,这通常不好,并且通常在它情况下很差。通常可以增加更多的索引而不要使用ALL,使得行能基于前面的表中的常数值或列值被检索出。

8.NULL:查询时不使用到任何表的时候连接类型就为NULL。
————————————————

(转载内容有修改)

版权声明:本文为优快云博主「FSW...」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.youkuaiyun.com/FSWZYC/article/details/126655438

  •  possible_key

 显示可能应用在这张表上的索引,一个或多个。

  • key

实际使用的索引,如果为NULL,则没有使用索引。

  • key_len

表示索引中使用的字节数,该值为索引字段最大可能长度,并非实际使用长度,在不损失精确性的前提下,长度越短越好 。

  • rows

MySQL认为必须要执行查询的行数,在innodb引擎的表中,是一个估计值,可能并不总是准确的。

  • filtered

表示返回结果的行数占需读取行数的百分比, filtered 的值越大越好。

  • Extra

该列包含MySQL解决查询的详细信息。


END


学习自:黑马程序员——MySQL数据库课程

<think>好的,用户想知道如何分析SQL执行计划。首先,我需要回忆一下自己掌握的知识,确保回答准确。记得执行计划数据库优化的重要工具,能够显示SQL查询的具体执行步骤和成本。 首先,用户可能不太清楚执行计划的基本概念,所以需要先解释什么是执行计划,以及它的作用。比如,执行计划能展示数据库如何访问数据,使用哪些索引,是否有全表扫描等。这部分要简明扼要,让用户有基础的认识。 接下来,用户需要知道如何获取执行计划。不同数据库系统有不同的方法,比如MySQLEXPLAIN,Oracle用EXPLAIN PLAN或者DBMS_XPLAN。要分别说明这些方法,但可能用户主要用的是某一种,不过还是全面一点比较好。引用中的例子提到了MySQLEXPLAIN关键字,这可以作为具体例子来说明[^2]。 然后,分析执行计划的关键点是什么?需要分步骤说明。比如操作类型(全表扫描、索引扫描等)、访问路径、连接方式、成本估算、执行顺序和优化建议。每个部分都要详细一点,但不要过于技术化,用用户能理解的语言。 比如,在操作类型里,全表扫描可能效率低,但有时也是必要的。索引扫描效率高,但要看是否合理使用。访问路径部分可以提到索引覆盖,避免回表操作。连接方式如Nested Loop、Hash Join、Merge Join的区别和应用场景。成本估算中的rows和filtered字段对性能的影响,执行顺序中的缩进或层级结构如何解读。 然后,结合具体例子,用户可能更容易理解。比如给出一个MySQLEXPLAIN输出,并逐列解释type、key、rows等字段含义。这样用户能对照实际输出来分析。 常见问题分析部分,可以列举全表扫描、索引失效、连接顺序不当等情况,并给出优化建议。例如,添加索引、优化查询条件、调整连接顺序等。这部分需要实用,用户可能遇到这些问题,给出解决方法会很有帮助。 高级分析部分,可以提到执行计划的深度分析工具,比如MySQLEXPLAIN FORMAT=JSON或者Oracle的DBMS_XPLAN,以及如何通过Outline Data固定执行计划,引用中的高级执行计划部分可以作为参考[^1]。这部分可能对进阶用户有用,但需要简要说明,避免过于复杂。 最后,总结分析步骤,帮助用户形成系统的分析流程。同时生成相关问题,引导用户进一步学习,比如如何优化全表扫描、如何选择索引策略、执行计划与实际性能差异的原因等。这些问题需要和主题紧密相关,并且能帮助用户深入理解。 在回答过程中,要确保使用正确的中文表达,避免术语错误。同时,检查是否有遗漏的关键点,比如不同数据库的差异,或者具体优化案例。确保引用正确,用户提到的引用[1]和[2]要自然地融入到回答中,比如在获取执行计划的方法和高级分析部分提到。 可能用户是数据库管理员或开发人员,需要优化查询性能,所以回答要侧重实际应用和问题解决。避免过多理论,多提供实际操作步骤和示例。同时,语言要清晰,结构分明,方便用户按照步骤进行分析。 最后检查是否符合系统级指令,比如数学公式是否正确使用,独立公式是否用$$,但这个问题里可能用不到数学公式,所以不用考虑。确保LaTeX语法正确,但这里可能不需要。生成的相关问题要符合用户需求,帮助扩展知识面。</think>### 如何分析SQL执行计划? #### 一、理解执行计划的核心作用 SQL执行计划数据库优化器生成的查询执行路径的可视化表示,包含以下关键信息: 1. **操作类型**:全表扫描(Full Table Scan)、索引扫描(Index Scan)、排序(Sort)等 2. **访问路径**:通过索引还是直接访问表数据 3. **连接方式**:Nested Loop Join、Hash Join、Merge Join等 4. **成本估算**:CPU、I/O、内存等资源消耗的预估值[^2] #### 二、获取执行计划的方法 | 数据库类型 | 命令示例 | 输出格式特点 | |------------|------------------------------|---------------------------| | MySQL | `EXPLAIN SELECT...` | 表格形式展示访问路径和类型 | | Oracle | `EXPLAIN PLAN FOR SELECT...` | 支持高级执行计划分析 | | PostgreSQL | `EXPLAIN ANALYZE SELECT...` | 包含实际执行时间统计 | #### 三、关键分析步骤 1. **识别高成本操作** - 全表扫描:`type=ALL`(MySQL- 临时表使用:`Using temporary` - 文件排序:`Using filesort` ```sql -- MySQL示例 EXPLAIN SELECT * FROM orders WHERE amount > 1000; ``` ```bash +----+-------------+--------+------+---------------+------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+--------+------+---------------+------+---------+------+------+-------------+ | 1 | SIMPLE | orders | ALL | NULL | NULL | NULL | NULL | 1000 | Using where | +----+-------------+--------+------+---------------+------+---------+------+------+-------------+ ``` 2. **分析索引使用** - 理想情况:`type=ref/range`,`key`字段显示使用的索引 - 索引失效情况:字段类型不匹配、使用函数处理索引字段 3. **评估连接效率** - Nested Loop适合小数据集 - Hash Join适合大数据集等值连接 - Merge Join需要预先排序的数据 #### 四、常见问题诊断与优化 | 问题现象 | 优化建议 | 实现方法示例 | |-------------------------|-----------------------------------|-----------------------------| | 全表扫描(type=ALL) | 添加合适索引 | `CREATE INDEX idx_col ON table(col)` | | 索引未使用 | 检查查询条件与索引字段匹配度 | 避免在索引字段使用函数 | | 临时表使用过多 | 优化GROUP BY/ORDER BY子句 | 添加覆盖索引 | #### 五、高级分析方法 1. **执行计划深度解析**: - MySQL使用`EXPLAIN FORMAT=JSON`获取详细成本计算 - Oracle通过`DBMS_XPLAN.DISPLAY_CURSOR`查看实际执行计划 2. **执行计划控制**: - 使用SQL Profile固定执行计划(Oracle) - 通过Hint强制指定访问路径(如`/*+ INDEX(table idx) */`) #### 六、分析流程图解 ```mermaid graph TD A[获取执行计划] --> B{是否存在全表扫描?} B -->|是| C[检查索引合理性] B -->|否| D{连接方式是否最优?} C --> E[添加缺失索引/优化查询条件] D -->|Hash Join更优| F[调整连接顺序或添加统计信息] D -->|已优化| G[检查资源消耗瓶颈] ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值