Mysql底层原理五:如何设计、用好索引

1.索引的代价

空间上的代价

时间上的代价

每次对表中的数据进⾏增、删、改操作时,都需要去修改各个B+树索引。⽽且我们讲过,B+树每层节点都是按照索引列的值从⼩到⼤的顺序排序⽽组成了双 向链表。不论是叶⼦节点中的记录,还是内节点中的记录(也就是不论是⽤户记录还是⽬录项记录)都是按照索引列的值从⼩到⼤的顺序⽽形成了⼀个单向链 表。⽽增、删、改操作可能会对节点和记录的排序造成破坏,所以存储引擎需要额外的时间进⾏⼀些记录移位,⻚⾯分裂、⻚⾯回收啥的操作来维护好节点和 记录的排序。如果我们建了许多索引,每个索引对应的B+树都要进⾏相关的维护操作,这还能不给性能拖后腿么?

总结:

所以说,一个表上索引建的越多,就会占用越多的存储空间,在增删改的时候性能就会越差。

2.索引适用的条件

为了将索引的效能发挥最大,我们需要对索引由深刻的认识。下面,我们通过查询来更加深入理解索引的使用方式。

1.1 准备

建立表:

CREATE	TABLE	person_info(
   	id	INT	NOT	NULL	auto_increment,
   	name	VARCHAR(100)	NOT	NULL,
   	birthday	DATE	NOT	NULL,
   	phone_number	CHAR(11)	NOT	NULL,
   	country	varchar(100)	NOT	NULL,
   	PRIMARY	KEY	(id),
   	KEY	idx_name_birthday_phone_number	(name,	birthday,	phone_number)
);

对应这个表,有几点需要注意:

  1. 表中的主键是id,Innodo存储引擎会自动为id生成聚簇索引
  2. 我们额外定义了⼀个⼆级索引idx_name_birthday_phone_number,它是由3个列组成的联合索引。所以在这个索引对应的B+树的叶⼦节点处存储的⽤户记录 只保留name、birthday、phone_number这三个列的值以及主键id的值,并不会保存country列的值。

直接看一下二级索引的图示:

从图中可以看出:

  1. 先按照name列的值进行升序
  2. 如果name一样,就按照birthday列进行升序
  3. 如果birthday一样,就按照phone_numer进行升序

这个排序十分重要,因为只有页面和记录排好序,我们才可以通过二分法快速查找。

1.2 索引发挥作用

1.2.1 全值匹配

如果我们的搜索条件中的列和索引列一致的话,这种情况就称为全值匹配,比方说下面这个条件:

SELECT
	* 
FROM
	person_info 
WHERE
	NAME = 'Ashburn' 
	AND birthday = '1990-09-27' 
	AND phone_number = '15123983239';

这个查询过程很简单,先按照name,接着birthday,最后phone_numer

如果 where后面的查询条件顺序改一下会有什么影响嘛?

SELECT
	* 
FROM
	person_info 
WHERE
	birthday = '1990-09-27' 
	AND phone_number = '15123983239' 
	AND NAME = 'Ashburn';

答案:没有影响,Mysql查询优化器会按照可以使用索引中列的顺序来决定先使用哪个条件。

1.2.2 匹配最左边列

有时候,我们不想全值匹配,只是通过一个列,比如下面:

SELECT
	* 
FROM
	person_info 
WHERE
	NAME = 'Ashburn';

或者

SELECT
	* 
FROM
	person_info 
WHERE
	NAME = 'Ashburn' 
	AND birthday = '1990-09-27';

只要where条件后面按照索引顺序,但又不是全值匹配,都会走索引。因为B+树的数据⻚和记录先是按照name列的值排序的,在name列的值相同的情况下才使⽤birthday列进⾏排序,也就是说name列的值不同的 记录中birthday的值可能是⽆序的。

但是:像下面这种方式就不会走索引了:

SELECT
	* 
FROM
	person_info 
WHERE
	birthday = '1990-09-27';

