mysql中EXPLAIN详解

大家好。众所周知，MySQL 查询优化器的各种基于成本和规则的优化会后生成一个所谓的执行计划，这个执行计划展示了接下来具体执行查询的方式。在日常工作过程中，我们可以使用EXPLAIN语句来查看某个查询语句的具体执行计划， 今天我们就来聊一聊EXPLAIN语句。

如果我们想看看某个查询的执行计划的话，可以在具体的查询语句前边加一个EXPLAIN，就像这样：

在这里插入图片描述
我们把EXPLAIN 语句输出的各个列的作用先大致罗列一下：

列名描述
id在一个大的查询语句中每个SELECT关键字都对应一个唯一的id
select_typeSELECT关键字对应的那个查询的类型
table表名
partitions匹配的分区信息
type针对单表的访问方法
possible_keys可能用到的索引
key实际上使用的索引
key_len实际使用到的索引长度
ref当使用索引列等值查询时，与索引列进行等值匹配的对象信息
rows预估的需要读取的记录条数
filtered某个表经过搜索条件过滤后剩余记录条数的百分比
Extra一些额外的信息

下面我们仔细聊一下每个列是干什么的。

一、 执行计划输出中各列详解

为了方便我们讲解，我们依旧先创建两张一模一样的single_table表（下面分别称为t1和t2），并分别插入10000条记录。

CREATE TABLE single_table ( id INT NOT NULL AUTO_INCREMENT, key1 VARCHAR(100), key2 INT, key3 VARCHAR(100), key_part1 VARCHAR(100), key_part2 VARCHAR(100), key_part3 VARCHAR(100), common_field VARCHAR(100), PRIMARY KEY (id), KEY idx_key1 (key1), UNIQUE KEY idx_key2 (key2), KEY idx_key3 (key3), KEY idx_key_part(key_part1, key_part2, key_part3) 
) Engine=InnoDB CHARSET=utf8;

1、table

不论我们的查询语句有多复杂，里边儿包含了多少个表，到最后也是需要对每个表进行单表访问的，所以MySQL规定EXPLAIN语句输出的每条记录都对应着某个单表的访问方法，该条记录的table列代表着该表的表名。比如：
在这里插入图片描述

这条sql就涉及到s1一个表，所以只输出一条记录。

在这里插入图片描述

可以看到这个连接查询的执行计划中有两条记录，这两条记录的table列分别是s1和s2，这两条记录用来分别说明对s1表和s2表的访问方法是什么 。

2、id

我们在平时写查询语句的时候一般都只有一个SELECT关键字，比如：

SELECT * FROM single_table s1 INNER JOIN single_table2 s2 ON s1.key1 = s2.key1 WHERE s1.common_field = 'a'

但是在使用子查询语句或者UNION语句时可能会有多个SELECT关键字，比如：

#子查询
SELECT * FROM single_table s1 WHERE key1 IN (SELECT * FROM single_table2 s2);
#UNION
SELECT * FROM single_table s1 UNION SELECT * FROM single_table2 s2;

查询语句中每出现一个SELECT 关键字，MySQL就会为它分配一个唯一的id 值。这个id值就是 EXPLAIN 语句的第一个列，比如下边这个查询中只有一个 SELECT 关键字，所以 EXPLAIN 的结果中也就只有一 条id 列为1的记录。
在这里插入图片描述

对于连接查询来说，一个SELECT关键字后边的FROM子句中可以跟随多个表，所以在连接查询的执行计划中，每个表都会对应一条记录，但是这些记录的id值都是相同的，比如：

在这里插入图片描述

可以看到，在连接查询的执行计划中，每个表都会对应一条记录，这些记录的id列的值是相同的，出现在前边的表表示驱动表，出现在后边的表表示被驱动表。所以从上边的EXPLAIN输出中我们可以看出，查询优化器准备让s1表作为驱动表，让s2表作为被驱动表来执行查询。

对于包含子查询的查询语句来说，可能涉及多个SELECT关键字，所以在包含子查询的查询语句的执行计划中，每个SELECT 关键字都会对应一个唯一的id 值，比如：在这里插入图片描述

上述sql中，s1表在外层查询中，外层查询有一个独立的SELECT关键字，所以第一条记录的id值就是 1 ，s2表在子查询中，子查询有一个独立的SELECT关键字，所以第二条记录的id值就是2。
但是这里大家需要特别注意，查询优化器可能对涉及子查询的查询语句进行重写，从而转换为连接查询。所以如果我们想知道查询优化器对某个包含子查询的语句是否进行了重写，直接查看执行计划就好了，比如说：

