mysql原理--连接查询的成本

1.准备工作
连接查询至少是要有两个表的,只有一个 single_table 表是不够的,所以为了故事的顺利发展,我们直接构造一个和 single_table 表一模一样的 single_table2 表。为了简便起见,我们把 single_table 表称为 s1 表,把 single_table2 表称为 s2 表。

1.1.Condition filtering介绍
MySQL 中连接查询采用的是嵌套循环连接算法,驱动表会被访问一次,被驱动表可能会被访问多次,所以对于两表连接查询来说,它的查询成本由下边两个部分构成:
(1). 单次查询驱动表的成本
(2). 多次查询被驱动表的成本(具体查询多少次取决于对驱动表查询的结果集中有多少条记录)

我们把对驱动表进行查询后得到的记录条数称之为驱动表的 扇出 (英文名: fanout )。当查询优化器想计算整个连接查询所使用
的成本时,就需要计算出驱动表的扇出值,有的时候扇出值的计算是很容易的,比如下边这两个查询:
(1). 查询一: SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2;
假设使用 s1 表作为驱动表,很显然对驱动表的单表查询只能使用全表扫描的方式执行,驱动表的扇出值也很明确,那就是驱动表中有多少记录,扇出值就是多少。我们前边说过,统计数据中 s1 表的记录行数是 9693 ,也就是说优化器就直接会把 9693 当作在 s1 表的扇出值。
(2). 查询二: SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2 WHERE s1.key2 >10 AND s1.key2 < 1000;
仍然假设 s1 表是驱动表的话,很显然对驱动表的单表查询可以使用 idx_key2 索引执行查询。此时 idx_key2 的范围区间 (10, 1000) 中有多少条记录,那么扇出值就是多少。我们前边计算过,满足 idx_key2 的范围区间 (10, 1000) 的记录数是95条,也就是说本查询中优化器会把 95 当作驱动表 s1 的扇出值。

有的时候扇出值的计算就变得很棘手,比方说下边几个查询:
(3). 查询三: SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2 WHERE s1.common_field > 'xyz';
本查询和 查询一 类似,只不过对于驱动表 s1 多了一个 common_field > 'xyz' 的搜索条件。查询优化器又不会真正的去执行查询,所以它只能 猜 这 9693 记录里有多少条记录满足 common_field > 'xyz' 条件。
(4). 查询四: SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2 WHERE s1.key2 > 10 AND s1.key2 < 1000 AND s1.common_field > 'xyz';
本查询和 查询二 类似,只不过对于驱动表 s1 也多了一个 common_field > 'xyz' 的搜索条件。不过因为本查询可以使用 idx_key2 索引,所以只需要从符合二级索引范围区间的记录中猜有多少条记录符合 common_field > 'xyz' 条件,也就是只需要猜在 95 条记录中有多少符合 common_field > 'xyz' 条件。
(5). 查询五: SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2 WHERE s1.key2 > 10 AND s1.key2 < 1000 AND s1.key1 IN ('a', 'b', 'c') AND s1.common_field > 'xyz';
本查询和 查询二 类似,不过在驱动表 s1 选取 idx_key2 索引执行查询后,优化器需要从符合二级索引范围区间的记录中猜有多少条记录符合下边两个条件:
a. key1 IN ('a', 'b', 'c')
b. common_field > 'xyz'
也就是优化器需要猜在 95 条记录中有多少符合上述两个条件的。

这两种情况下计算驱动表扇出值时需要靠 猜 :
(1). 如果使用的是全表扫描的方式执行的单表查询,那么计算驱动表扇出时需要猜满足搜索条件的记录到底有多少条。
(2). 如果使用的是索引执行的单表扫描,那么计算驱动表扇出的时候需要猜满足除使用到对应索引的搜索条件外的其他搜索条件的记录有多少条。

设计 MySQL 的大叔把这个 猜 的过程称之为 condition filtering

1.2.两表连接的成本分析
连接查询的成本计算公式是这样的:连接查询总成本 = 单次访问驱动表的成本 + 驱动表扇出数 x 单次访问被驱动表的成本
对于左(外)连接和右(外)连接查询来说,它们的驱动表是固定的,所以想要得到最优的查询方案只需要:分别为驱动表和被驱动表选择成本最低的访问方法。