总结一下

  • 在联合索引时,如果想要使用索引,where 条件后面顺序一定要和索引保持顺序,这有点像找个人一样,刚开始拿姓匹配,如果匹配不上就第二个字,再匹配不上就第三个字。。。

1.2.3 匹配列前缀

走索引:

SELECT
	* 
FROM
	person_info 
WHERE
	NAME LIKE 'As%';

不走索引:

SELECT	*	FROM	person_info	WHERE	name	LIKE	'%As%';

原因:Mysql无法定位记录的位置,因为可能性太多了,可以时AAS,aAS,甚至aAas。只有记录无序,Mysql就无法走索引,只能全表扫描了。

像这种的匹配规则是这样的,其实和列匹配差不多:

  1. 先比较字符串的第一个字符
  2. 第一个字符一样就比较第二个字符
  3. 第二个字符如果一样就比较第三个字符,如果一样,继续往后,不一样就终止。

案例:

1.2.4 匹配范围值

回头看我们idx_name_birthday_phone_number索引的B+树示意图,所有记录都是按照索引列的值从⼩到⼤的顺序排好序的,所以这极⼤的⽅便我们查找索引列的 值在某个范围内的记录。⽐⽅说下边这个查询语句:

走索引:

SELECT	*	FROM	person_info	WHERE	name	>	'Asa'	AND	name	<	'Barlow';

不走索引:

SELECT
	* 
FROM
	person_info 
WHERE
	NAME > 'Asa' 
	AND NAME < 'Barlow' AND birthday > '1980-01-01';

上边这个查询可以分为两个部分:

  1. 通过条件name > ‘Asa’ AND name < 'Barlow’来对name进⾏范围,查找的结果可能有多条name值不同的记录
  2. 对这些name值不同的记录继续通过birthday > '1980-01-01’条件继续过滤

这样⼦对于联合索引idx_name_birthday_phone_number来说,只能⽤到name列的部分,⽽⽤不到birthday列的部分,因为只有name值相同的情况下才能⽤ birthday列的值进⾏排序,⽽这个查询中通过name进⾏范围查找的记录中可能并不是按照birthday列进⾏排序的,所以在搜索条件中继续以birthday列进⾏查找 时是⽤不到这个B+树索引的。

总结一下:

**为什么加上个birthday条件就用不上索引,其实说到底,就是通过name查找出来的记录birthday不是有序的。比如说 ASA  1980-01-01、ASAa  1979-01-01、Barlow 1981-01-01取出来的birthday不就无序了嘛  **

1.2.5 精确匹配某一列并范围匹配另外一列

对于同⼀个联合索引来说,虽然对多个列都进⾏范围查找时只能⽤到最左边那个索引列,但是如果左边的列是精确查找,则右边的列可以进⾏范围查找,⽐⽅说 这样:

SELECT
	* 
FROM
	person_info 
WHERE
	NAME = 'Ashburn' 
	AND birthday > '1980-01-01' 
	AND birthday < '2000-12-31' AND phone_number > '15100000000';

这个查询的条件可以分成3个部分:

  1. name = ‘Ashburn’,对name列进⾏精确查找,当然可以使⽤B+树索引了。
  2. birthday > ‘1980-01-01’ AND birthday < ‘2000-12-31’,由于name列是精确查找,所以通过name = 'Ashburn’条件查找后得到的结果的name值都是相 同的,它们会再按照birthday的值进⾏排序。所以此时对birthday列进⾏范围查找是可以⽤到B+树索引的。
  3. phone_number > ‘15100000000’,通过birthday的范围查找的记录的birthday的值可能不同,所以这个条件⽆法再利⽤B+树索引了,只能遍历上⼀步查询 得到的记录。

同理,下边的查询也是可能用到这个联合索引的:

SELECT
	* 
FROM
	person_info 
WHERE
	NAME = 'Ashburn' 
	AND birthday = '1980-01-01' 
	AND phone_number > '15100000000';

1.2.6 排序