在这里插入图片描述

可以看到，虽然我们的查询语句是一个子查询，但是执行计划中s1和s2表对应的记录的id值全部是1，这就 表明了查询优化器将子查询转换为了连接查询。

对于包含UNION 子句的查询语句来说，每个SELECT关键字对应一个 id 值也是没错的，不过还是有点儿特别的东西，比方说下边这个查询：在这里插入图片描述

这个语句的执行计划有三条记录，这是因为UNION子句会把多个查询的结果集合并起来并对结果集中的记录进行去重，UNION子句是为了把id为1的查询和id为2的查询的结果集合并起来并去重，在内部创建了一个临时表（表名就是执行计划第三条记录的table 列的名称）。

跟UNION 对比起来， UNION ALL 就不需要为最终的结果集进行去重，它只是单纯的把多个查询的结果集中的记录 合并成一个并返回给用户，所以也就不需要使用临时表。所以在包含UNION ALL子句的查询的执行计划中，就没有上述的第三条记录，比如：
在这里插入图片描述

3、select_type

通过上边的内容我们知道，一条大的查询语句里边可以包含若干个SELECT关键字，每个SELECT关键字代表着一个小的查询语句，而每个SELECT关键字的FROM子句中都可以包含若干张表（这些表用来做连接查询），每一张表都对应着执行计划输出中的一条记录，对于在同一个SELECT关键字中的表来说，它们的id值是相同的。

MySQL 为每一个SELECT关键字代表的小查询都定义了一个称之为select_type的属性，下面我们看一下select_type的各个值是什么意思：

名称描述
SIMPLE查询语句中不包含UNION或者子查询的查询都算作是SIMPLE 类型。
PRIMARY对于包含UNION、UNION ALL或者子查询的大查询来说，它是由几个小查询组成的，其中最左边的那个查询的select_type 值就是PRIMARY。
UNION对于包含UNION 或者 UNION ALL 的大查询来说，它是由几个小查询组成的，其中除了最左边的那个小查询以外，其余的小查的select_type值就是UNION。
UNION RESULTMySQL选择使用临时表来完成 UNION查询的去重工作，针对该临时表的查询的select_type 就是UNION RESULT。
SUBQUERY如果包含子查询的查询语句不能够转为对应的半连接的形式，并且该子查询是不相关子查询，并且查询 优化器决定采用将该子查询物化的方案来执行该子查询时，该子查询的第一个SELECT关键字代表的那个查询的select_type就是SUBQUERY。
DEPENDENT SUBQUERY如果包含子查询的查询语句不能够转为对应的半连接的形式，并且该子查询是相关子查询，则该子查询的第一个SELECT关键字代表的那个查询的select_type 就是DEPENDENT SUBQUERY。
DEPENDENT UNION在包含UNION或者UNION ALL的大查询中，如果各个小查询都依赖于外层查询的话，那除了最左边的那个小查询之外，其余的小查询的select_type的值就是 DEPENDENT UNION。
DERIVED对于采用物化的方式执行的包含派生表的查询，该派生表对应的子查询的select_type就是DERIVED。
MATERIALIZED当查询优化器在执行包含子查询的语句时，选择将子查询物化之后与外层查询进行连接查询时，该子查询对 应的select_type属性就是MATERIALIZED。
UNCACHEABLE SUBQUERY不常用。
UNCACHEABLE UNION不常用。

4、partitions

一般情况下我们的查询语句的执行计划的partitions列的值都是NULL，这里我们就不讲了。

5、type

执行计划中的一条记录就代表着MySQL对某个表的执行查询时的访问方法，其中的type列就表明了这个访问方法是什么，比如：
在这里插入图片描述

可以看到type 列的值是ref ，表明MySQL即将使用ref访问方法来执行对s1表的查询。我们之前说过对使用InnoDB存储引擎的表进行单表访问的一些访问方法，例如：system，const，eq_ref，ref，fulltext，ref_or_null，index_merge，unique_subquery，index_subquery， range，index，ALL。下面我们再看一下这些方法：