可是对于内连接来说,驱动表和被驱动表的位置是可以互换的,所以需要考虑两个方面的问题:
(1). 不同的表作为驱动表最终的查询成本可能是不同的,也就是需要考虑最优的表连接顺序。
(2). 然后分别为驱动表和被驱动表选择成本最低的访问方法。

下边我们就以内连接为例来看看如何计算出最优的连接查询方案。
比如对于下边这个查询来说:SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2 ON s1.key1 = s2.common_field WHERE s1.key2 > 10 AND s1.key2 < 1000 AND s2.key2 > 1000 AND s2.key2 < 2000;

可以选择的连接顺序有两种:
(1). s1 连接 s2 ,也就是 s1 作为驱动表, s2 作为被驱动表。
(2). s2 连接 s1 ,也就是 s2 作为驱动表, s1 作为被驱动表。

查询优化器需要分别考虑这两种情况下的最优查询成本,然后选取那个成本更低的连接顺序以及该连接顺序下各个表的最优访问方法作为最终的查询计划。

(1).使用 s1 作为驱动表的情况:
a. 分析对于驱动表的成本最低的执行方案
首先看一下涉及 s1 表单表的搜索条件有哪些:
a.1. s1.key2 > 10 AND s1.key2 < 1000
所以这个查询可能使用到 idx_key2 索引,从全表扫描和使用 idx_key2 这两个方案中选出成本最低的那个,这个过程我们上边都唠叨过了,很显然使用 idx_key2 执行查询的成本更低些。
b. 然后分析对于被驱动表的成本最低的执行方案
此时涉及被驱动表 idx_key2 的搜索条件就是:
b.1. s2.common_field = 常数(这是因为对驱动表 s1 结果集中的每一条记录,都需要进行一次被驱动表 s2 的访问,此时那些涉及两表的条件现在相当于只涉及被驱动表 s2 了。)
b.2. s2.key2 > 1000 AND s2.key2 < 2000
很显然,第一个条件由于 common_field 没有用到索引,所以并没有什么卵用,此时访问 single_table2 表时可用的方案也是全表扫描和使用 idx_key2 两种,很显然使用 idx_key2 的成本更小。

所以此时使用 single_table 作为驱动表时的总成本就是(暂时不考虑使用 join buffer 对成本的影响):
使用idx_key2访问s1的成本 + s1的扇出 × 使用idx_key2访问s2的成本

(2). 使用 s2 作为驱动表的情况
a. 分析对于驱动表的成本最低的执行方案
首先看一下涉及 s2 表单表的搜索条件有哪些:
a.1. s2.key2 > 10 AND s2.key2 < 1000
所以这个查询可能使用到 idx_key2 索引,从全表扫描和使用 idx_key2 这两个方案中选出成本最低的那个,这个过程我们上边都唠叨过了,很显然使用 idx_key2 执行查询的成本更低些。
b. 然后分析对于被驱动表的成本最低的执行方案
此时涉及被驱动表 idx_key2 的搜索条件就是:
b.1. s1.key1 = 常数
b.2. s1.key2 > 1000 AND s1.key2 < 2000

使用 idx_key1 可以进行 ref 方式的访问,使用 idx_key2 可以使用 range 方式的访问。这时优化器需要从全表扫描、使用 idx_key1 、使用 idx_key2 这几个方案里选出一个成本最低的方案。这里有个问题啊,因为 idx_key2 的范围区间是确定的: (10, 1000) ,怎么计算使
用 idx_key2 的成本我们上边已经说过了,可是在没有真正执行查询前, s1.key1 = 常数 中的 常数 值我们是不知道的,怎么衡量使用 idx_key1 执行查询的成本呢?其实很简单,直接使用索引统计数据就好了(就是索引列平均一个值重复多少次)。一般情况下, ref 的访问方式要比 range 成本最低,这里假设使用 idx_key1 进行对 s2 的访问。

所以此时使用 single_table 作为驱动表时的总成本就是:
使用idx_key2访问s2的成本 + s2的扇出 × 使用idx_key1访问s1的成本

最后优化器会比较这两种方式的最优访问成本,选取那个成本更低的连接顺序去真正的执行查询。从上边的计算过程也可以看出来,连接查询成本占大头的其实是 驱动表扇出数 x 单次访问被驱动表的成本 ,所以我们的优化重点其实是下边这两个部分:
(1). 尽量减少驱动表的扇出
(2). 对被驱动表的访问成本尽量低