我们在写查询语句的时候可以通过order by来进行升序。一般情况下,是把数据加载到内存中,然后在使用排序算法在内存中进行排序,但是如果数据集太大,**可能需要通过磁盘来存放中间结果,排序完再返回到客户端。**再磁盘中进行排序慢的和蜗牛一样,这时候通过索引直接取出来,不就不需要排序了吗,是不是特别快,哈哈

SELECT	*	FROM	person_info	ORDER	BY	name,	birthday,	phone_number	LIMIT	10;

这个查询的结果集需要先按照name值排序,如果记录的name值相同,则需要按照birthday来排序,如果birthday的值相同,则需要按照phone_number排序。

使用联合索引排序需要注意事项

1) order by 列的顺序一定要和建立联合索引的顺序一致

2) 等值+order by 其余索引列可以使用联合索引

3) ASC、DESC混用

对于联合索引进行排序的场景,要求各个列要么都是ASC排序,要么都是DESC排序

但是,对于先按照name升序,再按照birthday降序的话,比如这样的:

SELECT	*	FROM	person_info	ORDER	BY	name,	birthday	DESC	LIMIT	10;

这样如果使用索引的话,过程是这样的:

  1. 先从索引的最左边确定name列最⼩的值,然后找到name列等于该值的所有记录,然后从name列等于该值的最右边的那条记录开始往左找10条记录。
  2. 如果name列等于最⼩的值的记录不⾜10条,再继续往右找name值第⼆⼩的记录,重复上边那个过程,直到找到10条记录为⽌。

累不累,累啊,对于索引的使用一点也不高效,设计Mysql觉得这样还不如直接文件排序来的快,所以联合索引的各个排序列的排序顺序必须是一样的

1】 where子句中出现非排序使用到的索引列,如果说:
SELECT	*	FROM	person_info	WHERE	country	=	'China'	ORDER	BY	name	LIMIT	10;

这个查询是把符合条件的数据先查询出来然后排序,这样是使用不到索引的。

2】 排序列包含非同一个索引的列

有时候⽤来排序的多个列不是⼀个索引⾥的,这种情况也不能使⽤索引进⾏排序,⽐⽅说:

SELECT	*	FROM	person_info	ORDER	BY	name,	country	LIMIT	10;

name和country并不属于⼀个联合索引中的列,所以⽆法使⽤索引进⾏排序,⾄于为啥我就不想再唠叨了,⾃⼰⽤前边的理论⾃⼰捋⼀捋把~

3】 排序列使用了复杂的表达式

要想使⽤索引进⾏排序操作,必须保证索引列是以单独列的形式出现,⽽不是修饰过的形式,⽐⽅说这样:

SELECT	*	FROM	person_info	ORDER	BY	UPPER(name)	LIMIT	10;

使⽤了UPPER函数修饰过的列就不是单独的列啦,这样就⽆法使⽤索引进⾏排序啦。

1.2.7 分组

有时候我们为了⽅便统计表中的⼀些信息,会把表中的记录按照某些列进⾏分组。⽐如下边这个分组查询:

SELECT NAME,
	birthday,
	phone_number,
	COUNT( * ) 
FROM
	person_info 
GROUP BY
	NAME,
	birthday,
	phone_number

这个查询相当于做了这3次分组操作:

  1. 先按照name分组,把所有name相同的分成一个个大组
  2. 一个个大组再按照birthday分成一个个小组
  3. 一个个小组再按照phone_numer分成一个个更小的组

3.回表的代价

这个东西对于我来说,很好理解就放张整图了:

索引覆盖

问题:回表的代价这么大,我们怎么减少拿?

为了彻底告别回表操作带来的性能损耗,我们建议:最好在查询列表⾥只包含索引列,⽐如这样:

SELECT NAME,
	birthday,
	phone_number 
FROM
	person_info 
WHERE
	NAME > 'Asa' 
	AND NAME < 'Barlow'

因为我们只查询name, birthday, phone_number这三个索引列的值,所以只需要通过联合索引就可以得到,就可以不用聚簇索引回表查询 剩余列,也就是country的值了。 我们把这种只查询索引排序列的方式称之为索引覆盖