方法名描述举例sql
system当表中只有一条记录并且该表使用的存储引擎的统计数据是精确的，比如MyISAM、Memory，那么对该表的 访问方法就是system。EXPLAIN SELECT * FROM t;（表t的存储引擎的统计数据必须是精确的）
const是当我们根据主键或者唯一二级索引列与常数进行等值匹配时，对单表的访问方法就是const。EXPLAIN SELECT * FROM single_table s1 WHERE id = 5
eq_ref在连接查询时，如果被驱动表是通过主键或者唯一二级索引列等值匹配的方式进行访问的，则对该被驱动表的访问方法就是 eq_ref。EXPLAIN SELECT * FROM single_table s1 INNER JOIN single_table2 s2 ON s1.id = s2.id;
ref当通过普通的二级索引列与常量进行等值匹配时来查询某个表，那么对该表的访问方法就可能是ref。EXPLAIN SELECT * FROMsingle_table s1 WHERE key1 = 'a';
fulltext全文索引。这里不讲了。
ref_or_null当对普通二级索引进行等值匹配查询，该索引列的值也可以是NULL值时，那么对该表的访问方法就可能是ref_or_null。EXPLAIN SELECT * FROMsingle_table s1 WHERE key1 = 'a' OR key1 IS NULL;
index_mergeMySQL打算使用索引合并的方式来执行对表的 查询时，那么对该表的访问方法就可能是index_merge。EXPLAIN SELECT * FROMsingle_table s1WHERE key1 = 'a'OR key3 = 'a';
unique_subqueryunique_subquery是针对在一些包含IN子查询的查询语句中，如果查询优化器决定将IN子查询转换为EXISTS 子查询，而且子查询可以使用到主键进行等值匹配的话，那么该子查询执行计划的type列的值就是unique_subquery。EXPLAIN SELECT * FROM single_table s1 WHERE key2 IN (SELECT id FROM single_table2 s2 where s1.key1 = s2.key1) OR key3 = 'a';
index_subqueryindex_subquery与unique_subquery类似，只不过访问子查询中的表时使用的是普通的索引。EXPLAIN SELECT * FROM single_table s1 WHERE common_field IN (SELECT key3 FROM single_table2 s2 where s1.key1 = s2.key1) OR key3 = 'a';
range如果使用索引获取某些范围区间的记录，那么就可能使用到range访问方法。EXPLAIN SELECT * FROM single_table s1 WHERE key1 IN ('a', 'b', 'c');
index当可以使用索引覆盖，但需要扫描全部的索引记录时，该表的访问方法就是index。EXPLAIN SELECT key_part2 FROM single_table s1 WHERE key_part3 = 'a';
ALL全表扫描。这里不讲了。

6、possible_keys和key

在EXPLAIN 语句输出的执行计划中， possible_keys 列表示在某个查询语句中，对某个表执行单表查询时可能用到的索引有哪些，key列表示实际用到的索引有哪些，比如：
在这里插入图片描述
上述执行计划的possible_keys 列的值是 idx_key1,idx_key3 ，表示该查询可能使用到idx_key1,idx_key3两个索引，然后key列的值是idx_key3，表示经过查询优化器计算使用不同索引的成本后，最后决定使用 idx_key3来执行查询比较划算。

不过有一点比较特别，就是在使用index访问方法来查询某个表时，possible_keys列是空的，而key列展示的是实际使用到的索引。

注意：possible_keys列中的值并不是越多越好，可能使用的索引越多，查询优化器计算查询成本时就得花费更长时间，所以如果可以的话，尽量删除那些用不到的索引。

7、 key_len

我们知道在使用某个索引来执行查询时，首先要搞清楚扫描区间和边界条件，这里我们可以通过key_len来了解查询sql的边界条件。例如：
在这里插入图片描述

我们可以看到，这条sql的key_len为303，那么303是什么意思呢？
key_len是由三个部分构成的：

  1. 该列的实际数据最多占用的存储空间长度。key1字段类型是varchar(100)，s1表使用utf8字符集，所以多占用的存储空间长度是3 * 100 = 300字节。
  2. 如果该索引列可以存储NULL值，则key_len比不可以存储NULL值时多1个字节。key1列可以为空。所以需要+1。
  3. 对于变长字段来说，都会有2个字节的空间来存储该变长列的实际长度。key1列是变长字段。所以需要+2。

所以，key_len的值就是3 * 100 + 1 +2 = 303。

这意味着 MySQL 在执行上述查询中只能用到key1列的索引，再看key1列的查询条件是 key1 > ‘a’ and key1 < ‘b’，所以这个搜索条件就是形成范围区间的边界条件。