这一点对于我们实际书写连接查询语句时十分有用,我们需要尽量在被驱动表的连接列上建立索引,这样就可以使用 ref 访问方法来降低访问被驱动表的成本了。如果可以,被驱动表的连接列最好是该表的主键或者唯一二级索引列,这样就可以把访问被驱动表的成本降到更低了。

1.3.多表连接的成本分析
首先要考虑一下多表连接时可能产生出多少种连接顺序:
(1). 对于两表连接,比如表A和表B连接
只有 AB、BA这两种连接顺序。其实相当于 2 × 1 = 2 种连接顺序。
(2). 对于三表连接,比如表A、表B、表C进行连接
ABC、ACB、BAC、BCA、CAB、CBA这么6种连接顺序。其实相当于 3 × 2 × 1 = 6 种连接顺序。
(3). 对于 n 表连接的话,则有 n × (n-1) × (n-2) × ··· × 1 种连接顺序,就是n的阶乘种连接顺序,也就是 n! 。

设计 MySQL 的大叔们想了很多办法减少计算非常多种连接顺序的成本的方法:
(1). 提前结束某种顺序的成本评估
MySQL 在计算各种链接顺序的成本之前,会维护一个全局的变量,这个变量表示当前最小的连接查询成本。如果在分析某个连接顺序的成本时,该成本已经超过当前最小的连接查询成本,那就压根儿不对该连接顺序继续往下分析了。比方说A、B、C三个表进行连接,已经得到连接顺序 ABC 是当前的最小连接成本,比方说 10.0 ,在计算连接顺序 BCA 时,发现 B 和 C 的连接成本就已经大于 10.0 时,就不再继续往后分析 BCA 这个连接顺序的成本了。
(2). 系统变量 optimizer_search_depth
如果连接表的个数小于该值,那么就继续穷举分析每一种连接顺序的成本,否则只对与 optimizer_search_depth 值相同数量的表进行穷举分析。很显然,该值越大,成本分析的越精确,越容易得到好的执行计划,但是消耗的时间也就越长,否则得到不是很好的执行计划,但可以省掉很多分析连接成本的时间。
(3). 根据某些规则压根儿就不考虑某些连接顺序
设计 MySQL 的大叔提出了一些所谓的 启发式规则 (就是根据以往经验指定的一些规则),凡是不满足这些规则的连接顺序压根儿就不分析,这样可以极大的减少需要分析的连接顺序的数量,但是也可能造成错失最优的执行计划。他们提供一个系统变量 optimizer_prune_level 来控制到底是不是用这些启发式规则。

1.4.调节成本常数
我们前边之介绍了两个 成本常数 :
(1). 读取一个页面花费的成本默认是 1.0
(2). 检测一条记录是否符合搜索条件的成本默认是 0.2

其实除了这两个成本常数, MySQL 还支持好多呢,它们被存储到了 mysql 数据库(这是一个系统数据库,我们之前介绍过)的两个表中:
在这里插入图片描述
我们在第一章中就说过,一条语句的执行其实是分为两层的:
(1). server 层
(2). 存储引擎层

在 server 层进行连接管理、查询缓存、语法解析、查询优化等操作,在存储引擎层执行具体的数据存取操作。也就是说一条语句在 server 层中执行的成本是和它操作的表使用的存储引擎是没关系的,所以关于这些操作对应的 成本常数 就存储在了 server_cost 表中,而依赖于存储引擎的一些操作对应的 成本常数 就存储在了 engine_cost 表中。

1.4.1.mysql.server_cost表
server_cost 表中在 server 层进行的一些操作对应的 成本常数 ,具体内容如下:
在这里插入图片描述
我们先看一下 server_cost 各个列都分别是什么意思:
(1). cost_name
表示成本常数的名称。
(2). cost_value
表示成本常数对应的值。如果该列的值为 NULL 的话,意味着对应的成本常数会采用默认值。
(3). last_update
表示最后更新记录的时间。
(4). comment
注释。

从 server_cost 中的内容可以看出来,目前在 server 层的一些操作对应的 成本常数 有以下几种:

成本常数名称默认值描述
disk_temptable_create_cost20.0创建基于磁盘的临时表的成本,如果增大这个值的话会让优化器尽量少的创建基于磁盘的临时表。
disk_temptable_row_cost0.5向基于磁盘的临时表写入或读取一条记录的成本,如果增大这个值的话会让优化器尽量少的创建基于磁盘的临时表。
key_compare_cost0.05两条记录做比较操作的成本,多用在排序操作上,如果增大这个值的话会提升 filesort 的成本,让优化器可能更倾向于使用索引完成排序而不是 filesort 。
memory_temptable_create_cost1.0创建基于内存的临时表的成本,如果增大这个值的话会让优化器尽量少的创建基于内存的临时表。
memory_temptable_row_cost0.1向基于内存的临时表写入或读取一条记录的成本,如果增大这个值的话会让优化器尽量少的创建基于内存的临时表。
row_evaluate_cost0.1这个就是我们之前一直使用的检测一条记录是否符合搜索条件的成本,增大这个值可能让优化器更倾向于使用索引而不是直接全表扫描。

MySQL在执行诸如DISTINCT查询、分组查询、Union查询以及某些特殊条件下的排序查询都可能在内部先创建一个临时表,使用这个临时表来辅助完成查询(比如对于DISTINCT查询可以建一个带有UNIQUE索引的临时表,直接把需要去重的记录插入到这个临时表中,插入完成之后的记录就是结果集了)。在数据量大的情况下可能创建基于磁盘的临时表,也就是为该临时表使用MyISAM、InnoDB等存储引擎,在数据量不大时可能创建基于内存的临时表,也就是使用Memory存储引擎。

这些成本常数在 server_cost 中的初始值都是 NULL ,意味着优化器会使用它们的默认值来计算某个操作的成本,如果我们想修改某个成本常数的值的话,需要做两个步骤:
(1). 对我们感兴趣的成本常数做更新操作
比方说我们想把检测一条记录是否符合搜索条件的成本增大到 0.4 ,那么就可以这样写更新语句: UPDATE mysql.server_cost SET cost_value = 0.4 WHERE cost_name = 'row_evaluate_cost';
(2). 让系统重新加载这个表的值。
使用下边语句即可: FLUSH OPTIMIZER_COSTS;

当然,在你修改完某个成本常数后想把它们再改回默认值的话,可以直接把 cost_value 的值设置为 NULL ,再使用 FLUSH OPTIMIZER_COSTS 语句让系统重新加载它就好了。

1.4.2.mysql.engine_cost表
engine_cost表 表中在存储引擎层进行的一些操作对应的 成本常数 ,具体内容如下:
在这里插入图片描述
与 server_cost 相比, engine_cost 多了两个列:
(1). engine_name 列
指成本常数适用的存储引擎名称。如果该值为 default ,意味着对应的成本常数适用于所有的存储引擎。
(2). device_type 列
指存储引擎使用的设备类型,这主要是为了区分常规的机械硬盘和固态硬盘,该值默认是 0 。

我们从 engine_cost 表中的内容可以看出来,目前支持的存储引擎成本常数只有两个:

成本常数名称默认值描述
io_block_read_cost1.0从磁盘上读取一个块对应的成本。请注意我使用的是 块 ,而不是 页 这个词儿。对于InnoDB 存储引擎来说,一个 页 就是一个块,不过对于 MyISAM 存储引擎来说,默认是以 4096 字节作为一个块的。增大这个值会加重 I/O 成本,可能让优化器更倾向于选择使用索引执行查询而不是执行全表扫描。
memory_block_read_cost0.25与上一个参数类似,只不过衡量的是从内存中读取一个块对应的成本。

与更新 server_cost 表中的记录一样,我们也可以通过更新 engine_cost 表中的记录来更改关于存储引擎的成本常数,我们也可以通过为 engine_cost 表插入新记录的方式来添加只针对某种存储引擎的成本常数:
(1). 插入针对某个存储引擎的成本常数
比如我们想增大 InnoDB 存储引擎页面 I/O 的成本,书写正常的插入语句即可: INSERT INTO mysql.engine_cost VALUES ('InnoDB', 0, 'io_block_read_cost', 2.0, CURRENT_TIMESTAMP, 'increase Innodb I/O cost');
(2). 让系统重新加载这个表的值。
使用下边语句即可: FLUSH OPTIMIZER_COSTS;

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

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