排序操作也优先使用索引覆盖的方式查询,比方说这个查询:

SELECT NAME,
	birthday,
	phone_number 
FROM
	person_info 
ORDER BY
	NAME,
	birthday,
	phone_number;

虽然这个查询中没有LIMIT⼦句,但是采⽤了覆盖索引,所以查询优化器就会直接使⽤idx_name_birthday_phone_number索引进⾏排序⽽不需要回表操作了。

当然,如果业务需要查询出索引以外的列,那还是以保证业务需求为重。但是我们很不⿎励⽤*号作为查询列表,最好把我们需要查询的列依次标明。

4.如何挑选索引

4.1 只为搜索、排序或者分组的列创建索引

只为出现在WHERE⼦句中的列、连接⼦句中的连接列,或者出现在ORDER BYGROUP BY⼦句中的列创建索引。而出现在查询列表中的列就不没必要建立索引了:

SELECT	birthday,	country	FROM	person_name	WHERE	name	=	'Ashburn';

像查询列表中的birthday、country这两个列就不需要建⽴索引,我们只需要为出现在WHERE⼦句中的name列创建索引就可以了。

4.2 考虑列的基数

列的基数指的是某一列中不重复数据的个数,比方说某个列包含值2, 5, 8, 2, 5, 8, 2, 5, 8,虽然有9条记录,但该列的基数却是3。也就是说,在记录⾏数⼀ 定的情况下,列的基数越⼤,该列中的值越分散,列的基数越⼩,该列中的值越集中。

  • 这个列的基数指标⾮常重要,直接影响我们是否能有效的利⽤索引。假设某 个列的基数为1,也就是所有记录在该列中的值都⼀样,那为该列建⽴索引是没有⽤的,因为所有值都⼀样就⽆法排序,⽆法进⾏快速查找了
  • 如果某个建⽴ 了⼆级索引的列的重复值特别多,那么使⽤这个⼆级索引查出的记录还可能要做回表操作,这样性能损耗就更⼤了

最好为那些列的基数⼤的列 建⽴索引,为基数太⼩列的建⽴索引效果可能不好。

4.3 索引列的类型尽量小

我们在定义表结构的时候要显示的指定列的类型,以整数类型为理,以整数类型为例,有TINYINT、MEDIUMINT、INT、BIGINT这几种,它们占用的存储空间依次递增,我们这里所说的类型大小指的就是 **该类型表示的数据范围大小。**能表示的整数范围当然也是依次递增,如果我们想要对某个整数列建⽴索引的话,在表示的整数范围允许 的情况下,尽量让索引列使⽤较⼩的类型, 比如,我们能用INT就不要使用BIGINT,能使⽤MEDIUMINT就不要使⽤INT,这是因为:

  • 数据类型越⼩,在查询时进⾏的⽐较操作越快(这是CPU层次的东东)
  • 数据类型越⼩,索引占⽤的存储空间就越少,在⼀个数据⻚内就可以放下更多的记录,从⽽减少磁盘I/O带来的性能损耗,也就意味着可以把更多的数据⻚缓 存在内存中,从⽽加快读写效率。

这个建议对于表的主键来说更加适⽤,因为不仅是聚簇索引中会存储主键值,其他所有的⼆级索引的节点处都会存储⼀份记录的主键值,如果主键适⽤更⼩的数 据类型,也就意味着节省更多的存储空间和更⾼效的I/O。

4.4 索引字符串的前缀

4.5 让索引列在比较表达式中单独出现

假设表中有一个整数列my_col,我们为这个列建立索引,下面两个where子句虽然语义上是一致的,但在执行效率上却有很大差别:

  1. WHERE my_col * 2 < 4
  2. WHERE my_col < 4/2

第1个WHERE⼦句中my_col列并不是以单独列的形式出现的,⽽是以my_col * 2这样的表达式的形式出现的,存储引擎会依次遍历所有的记录,计算这个表达式的 值是不是⼩于4,所以这种情况下是使⽤不到为my_col列建⽴的B+树索引的。⽽第2个WHERE⼦句中my_col列并是以单独列的形式出现的,这样的情况可以直接使 ⽤B+树索引。