8、ref

当使用索引列等值匹配的条件去执行查询时，也就是在访问方法是const、eq_ref、ref、ref_or_null、 unique_subquery、 index_subquery其中之一时，ref 列展示的就是与索引列作等值匹配的东东是什么，比如只是一个常数或者是某个列。例如：
在这里插入图片描述

可以看到ref 列的值是const ，表明在使用idx_key1索引执行查询时，与key1列作等值匹配的对象是一个常数，当然有时候更复杂一点：

在这里插入图片描述

可以看到对被驱动表s2的访问方法是eq_ref，而对应的ref列的值是s1.id ，这说明在对被驱动表进行访问时会用到PRIMARY索引，也就是聚簇索引与一个列进行等值匹配的条件，于s2表的id作等值匹配的对象就是s1.id 列。

有的时候与索引列进行等值匹配的对象是一个函数，比如：

在这里插入图片描述

可以看到对s2表采用ref访问方法执行查询，然后在查询计划的ref列里输出 的是func ，说明与s2表的key1列进行等值匹配的对象是一个函数。

9、rows

如果查询优化器决定使用全表扫描的方式对某个表执行查询时，执行计划的rows列就代表预计需要扫描的行数，如果使用索引来执行查询时，执行计划的rows列就代表预计扫描的索引记录行数。比如：
在这里插入图片描述
我们看到执行计划的rows列的值是1 ，这意味着查询优化器在经过分析使用idx_key1进行查询的成本之后，觉得满足key1 > ‘z’ 这个条件的记录只有1条。

10、filtered

我们在分析连接查询的成本时提出过一个condition filtering（条件过滤）的概念，就是MySQL在计算驱动表扇出时采用的一个策略：

如果使用的是全表扫描的方式执行的单表查询，那么计算驱动表扇出时需要估计出满足搜索条件的记录到底有多少条。

如果使用的是索引执行的单表扫描，那么计算驱动表扇出的时候需要估计出满足除使用到对应索引的搜索条件外的其他搜索条件的记录有多少条。

在这里插入图片描述

从执行计划的key列中可以看出来，该查询使用idx_key1索引来执行查询，从rows 列可以看出满足key1 > ‘z’ 的记录有1条。执行计划的 filtered 列就代表查询优化器预测在这1条记录中，有多少条记录满足其余的搜索条件，也就是common_field = ‘a’ 这个条件的百分比。此处 filtered 列的值是 10.00，说明查询优化器预测这条记录10.00%的可能满足 common_field = ‘a’ 这个条件。

对于单表查询来说，这个filtered 列的值没什么意义，我们更关注在连接查询中驱动表对应的执行计划记录的 filtered 值，比方：

在这里插入图片描述

从执行计划中可以看出来，查询优化器打算把s1当作驱动表，s2当作被驱动表。我们可以看到驱动表s1表的执行计划的rows 列为9823， filtered 列为10.00 ，这意味着驱动表 s1的扇出值就是 9823× 10.00% = 982.3，这说明还要对被驱动表执行大约982次查询。

11、Extra

Extra 列是用来说明一些额外信息的，我们可以通过这些额外信息来更准确的理解MySQL到底将如何执行给定的查询语句。下面我们介绍一些平时常见的或者比较重要的额外信息。