相关文章

ES8生产实践——Kibana对接Azure AD实现单点登录

基本概念介绍 什么是单点登录 单点登录&#xff08;Single Sign-On&#xff0c;SSO&#xff09;是一种身份验证和访问控制机制&#xff0c;允许用户使用一组凭据&#xff08;通常是用户名和密码&#xff09;仅需登录一次&#xff0c;即可访问多个应用程序或系统&#xff0c;而…

结构体的对齐规则

1.引入 我们在掌握了结构体的基本使⽤后。 现在我们深⼊讨论⼀个问题&#xff1a;计算结构体的大小。 这也是⼀个特别热门的考点&#xff1a; 结构体内存对齐。 2.具体分析 ⾸先我们得掌握结构体的对⻬规则&#xff1a; 1. 结构体的第⼀个成员对⻬到和结构体变量起始位置偏移量…

一站式指南:第 377 场力扣周赛的终极题解

比赛详情 比赛地址 题目一很简单题目二主要是题目长了点&#xff0c;其实解法很常规(比赛后才意识到)题目三套用Dijkstra算法题目四没时间解答水平还有待提升(其实就是需要灵活组合运用已知的算法&#xff0c;有点类似大模型的Agent) 题解和思路 第一题&#xff1a;最小数字…

CentOS进入单用户模式

一、重启 二、出现内核选项 按“e” 三、编辑这一行 输入 rw init/sysroot/bin/sh 四、进入单用户模式 ctrlx 进入 五、切换目录 chroot /sysroot 六、然后你就操作你的系统了。 修改密码等等

【知识点随笔分享 | 第九篇】常见的限流算法

目录 前言&#xff1a; 1.固定窗口限流&#xff1a; 缺点&#xff1a; 2.滑动窗口限流&#xff1a; 优点&#xff1a; 滴桶限流&#xff1a; 缺点&#xff1a; 令牌桶限流&#xff1a; 优点&#xff1a; 总结: 前言&#xff1a; 当今互联网时代&#xff0c;随着网络…

IP编址,IP地址介绍与子网划分方法

网络层位于数据链路层与传输层之间。网络层中包含了许多协议&#xff0c;其中最为重要的协议就是IP协议。网络层提供了IP路由功能。理解IP路由除了要熟悉IP协议的工作机制之外&#xff0c;还必须理解IP编址以及如何合理地使用IP地址来设计网络。 上层协议类型 以太网帧中的Typ…

数据通信网络基础华为ICT网络赛道

目录 前言&#xff1a; 1.网络与通信 2.网络类型与网络拓扑 3.网络工程与网络工程师 前言&#xff1a; 数据通信网络基础是通信领域的基本概念&#xff0c;涉及数据传输、路由交换、网络安全等方面的知识。华为ICT网络赛道则是华为公司提出的一种技术路径&#xff0c;旨在通…

主机安全技术措施

目录 身份鉴别 进阶 访问控制 进阶 安全审计 进阶 ​编辑 剩余信息保护 入侵防范 进阶 恶意代码防范 资源控制 身份鉴别 进阶 访问控制 进阶 安全审计 进阶 剩余信息保护 入侵防范 进阶 恶意代码防范 资源控制 ~over~

Git 分布式版本控制系统(序章1)

第一章 Git 分布式版本控制系统 为什么学Git? 某些企业面试需要掌握Git&#xff0c;同时&#xff0c;也方便管理自己的Qt项目。 一、Git 客户端下载&#xff08;Windows&#xff09; 下载地址 https://gitee.com/all-about-git#git-%E5%A4%A7%E5%85%A8 二、Git 的特点 分支…

java的XWPFDocument3.17版本学习

maven依赖 <dependency><groupId>org.apache.poi</groupId><artifactId>poi-ooxml</artifactId><version>3.17</version> </dependency> 测试类&#xff1a; import org.apache.poi.openxml4j.exceptions.InvalidFormatExcep…

【MybatisPlus快速入门】(3)SpringBoot整合MybatisPlus 之 Lombok插件安装及MybatisPlus分页代码示例