如果索引列在⽐较表达式中不是以单独列的形式出现,⽽是以某个表达式,或者函数调⽤形式出现的话,是⽤不到索引的。

4.6 主键选择-最好是自增

我们知道,对于⼀个使⽤InnoDB存储引擎的表来说,在我们没有显式的创建索引时,表中的数据实际上都是存储在聚簇索引的叶⼦节点的。⽽记录⼜是存储在数据 ⻚中的,数据⻚和记录⼜是按照记录主键值从⼩到⼤的顺序进⾏排序,所以如果我们插⼊的记录的主键值是依次增⼤的话,那我们每插满⼀个数据⻚就换到下⼀ 个数据⻚继续插,⽽如果我们插⼊的主键值忽⼤忽⼩的话,这就⽐较麻烦了,假设某个数据⻚存储的记录已经满了,它存储的主键值在1~100之间:

可这个数据⻚已经满了啊,再插进来咋办呢?我们需要把当前⻚⾯分裂成两个⻚⾯,把本⻚中的⼀些记录移动到新创建的这个⻚中。⻚⾯分裂和记录移位意味着 什么?意味着:性能损耗。所以如果我们想尽量避免这样⽆谓的性能损耗,最好让插⼊的记录的主键值依次递增,这样就不会发⽣这样的性能损耗了。所以我们建议:让主键具有AUTO_INCREMENT,让存储引擎⾃⼰为表⽣成主键,⽽不是我们⼿动插⼊,比如说我们可以这么定义person_info表:

4.7 冗余和重复索引

有时候有的人有意或者无意的就对同一列创建了多个索引,比方说这样写建表语句:

我们知道,通过 idx_name_birthday_phone_number索引就可以对 name进行快读搜索,再创建一个专门针对 name列的索引就算是一个 **冗余索引,**维护这个索引只 会增加维护的成本,并不会对搜索有什么好处。

另外一种情况就是,我们对某个列重复建立索引,比方说这样:

我们看到,c1既是主键、⼜给它定义为⼀个唯⼀索引,还给它定义了⼀个普通索引,可是主键本身就会⽣成聚簇索引,所以定义的唯⼀索引和普通索引是重复 的,这种情况要避免。

5.总结

5.1 B+树索引在空间和时间上都有代价,所以没事⼉别瞎建索引。

5.2 B+树索引适⽤于下边这些情况:

  • 全值匹配
  • 匹配左边的列
  • 匹配范围值
  • 精确匹配某⼀列并范围匹配另外⼀列
  • 用于排序
  • 用于分组

这里我自己的总结:怎么判断走不走索引?可以看一下这个操作之前的数据是否是有序的,Mysql能不能快速查询,还是得一个个查询,有序的并且能够快速查询(就像快速扫描一样)肯定是能走索引的。

5.3 在使用索引时要注意以下事项:

  • 只为⽤于搜索、排序或分组的列创建索引
  • 为列的基数⼤的列创建索引
  • 索引列的类型尽量⼩
  • 可以只对字符串值的前缀建⽴索引 只有索引列在⽐较表达式中单独出现才可以适
  • 为了尽可能少的让聚簇索引发⽣⻚⾯分裂和记录移位的情况,建议让主键拥有AUTO_INCREMENT属性。
  • 定位并删除表中的重复和冗余索引
  • 尽量使⽤覆盖索引进⾏查询,避免回表带来的性能损耗。

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

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

设计模式实践

一、工厂模式 这里只讲简单工厂模式&#xff0c;详细的可以参考Java工厂模式&#xff08;随笔&#xff09;-CSDN博客。工厂类会根据不同的参数或条件来决定创建哪种对象&#xff0c;这样客户端只需要知道自己需要什么对象&#xff0c;而不需要关心对象的创建过程&#xff01; …

Golang 开发实战day06 - Boolean Conditional