额外信息描述举例sql
No tables used当查询语句的没有FROM 子句时将会提示该额外信息。EXPLAIN SELECT 1
ImpossibleWHERE查询语句的WHERE 子句永远为 FALSE 时将会提示该额外信息。EXPLAIN SELECT * FROM single_table s1 WHERE 1 != 1;
No matching min/max row当查询列表处有MIN或者MAX 聚集函数，但是并没有符合WHERE 子句中的搜索条件的记录时会提示该额外信息。EXPLAIN SELECT MIN(key1) FROM single_table s1 WHERE key1 = 'abcdefg';
Using index当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用索引覆盖的情况下，在Extra列将会提示该额外信息。EXPLAIN SELECT key1 FROM single_table s1 WHERE key1 = 'a';
Using index condition有些搜索条件虽然出现了索引列，但是不能充当边界条件来形成扫描区间，这时会提示该额外信息。EXPLAIN SELECT * FROM single_table s1 WHERE key1 > 'z' AND key1 LIKE '%b';
Using where当我们使用全表扫描来执行对某个表的查询，并且该语句的WHERE子句中有针对该表的搜索条件时，在 Extra 列中会提示上述额外信息。EXPLAIN SELECT * FROM single_table s1 WHERE common_field = 'a';
Zero limit当我们的LIMIT 子句的参数为 0 时，表示压根儿不打算从表中读出任何记录，将会提示该额外信息。EXPLAIN SELECT * FROM single_table s1 LIMIT 0;
Using filesort有一些情况下对结果集中的记录进行排序是可以使用到索引的，如果某个查询需要使用文件排序的方式执行查询，就会在执行计划的Extra 列中显示 Using filesort 提示。EXPLAIN SELECT * FROM single_table s1 ORDER BY common_field LIMIT 10;
Using temporary如果查询中使用到了内部的临时表，在执行计划 的Extra 列将会显示 Using temporary提示。EXPLAIN SELECT common_field, COUNT(*) AS amount FROM single_table s1 GROUP BY common_field;
Start temporary, End temporary当sql通过建立临时表来实现为外层查询中的记 录进行去重操作时，驱动表查询执行计划的Extra列将显示Start temporary提示，被驱动表查询执行计划的Extra 列将显示 End temporary 提示。EXPLAIN SELECT * FROM single_table s1 WHERE key1 IN (SELECT key3 FROM single_table2 s2 WHERE common_field = 'a');
LooseScan在将In子查询转为semi-join 时，如果采用的是 LooseScan 执行策略，则在驱动表执行计划的Extra列就是显示LooseScan 提示。EXPLAIN SELECT * FROM single_table s1 WHERE key3 IN (SELECT key1 FROM single_table2 s2 WHERE key1 > 'z');
FirstMatch(tbl_name)在将In子查询转为semi-join 时，如果采用的是FirstMatch 执行策略，则在被驱动表执行计划的Extra列就是显示FirstMatch(tbl_name) 提示。EXPLAIN SELECT * FROM single_table s1 WHERE common_field IN (SELECT key1 FROM single_table2 s2 where s1.key3 = s2.key3);

二、Json格式的执行计划

我们上边介绍的EXPLAIN语句输出中缺少了一个衡量执行计划好坏的重要属性 —— 成本。不过MySQL提供了一种查看某个执行计划花费的成本的方式：

在EXPLAIN 单词和真正的查询语句中间加上FORMAT=JSON。

这样我们就可以得到一个json 格式的执行计划，里边儿包含该计划花费的成本，比如：