目录 1.Lombok1.1 步骤1:添加lombok依赖 2.2 步骤2:安装Lombok的插件1.3 步骤3:模型类上添加注解2 分页功能2.1 步骤1:调用方法传入参数获取返回值2.2步骤2:设置分页拦截器2.3 步骤3:运行测试程序 之前我们已学习MyBatisPlus在代码示例与MyBatisPlus的简介&#xff0c;在这一节…

Web Components入门不完全指北

目前流行的各类前端框架&#xff0c;不管是react, angular还是vue&#xff0c;都有一个共同点&#xff0c;那就是支持组件化开发&#xff0c;但事实上随着浏览器的发展&#xff0c;现在浏览器也原生支持组件式开发&#xff0c;本文将通过介绍Web Components 的三个主要概念&…

vue场景 无分页列表条件过滤,子组件多选来自父组件的列表

日常开发中&#xff0c;经常会遇到下面场景&#xff1a; 页面加载一个无分页列表&#xff0c;同时工具栏设置多个条件可对列表过滤的场景(典型的就是关键字模糊查询)父组件传给子组件列表&#xff0c;子组件中需要多选列表多选&#xff0c;选择结果返回父组件 1 无分页列表过…

电子电器架构刷写方案——General Flash Bootloader

电子电器架构刷写方案——General Flash Bootloader 我是穿拖鞋的汉子&#xff0c;魔都中坚持长期主义的汽车电子工程师。 注&#xff1a;文章1万字左右&#xff0c;深度思考者入&#xff01;&#xff01;&#xff01; 老规矩&#xff0c;分享一段喜欢的文字&#xff0c;避免…

CentOS 7 Tomcat服务的安装

前提 安装ava https://blog.csdn.net/qq_36940806/article/details/134945175?spm1001.2014.3001.5501 1. 下载 wget https://mirrors.tuna.tsinghua.edu.cn/apache/tomcat/tomcat-9/v9.0.84/bin/apache-tomcat-9.0.84.tar.gzps: 可选择自己需要的版本下载安装https://mirr…

mysql原理--基于成本的优化

1.什么是成本 我们之前老说 MySQL 执行一个查询可以有不同的执行方案&#xff0c;它会选择其中成本最低&#xff0c;或者说代价最低的那种方案去真正的执行查询。不过我们之前对 成本 的描述是非常模糊的&#xff0c;其实在 MySQL 中一条查询语句的执行成本是由下边这两个方面组…

Kali Linux—借助 SET+MSF 进行网络钓鱼、生成木马、获主机shell、权限提升、远程监控、钓鱼邮件等完整渗透测试(一)

社会工程学—世界头号黑客凯文米特尼克在《欺骗的艺术》中曾提到&#xff0c;这是一种通过对受害者心理弱点、本能反应、好奇心、信任、贪婪等心理陷阱进行诸如欺骗、伤害等危害手段。 SET最常用的攻击方法有&#xff1a;用恶意附件对目标进行 E-mail 钓鱼攻击、Java Applet攻…

Unity之DOTweenPath轨迹移动

Unity之DOTweenPath轨迹移动 一、介绍 DOTweenPath二、操作说明1、Scene View Commands2、INfo3、Tween Options4、Path Tween Options5、Path Editor Options&#xff1a;轨迹编辑参数&#xff0c;就不介绍了6、ResetPath&#xff1a;重置轨迹7、Events&#xff1a;8、WayPoin…

Liteos移植_STM32_HAL库

0 开发环境 STM32CubeMX(HAL库)keil 5正点原子探索者STM32F4ZET6LiteOS-develop分支 1 STM32CubeMX创建工程 如果有自己的工程&#xff0c;直接从LiteOS源码获取开始 关于STM32CubeMX的安装&#xff0c;看我另一篇博客STM32CubeMX安装 工程配置 创建新工程 选择芯片【STM32F…

ElasticSearch入门介绍和实战

目录 1.ElasticSearch简介 1.1 ElasticSearch&#xff08;简称ES&#xff09; 1.2 ElasticSearch与Lucene的关系 1.3 哪些公司在使用Elasticsearch 1.4 ES vs Solr比较 1.4.1 ES vs Solr 检索速度 2. Lucene全文检索框架 2.1 什么是全文检索 2.2 分词原理之倒排索引…