&#x1f3c6;个人专栏 &#x1f93a; leetcode &#x1f9d7; Leetcode Prime &#x1f3c7; Golang20天教程 &#x1f6b4;‍♂️ Java问题收集园地 &#x1f334; 成长感悟 欢迎大家观看&#xff0c;不执着于追求顶峰&#xff0c;只享受探索过程 Golang 教程06 - Boolean &a…

分布式锁的原子性问题

4.6 分布式锁的原子性问题 更为极端的误删逻辑说明&#xff1a; 线程1现在持有锁之后&#xff0c;在执行业务逻辑过程中&#xff0c;他正准备删除锁&#xff0c;而且已经走到了条件判断的过程中&#xff0c;比如他已经拿到了当前这把锁确实是属于他自己的&#xff0c;正准备删…

如何在CentOS安装Nexus容器无公网IP远程管理本地仓库

文章目录 1. Docker安装Nexus2. 本地访问Nexus3. Linux安装Cpolar4. 配置Nexus界面公网地址5. 远程访问 Nexus界面6. 固定Nexus公网地址7. 固定地址访问Nexus Nexus是一个仓库管理工具&#xff0c;用于管理和组织软件构建过程中的依赖项和构件。它与Maven密切相关&#xff0c;可…

数据通讯平台解决方案(Word原件获取)

1.数据通讯平台方案 1.1.系统概述 1.2.需求分析 1.3.重难点分析 1.4.重难点解决措施 2.系统架构设计 2.1.系统架构图 系统机构图 2.2.业务架构设计 (1) MQ消息服务 (2) TCP通讯服务 (3) CoAP通讯服务 (4) MQTT通讯服务 (5) 资源管理服务 2.3.主流技术架构分析 纵向设计方案 2.4…

QGraphics框架场景中图元的移除与析构

1.场景里面使用removeItem函数&#xff0c;这个函数官方给出如下解释 注意这个词remove只是移除&#xff0c;并不是delete掉&#xff0c;所以只是场景中&#xff08;显示出来的图元&#xff09;没有了&#xff0c;空间还是存在。 举个代码例子&#xff1a; void MyGraphicsV…

USACO 2024 Open Bronze铜组题解

迟到了一个月的题解...... Logical Moos: 啊这题放在铜组T1雀食有点BT...... 首先&#xff0c;我们关注l前第一和r最后那两组。如果这俩有一个是true&#xff0c;那答案肯定也是true。 否则&#xff0c;在l和r外边的都是false。那我们就只用仔细看l和r中间的玩意儿。对于l和…

三月以来的黄金暴涨 ,华尔街都看不懂

本轮黄金大幅上涨无法按照美联储政策逻辑解释&#xff0c;央行的购金需求也无法合理化金价的历史新高&#xff0c;而金价的大涨也与黄金ETF流出相背&#xff0c;推动反弹的“神秘力量”令分析师困惑不已。 黄金上涨的情况往往会出现在美联储开启降息周期后&#xff0c;如果市场…

Linux 之 定时任务调度器-crond(crontab)服务

Linux系列文章&#xff1a; Windows本地如何添加域名映射&#xff1f;&#xff08;修改hosts文件&#xff09;_本机域名映射-CSDN博客 Linux安装mysq 8.0服务端和客户端(亲测保成功&#xff09;_linux安装mysql客户端-CSDN博客 linux-man命令的使用及练习_man命令执行后无法…

微服务架构下,如何通过弱依赖原则保障系统高可用?

前言 当我初次接触高可用这个概念的时候&#xff0c;对高可用的【少依赖原则】和【弱依赖原则】的边界感模糊&#xff0c;甚至有些“傻傻分不清楚”。这两个原则都关注降低模块之间的依赖关系&#xff0c;但它们之间的确存在某些差异。 那么&#xff0c;「少依赖原则」和「弱…

Windows深度学习环境----Cuda version 10.2 pytorch3d version 0.3.0