root@localhost 8.4.0 [hanzy]>  EXPLAIN FORMAT=JSON SELECT * FROM single_table s1 INNER JOIN single_table2 s2 ON s1.key1 = s2.key2 WHERE s1.common_field = 'a'\G;
*************************** 1. row ***************************
EXPLAIN: {"query_block": {"select_id": 1,   # 整个查询语句只有1个SELECT关键字，该关键字对应的id号为1 "cost_info": {"query_cost": "1350.35"  # 整个查询的执行成本预计为1350.35},"nested_loop": [  # 几个表之间采用嵌套循环连接算法执行# 以下是参与嵌套循环连接算法的各个表的信息 {"table": {"table_name": "s1",  # s1表是驱动表"access_type": "ALL",   # 访问方法为ALL，意味着使用全表扫描访问 "possible_keys": [  # 可能使用的索引 "idx_key1"],"rows_examined_per_scan": 9823,  # 查询一次s1表大致需要扫描9823条记录"rows_produced_per_join": 982,  # 驱动表s1的扇出是982"filtered": "10.00",  # condition filtering代表的百分比 "cost_info": {"read_cost": "908.32",  # 稍后解释"eval_cost": "98.23",  # 稍后解释"prefix_cost": "1006.55",  # 单次查询s1表总共的成本"data_read_per_join": "1M"  # 读取的数据量 },"used_columns": [   # 执行查询中涉及到的列 "id","key1","key2","key3","key_part1","key_part2","key_part3","common_field"],# 对s1表访问时针对单表查询的条件 "attached_condition": "((`hanzy`.`s1`.`common_field` = 'a') and (`hanzy`.`s1`.`key1` is not null))"}},{"table": {"table_name": "s2",  # s2表是被驱动表 "access_type": "eq_ref",  # 访问方法为eq_ref"possible_keys": [  # 可能使用的索引 "idx_key2"],"key": "idx_key2",  # 实际使用的索引 "used_key_parts": [  # 使用到的索引列 "key2"],"key_length": "5",  # key_len"ref": [   # 与key2列进行等值匹配的对象 "hanzy.s1.key1"],"rows_examined_per_scan": 1,  # 查询一次s2表大致需要扫描1条记录 "rows_produced_per_join": 982,  # 被驱动表s2的扇出是982"filtered": "100.00",  # condition filtering代表的百分比 # s2表使用索引进行查询的搜索条件 "index_condition": "(cast(`hanzy`.`s1`.`key1` as double) = cast(`hanzy`.`s2`.`key2` as double))","cost_info": {"read_cost": "245.58",   # 稍后解释"eval_cost": "98.23",  # 稍后解释"prefix_cost": "1350.36",  # 单次查询s1、多次查询s2表总共的成本 "data_read_per_join": "1M"  # 读取的数据量},"used_columns": [  # 执行查询中涉及到的列 "id","key1","key2","key3","key_part1","key_part2","key_part3","common_field"]}}]}
}
1 row in set, 2 warnings (0.01 sec)

我们使用#后边跟随注释的形式为大家解释了EXPLAIN FORMAT=JSON 语句的部分输出内容，现在我们先看 s1 表的 “cost_info” 部分：

 "cost_info": {"read_cost": "908.32",  "eval_cost": "98.23",  "prefix_cost": "1006.55", "data_read_per_join": "1M" },

read_cost 是由下边这两部分组成的： IO 成本和检测rows × (1 - filter) 条记录的CPU成本。

eval_cost 是这样计算的：检测 rows × filter 条记录的成本。

prefix_cost 就是单独查询 s1 表的成本，也就是：read_cost + eval_cost。

data_read_per_join 表示在此次查询中需要读取的数据量。

对于s2 表的"cost_info" 部分是这样的：

"cost_info": {"read_cost": "245.58",  "eval_cost": "98.23",  "prefix_cost": "1350.36",  "data_read_per_join": "1M" 
},

由于s2 表是被驱动表，所以可能被读取多次，这里的read_cost 和 eval_cost 是访问多次 s2 表后累加起来的值，大家主要关注里边儿的prefix_cost 的值代表的是整个连接查询预计的成本，也就是单次查询s1 表和多次查询s2 表后的成本的和。

三、Extented EXPLAIN

在我们使用EXPLAIN 语句查看了某个查询的执行计划后，紧接着还可以使用SHOW WARNINGS语句查看与这个查询的执行计划有关的一些扩展信息，比如：
在这里插入图片描述

大家可以看到SHOW WARNINGS 展示出来的信息有三个字段，分别是 Level 、 Code 、 Message 。我们最常见的就 是Code为1003的信息，当 Code值为1003时， Message字段展示的信息类似于查询优化器将我们的查询语句重写后的语句。比如我们上边的查询本来是一个左（外）连接查询，但是有一个s2.common_field IS NOT NULL 的条件，这就会导致查询优化器把左（外）连接查询优化为内连接查询，从SHOW WARNINGS 的Message 字段也可以看出来，原本的LEFT JOIN已经变成了 JOIN 。

但是大家一定要注意，我们说Message 字段展示的信息类似于查询优化器将我们的查询语句重写后的语句，并不是等价于，也就是说Message 字段展示的信息并不是标准的查询语句，在很多情况下并不能直接运行，它只能作为帮助我们理解查MySQL将如何执行查询语句的一个参考依据而已。

好了，到这里我们就讲完了，大家有什么想法欢迎留言讨论。也希望大家能给作者点个关注，谢谢大家！最后依旧是请各位老板有钱的捧个人场，没钱的也捧个人场，谢谢各位老板！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/diannao/21256.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

数据库索引的理解

数据库索引的理解

目录 1.索引是什么&#xff0c;解决了什么问题 2.索引付出了什么代价 3.如何使用sql索引&#xff0c;有何注意事项 普通索引&#xff1a; 唯一索引&#xff1a; 主键索引(Primary Key Index)&#xff1a; 删除索引: 创建主键索引的基本语法: 4.索引背后的数据结构 1.索…
阅读更多...
数据结构严蔚敏版精简版-绪论

数据结构严蔚敏版精简版-绪论

1.基本概念和术语 下列概念和术语将在以后各章节中多次出现&#xff0c;本节先对这些概念和术语赋予确定的含义。 数据(Data)&#xff1a;数据是客观事物的符号表示&#xff0c;是所有能输入到计算机中并被计算机程序处理的符号 的总称。 数据元素(DataElement)&#xff1a;…
阅读更多...
基于STM32的水库预警系统的Proteus仿真

基于STM32的水库预警系统的Proteus仿真

文章目录 一、水库预警系统1.题目要求2.思路2.1 OLED显示汉字2.2 水质传感器等等2.3 步进电机2.4 驱动水泵 3.仿真图3.1 未仿真时3.2 开始仿真&#xff0c;OLED开始显示3.3 提高水位&#xff0c;开启阀门和预警3.4 通过按键增大水位阈值&#xff0c;取消报警 4.仿真程序4.1 程序…
阅读更多...
轻松拿捏C语言——【文件操作】

轻松拿捏C语言——【文件操作】

&#x1f970;欢迎关注 轻松拿捏C语言系列&#xff0c;来和 小哇 一起进步&#xff01;✊ &#x1f389;创作不易&#xff0c;请多多支持&#x1f389; &#x1f308;感谢大家的阅读、点赞、收藏和关注&#x1f495; &#x1f339;如有问题&#xff0c;欢迎指正 目录 &#x1f…
阅读更多...
谨以此文章记录我的蓝桥杯备赛过程

谨以此文章记录我的蓝桥杯备赛过程

以国优秀结束了蓝桥杯cb组 鄙人来自电信学院&#xff0c;非科班出身&#xff0c;在寒假&#xff0c;大约2024年2月份&#xff0c;跟着黑马程序员将c基础语法学完了&#xff0c;因为过年&#xff0c;事情较多&#xff0c;没在学了。 最初就是抱着拿省三的态度去打这个比赛的&a…
阅读更多...
C语言之旅：探索单链表

C语言之旅：探索单链表

目录 一、前言 二、实现链表的功能&#xff1a; 打印 创建节点 尾插 尾删 头插 头删 查找 在指定位置之前插入数据 指定位置删除 在指定位置之后插入数据 打印 销毁 三、全部源码&#xff1a; 四、结语 一、前言 链表是一个强大且基础的数据结构。对于很多初…
阅读更多...
禁用手机连接 - Win11

禁用手机连接 - Win11

问题 Win11系统自带手机连接软件&#xff0c;会在后台自启&#xff0c;不适用于全部的手机型号&#xff0c;而且常规方法无法卸载。甚至任务管理器中&#xff0c;此软件的后台进程高达76个&#xff0c;如下图。下文以Win11系统为例&#xff0c;介绍如何禁用手机连接。 解决方…
阅读更多...
考研数学：有些无穷小不能用等价无穷小的公式？

考研数学：有些无穷小不能用等价无穷小的公式？

今天要给大家分享的笔记是&#xff1a;《有些无穷小虽然是无穷小&#xff0c;但却不能用无穷小的相关公式》&#xff1a;
阅读更多...
来自大厂硬盘的降维打击！当希捷酷玩520 1TB SSD卷到369，请问阁下该怎么应对？

来自大厂硬盘的降维打击！当希捷酷玩520 1TB SSD卷到369，请问阁下该怎么应对？

来自大厂硬盘的降维打击&#xff01;当希捷酷玩520 1TB SSD卷到369&#xff0c;请问阁下该怎么应对&#xff1f; 哈喽小伙伴们好&#xff0c;我是Stark-C~ 今年4月份的时候因为电脑上的游戏盘突然挂掉&#xff0c;为了性价比选购了希捷酷玩520 1TB SSD&#xff0c;同时我也是…
阅读更多...
7. MySQL 视图、索引

7. MySQL 视图、索引

文章目录 【 1. 视图 View 】1.1 视图原理1.2 创建视图 CREATE VIEW1.2.1 创建基于单表的视图1.2.2 创建基于多表的视图 1.3 查看视图1.3.1 查看视图的内容1.3.2 查看视图的详细信息 1.4 修改视图 ALTER VIEW1.4.1 修改视图内容1.4.2 修改视图名称 1.5 删除视图 DORP VIEW 【 2…
阅读更多...
961题库 北航计算机 计算机网络 附答案 选择题形式

961题库 北航计算机 计算机网络 附答案 选择题形式

有题目和答案&#xff0c;没有解析&#xff0c;不懂的题问大模型即可&#xff0c;无偿分享。 第1组 习题 OSI 参考模型的第 5 层( 自下而上 ) 完成的主要功能是 A. 差错控制 B. 路由选择 C. 会话管理 D. 数据表示转换 100BaseT 快速以太网使用的导向传输介质是 A. 双绞线 B. …
阅读更多...
Gin的快速入门和搭建

Gin的快速入门和搭建

文章目录 Go的工程工程架构技术选型 Gin入门 Go的工程 基于Go生态&#xff0c;构建一个支持内容管理&#xff0c;内容加工、内容分发的内容库系统。 内容管理&#xff1a;增删改查内容加工&#xff1a;例如内容审核、推荐等内容分发&#xff1a;将内容可以推到不同的业务线 …
阅读更多...
linux进阶的一些操作以及知识点------习题集（实践）

linux进阶的一些操作以及知识点------习题集（实践）

请创建以你姓名全拼的用户luwenhua&#xff0c;将其设置为免密登录&#xff0c;切换到luwenhua用户&#xff0c;打开终端&#xff0c;完成以下操作 &#xff08;一&#xff09;bash脚本基础练习 1&#xff09;第一题&#xff1a;请在终端里定义两个用户变量num120&#xff0c…
阅读更多...
C# try catch异常捕获

C# try catch异常捕获

异常捕获 执行过程&#xff1a;try中的代码没有出现异常&#xff0c;则catch里面不会自行&#xff0c;如果try中代码出现异常&#xff0c;则后面的代码都不执行&#xff0c;直接跳到catch中的代码执行。 // try catch 可以捕获多个错误&#xff0c; try...catch...catch.... …
阅读更多...
C++一个StringBad类

C++一个StringBad类

设计一个字符串类,下面的代码是一个不好的设计,起名StringBad。 //stringbad.h #pragma once //一个设计有问题的string类 #include <iostream> using namespace std;class StringBad { public:StringBad();//默认构造函数StringBad(const char* s);//构造函数~StringBa…
阅读更多...
计算机毕业设计 | springboot+vue会议室管理系统(附源码)

计算机毕业设计 | springboot+vue会议室管理系统(附源码)

1&#xff0c;绪论 1.1 项目背景 随着企业规模的不断扩大&#xff0c;会议室管理愈加复杂。传统的手工预约会议室的方式已经无法满足现代企业的需求&#xff0c;因此&#xff0c;开发一套会议室系统方案变得尤为重要。会议室系统可以实现会议室的在线预约、会议室资源的有效利…
阅读更多...
【TB作品】MSP430 G2553 单片机口袋板，电风扇模拟控制系统设计

【TB作品】MSP430 G2553 单片机口袋板，电风扇模拟控制系统设计

功能 电风扇模拟控制系统设计 基本要求: 用LED/LCD 显示电风扇的工作状态 (1,2,3,4 四档风力), 显示风类:“自然风”、“常风”和“睡眠风”。 设计 “自然风”“常风”和“睡眠风” 三个风类键用于设置风类 设计一个“摇头”键用于控制电机摇头。 设计一个“定时”键&#x…
阅读更多...
慢SQL的治理思路

慢SQL的治理思路

慢SQL的治理思路 什么是慢SQL慢SQL产生的原因查看慢 SQL 是否开启开启慢 SQL 记录开启慢查询日志分析慢 SQL解决和优化慢SQL的方法 什么是慢SQL 慢 SQL 指的是 MySQL 中执行比较慢的 SQL&#xff0c;排查慢 SQL 最常用的方法是通过慢查询日志来查找慢 SQL。 MySQL 的慢查询日志…
阅读更多...
快速排序与归并排序（非递归）

快速排序与归并排序（非递归）

目录 快速排序&#xff08;双指针法&#xff09; 原理 代码 快速排序&#xff08;非递归&#xff09; 原理 代码 归并排序 介绍 优点 缺点 图片 原理 代码 归并排序&#xff08;非递归&#xff09; 代码 快速排序&#xff08;双指针法&#xff09; 快速排序的精…
阅读更多...
2024年06月编程语言流行度排名

2024年06月编程语言流行度排名

点击查看最新编程语言流行度排名&#xff08;每月更新&#xff09; 2024年06月编程语言流行度排名 编程语言流行度排名是通过分析在谷歌上搜索语言教程的频率而创建的 一门语言教程被搜索的次数越多&#xff0c;大家就会认为该语言越受欢迎。这是一个领先指标。原始数据来自…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023