Requirements Python version 3.8.5Pytorch version: pytorch1.6.0 torchvision0.8.2 torchaudio0.7.0 cudatoolkit10.2.89pytorch3d version 0.3.0Cuda version 10.2 感觉readme文件里的不适配&#xff0c;跟pytorch官网不同 以前的 PyTorch 版本 |PyTorch的 # CUDA 10.2 c…

面板数据回归模型(二)房价的影响因素分析

1.数据来源 本文选择我国出一线城市房价均值、新一线城市房价均值、二线城市房价均值、货币供应量和利率。选取2002-2018年的数据,共17组数据,由于数据的自然对数变换不改变原有的协整关系,并能使其趋势线性化,消除时间序列中存在的异方差现象,所以对所有数据取其自然对数…

程序员简历程序员简历.pdf

你们在制作简历时&#xff0c;是不是基本只关注两件事&#xff1a;简历模板&#xff0c;还有基本信息的填写。 当你再次坐下来更新你的简历时&#xff0c;可能会发现自己不自觉地选择了那个“看起来最好看的模板”&#xff0c;填写基本信息&#xff0c;却没有深入思考如何使简历…

聊一下Redis实现分布式锁的8大坑

前两篇文章都在讲 Redis 的 5 大常用数据类型&#xff0c;以及典型的 10 大应用场景。 那么今天就来看看 Redis 实现分布式锁。 聊一聊Redis实现分布式锁的8大坑 Redis中5大常见数据类型用法 工作中Redis用的最多的10种场景 在分布式系统中&#xff0c;保证资源的互斥访问是…

新火种AI|拳打百度,脚踢阿里...令国产大模型危机感爆棚的kimi强势上线!

作者&#xff1a;小岩 编辑&#xff1a;冰冰 Sora大火后&#xff0c;生成式AI的高光时候终于轮到了国产大模型。2024年3月&#xff0c;Kimi智能助手在市场上掀起了一股狂热的热潮。 Kimi是由时下大火的AI初创公司——北京月之暗面科技有限公司所推出的一款智能助手&#xff…

自动化测试框架 - Unittest 学习笔记速查

文章目录 UnitTest 简介UnitTest 核心UnitTest 原理UnitTest 断言函数TestCase&#xff08;用例&#xff09;基本用法执行结果 TestFixture&#xff08;夹具&#xff09;方法级夹具类级夹具模块级夹具 TestSuite&#xff08;套件&#xff09;TestLoader&#xff08;加载器&…

文件/目录的权限和归属

一.文件/目录的权限和归属的简要分析与概括 1.程序访问文件时的权限&#xff0c;取决于此程序的发起者 * 进程的发起者&#xff0c;同文件的属主&#xff1a;则应用文件属主权限 *进程的发起者&#xff0c;属于文件属组&#xff1b;则应用文件属组权限 *应用文件“其它”权…

【云贝教育】Oracle 19c OCP 083题库解析(71)

本文为云贝教育郭一军&#xff08;微信&#xff1a;guoyJoe&#xff09;原创&#xff0c;请尊重知识产权&#xff0c;转发请注明出处&#xff0c;不接受任何抄袭、演绎和未经注明出处的转载。 71、Which two are true about an Oracle gold image-based installation in Oracle…

指尖论文靠谱不 #学习方法#媒体#职场发展

指尖论文是当前市场上一款非常实用的论文写作、查重、降重工具。许多学生、研究人员和教师都已经开始使用它&#xff0c;因为它相当靠谱、方便、易用且高效。 首先&#xff0c;指尖论文的查重功能非常强大&#xff0c;能够及时准确地检测出文本中的相似内容&#xff0c;帮助用户…

源清天木生物科技带您抢先体验2024国际生物发酵展

参展企业介绍 优质的种质资源是生物产业的核心&#xff0c;也是农业的核心&#xff01; 高效的选育优质的种质资源&#xff0c;是生物产业和农业最重要工作之一。 天木生物&#xff0c;致力于高效生物育种技术开发和特色生物育种装备开 发&#xff0c;并依托自主研发的技术和装…