MYSQL

给你机会不中用

于 2023-07-28 10:33:08 发布

阅读量117

点赞数

文章标签： mysql 数据库

本文链接：https://blog.csdn.net/weixin_45006608/article/details/131975138

版权

1、 mysql索引分/（种）类

主键索引（Primary Key Index）：

用于唯一标识表中的每一行数据。主键索引是最常用的索引类型，它保证了索引列的唯一性和快速查找。

应用场景：用户 ID、订单表的订单号
唯一索引（Unique Index）：

用于保证索引列的唯一性，不允许重复的值。与主键索引不同的是，唯一索引列允许为空值。
普通索引（Normal Index）：

也称为非唯一索引，是最基本的索引类型。它可以快速加速数据的查找，但允许索引列出现重复的值。
组合索引（Composite Index）：效率大于索引合并。

是一种包含多个列的索引类型，用于加速涉及多个列的查询条件。通过将多个列的值组合成一个索引项，可以提高查询的性能和效率。
全文索引（Full-Text Index）：

用于对文本内容进行全文搜索。全文索引适用于大量的自然语言文本数据，如文章、博客等。它可以进行高效的全文搜索，并支持关键词的模糊匹配。
索引合并：

用于将多个索引的访问路径合并为一个更高效的访问路径，以提高查询性能。

根据物理结构存储分类：可以分为聚簇索引和非聚簇索引

根据数据结构存储分类：哈希索引、B树索引、B+树索引。

2、mysql的四种隔离级别，解决哪些问题，

读未提交（Read Uncommitted）：解决了更新丢失，但可能会出现脏读
- 解决的问题：没有提供真正的隔离，一个事务可以读取到另一个事务尚未提交的脏数据，可能会导致脏读问题。
- 特点：最低级别的隔离，事务间相互影响最大，没有并发控制，存在较高的数据不一致风险。
如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据，该隔离级别可以通过“排他写锁”，但是不排斥读线程实现。这样就避免了更新丢失，却可能出现脏读，也就是说事务 B 读取到了事务 A 未提交的数据
读已提交（Read Committed）：解决了更新丢失和脏读问题
- 解决的问题：保证了一个事务只能读取到已经提交的数据，避免了脏读问题。
- 特点：通过在读取数据时对所读取的行进行加锁来实现，可以避免脏读问题，但在并发情况下可能会出现不重复读问题。
如果是一个读事务(线程)，则允许其他事务读写，如果是写事务将会禁止其他事务访问该行数据，该隔离级别避免了脏读，但是可能出现不可重复读。事务 A 事先读取了数据，事务 B 紧接着更新了数据，并提交了事务，而事务 A 再次读取该数据时，数据已经发生了改变。
可重复读（Repeatable Read）：解决了更新丢失、脏读、不可重复读、但是还会出现幻读
- 解决的问题：保证了一个事务中的查询操作在整个事务过程中看到的数据是一致的，避免了脏读和重复读问题。
- 特点：通过在事务开始时对所读取的全部行进行加锁来实现，锁定范围较大，可能导致并发性能下降。
可重复读取是指在一个事务内，多次读同一个数据，在这个事务还没结束时，其他事务不能访问该数据(包括了读写)，这样就可以在同一个事务内两次读到的数据是一样的，因此称为是可重复读隔离级别，读取数据的事务将会禁止写事务(但允许读事务)，写事务则禁止任何其他事务(包括了读写)，这样避免了不可重复读和脏读，但是有时可能会出现幻读。(读取数据的事务)可以通过“共享读锁 ” 和 “排他写锁”实现。
可序化（Serializable）：
- 解决的问题：提供最高级别的隔离，确保事务的完全隔离性，避免了脏读、不可重复读和幻读问题。
- 特点：通过对事务进行序列化执行来实现，事务间完全隔离，但可能会导致并发性能严重下降。
提供严格的事务隔离，它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行，如果仅仅通过“行级锁”是无法实现序列化的，必须通过其他机制保证新插入的数据不会被执行查询操作的事务访问到。序列化是最高的事务隔离级别，同时代价也是最高的，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻读。

3、事务的各个隔离级别都是如何实现的？

读未提交

读未提交，就不⽤多说了，采取的是读不加锁原理。事务读不加锁，不阻塞其他事务的读和写。事务写阻塞其他事务写，但不阻塞其他事务读；

读取已提交&可重复读

读取已提交和可重复读级别利⽤了 ReadView 和 MVCC ，也就是每个事务只能读取它能看到的版本（ReadView）。

READ COMMITTED：每次读取数据前都⽣成⼀个 ReadView

REPEATABLE READ ：在第⼀次读取数据时⽣成⼀个 ReadView

串⾏化

串⾏化的实现采⽤的是读写都加锁的原理。

串⾏化的情况下，对于同⼀⾏事务，写会加写锁，读会加读锁。当出现读写锁冲突的时候，后访问的事务必须等前⼀个事务执⾏完成，才能继续执⾏。

4、MySQL 中有哪⼏种锁

如果按锁粒度划分，有以下 3 种：

表锁：开销⼩，加锁快；锁定⼒度⼤，发⽣锁冲突概率⾼，并发度最低;不会出现死锁。
⾏锁：开销⼤，加锁慢；会出现死锁；锁定粒度⼩，发⽣锁冲突的概率低，并发度⾼。
⻚锁：开销和加锁速度介于表锁和⾏锁之间；会出现死锁；锁定粒度介于表锁和⾏锁之间，并发度⼀般

如果按照兼容性，有两种，

共享锁（S Lock）,也叫读锁（read lock），相互不阻塞。
排他锁（X Lock），也叫写锁（write lock），排它锁是阻塞的，在⼀定时间内，只有⼀个请求能执⾏写⼊，并阻⽌其它锁读取正在写⼊的数据

5、mysql死锁及应用场景

MySQL死锁是指多个事务在并发执行时发生相互等待对方持有的锁资源，导致它们无法继续执行并永久阻塞的情况。

应用场景：

并发写入：当多个事务同时对相同的数据进行写操作时，可能会发生死锁。例如，多个事务同时更新同一行记录，导致互斥条件发生。
外键关联：在存在外键关联的表中，进行插入、更新、删除操作时，可能会涉及多个表的数据修改，引发死锁。例如，事务A修改表X的数据同时请求表Y的锁，而事务B修改表Y的数据同时请求表X的锁，形成循环等待条件。
复杂查询：在复杂的查询语句中，涉及多个表的连接、子查询和多个锁资源的操作，可能会导致死锁的发生。特别是在高并发的环境下，由于锁资源的竞争，死锁的概率会增加。

6、聚簇索引和非聚簇索引（二级索引）的区别

聚簇索引：数据行的物理存储顺序与聚簇索引的顺序一致。即，表的数据按照聚簇索引的键值进行排序并存储在磁盘上。每个表只能有一个聚簇索引。聚簇索引的键值必须是唯一的，用于唯一标识表中的每一行数据。
非聚簇索引：索引数据和实际数据的存储方式是分离的。索引文件包含索引列的值及指向实际数据行的指针。数据行的物理存储顺序与索引无关。非聚簇索引的键值可以是重复的，允许多个行具有相同的索引值。

应用场景：

聚簇索引的应用场景：将聚簇索引应用于主键列是一种常见的使用场景。需要频繁进行范围查询（例如根据日期范围或数值范围进行查询）

非聚簇索引的应用场景：频繁单值查询。查询含外键关系的表。

7、Mysql怎么添加索引？

创建表时添加索引： 在创建表的时候，可以在列定义后面使用 INDEX 或 KEY 关键字来添加索引。

使用 ALTER TABLE 语句添加索引： 如果表已经创建，可以使用 ALTER TABLE 语句来添加索引。

添加唯一索引： 如果想要创建唯一索引，确保索引列的值是唯一的，可以使用 UNIQUE 关键字。

添加主键索引： 可以使用 PRIMARY KEY 关键字将某一列或多列设为主键索引。

8、索引会不会失效？索引怎么失效？举个例子？

索引有可能失效。索引失效指的是在某些情况下，数据库查询优化器无法有效地使用索引，从而导致索引对查询性能的提升作用减弱或完全失效。

查询条件包含 or，可能导致索引失效
如果字段类型是字符串，where 时⼀定⽤引号括起来，否则会因为隐式类型转换，索引失效
like 通配符可能导致索引失效。
联合索引，查询时的条件列不是联合索引中的第⼀个列，索引失效。
在索引列上使⽤ mysql 的内置函数，索引失效。
对索引列运算（如，+、-、*、/），索引失效。
索引字段上使⽤（！= 或者 < >，not in）时，可能会导致索引失效。
索引字段上使⽤ is null， is not null，可能导致索引失效。
左连接查询或者右连接查询查询关联的字段编码格式不⼀样，可能导致索引失效。
MySQL 优化器估计使⽤全表扫描要⽐使⽤索引快,则不使⽤索引。

9、SQL优化怎么优化

选择合适的数据类型： 使用适当的数据类型可以减少存储空间和提高查询性能。选择最小的数据类型来存储数据，例如使用 INT 替代 BIGINT，可以减少磁盘和内存消耗，并加快查询速度。
创建适当的索引： 添加合适的索引可以大幅提高查询性能。分析查询语句，确定经常使用的列和常见的查询条件，并在这些列上创建索引。但要注意过多的索引会增加写操作的开销，因此需要权衡索引的数量和查询性能的提升。
优化查询语句： 优化查询语句是 SQL 优化的核心。使用 EXPLAIN关键字来分析查询计划，并根据分析结果进行调整。避免使用复杂的子查询和嵌套查询，尽量简化查询语句。
使用连接池： 对于频繁连接数据库的应用程序，使用连接池可以减少连接建立和销毁的开销。连接池可以重复利用连接对象，提高数据库访问性能。
合理分页查询： 当需要进行分页查询时，使用合理的分页机制。使用 LIMIT关键字限制返回的行数，避免一次性返回过多的数据。同时，确保分页查询语句的查询条件和排序条件可以有效利用索引。
定期维护和优化： 定期进行数据库的维护和优化工作，包括重新构建索引、收集统计信息、清理不再使用的索引和优化查询语句。这些操作可以保持数据库的健康状态并提高查询性能。

10、sql语句的优化

**SQL语句中IN包含的值不应过多:**例如：select id from t where num in(1,2,3) 对于连续的数值，能用between就不要用in了；
SELECT语句务必指明字段名称: 禁止用 ***** 来查询，查找哪个字段,就写具体的字段.
只查询一条数据的时候，使用limit 1
避免在where子句中对字段进行null值判断: mysql会自动判断数据的分布情况判断数据中 null 多还是 not null 多, 然后决定走不走索引.

避免在where子句中对字段进行表达式操作: 避免列上函数运算

select  uid from user_test  WHERE uid*10=40;
上面的sql对字段就行了算术运算，这会造成引擎放弃使用索引，建议改成：
select  uid from user_test  WHERE uid=40/10;

对于联合索引来说，要遵守最左前缀法则:
不建议使用%前缀模糊查询:
避免使⽤ != 或者 <> 操作符
低版本避免使⽤ or 查询可以使⽤ union 或者⼦查询来替代
JOIN 优化

优化⼦查询

尽量使⽤ Join 语句来替代⼦查询，因为⼦查询是嵌套查询，⽽嵌套查询会新创建⼀张临时表，⽽临时表的创建与销毁会占⽤⼀定的系统资源以及花费⼀定的时间，同时对于返回结果集⽐较⼤的⼦查询，其对查询性能的影响更⼤

11、事务的特征

**原子性（Atomicity）😗*原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。

**一致性（Consistency）😗*事务开始前和结束后，数据库的完整性约束没有被破坏。比如 A 向 B 转账，不可能 A 扣了钱，B 却没收到。

**隔离性（Isolation）😗*隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如 A 正在从一张银行卡中取钱，在 A取钱的过程结束前，B 不能向这张卡转账。

**持久性（Durability）😗*持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

12、MySQL事务是怎么实现的？怎么保证的？

ACID是衡量事务的四个标准：原子性(Atomicity ）一致性(Consistency) 隔离性(Isolation) 持久性(Durability) 按照严格的标准，只有同时满足ACID特性才是事务.

事务的隔离性是通过数据库锁的机制实现的。
事务的⼀致性由 undo log 来保证：undo log 是逻辑⽇志，记录了事务的 insert、update、deltete 操作，回滚的时候做相反的 delete、update、insert 操作来恢复数据。
事务的原⼦性和持久性由 redo log 来保证：redolog 被称作重做⽇志，是物理⽇志，事务提交的时候，必须先将事务的所有⽇志写⼊ redo log 持久化，到事务的提交操作才算完成。

1、原子性实现原理：原子性实现关键：undo log

实现原子性的关键，是当事务回滚时能够撤销所有已经执行成功的SQL语句，InnoDB实现回滚，靠的是undo log，当事务对数据库进行修改时，InnoDB会生成对应的；如果事务执行失败或者调用了rollback，导致事务需要回滚，就利用undo log中的信息将数据回滚到修改之前的样子
undo log属于逻辑日志，它记录的是SQL执行相关的信息，当发生回滚时，InndDB会根据undo log的内容做与之前相反的工作，对于每个insert，回滚时会执行delete，对于每个update，回滚时会执行一个相反的update，将数据改回去。
以update操作为例，当事务执行update时，其生成的undo log中会包含被修改行的主键(一遍知道修改了哪些行)，修改了哪些列、这些列在修改前后的值的信息，回滚时便可以使用这些信息将数据还原到update之前的状态。

2、久性实现原理：redo log

redo log就被引入来解决这个问题(宕机导致BP中的数据没有刷新磁盘，造成数据丢失)，当数据被修改时，除了修改BP中的数据，还会在redo log中记录这次操作，当事务提交时，会调用fsync接口对 redo log进行刷盘，如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复，redo log采用的是WAL(Write-ahead logging，预写式日志), 所有修改先写入日志，在更新到BP，保证了数据不会因为MySQL宕机而丢失，从而满足了持久性的要求。

3、隔离性实现原理：

保证事务执行尽可能不受其他事务影响；InnoDB默认的隔离级别是RR(可重复读)，RR的实现主要基于锁机制（包含next-key lock）、MVCC（包括数据的隐藏列、基于undo log的版本链、ReadView）

4、一致性实现原理

13、Mvcc的实现原理

MVCC（Multi-Version Concurrency Control）是一种并发控制机制，用于管理并发事务的隔离性和一致性。MVCC通过为每个事务创建不同的数据版本来实现并发控制，每个事务只能看到在其开始时间之前提交的数据版本，从而避免了一些常见的并发问题，如脏读、不可重复读和幻读。

1、记录中的三个隐藏字段，一个唯一行号，一个记录创建的版本号，一个记录回滚的版本号。

在多版本并发控制中，为了保证数据操作在多线程过程中，保证事务隔离的机制，降低锁竞争的压力，保证较高的并发量。在每开启一个事务时，会生成一个事务的版本号，被操作的数据会生成一条新的数据行（临时），但是在提交前对其他事务是不可见的，对于数据的更新（包括增删改）操作成功，会将这个版本号更新到数据的行中，事务提交成功，将新的版本号更新到此数据行中，这样保证了每个事务操作的数据，都是互不影响的，也不存在锁的问题。
	6字节的事务ID(DB_TRX_ID)字段：用来标识最近一次对本行记录做修改(insert|update)的事务的标识符，即最后一次修改(insert|update)本行记录的事务id。至于delete操作，在innodb看来也不过是一次update操作，更新行中的一个特殊位将行表示为deleted ，并非真正删除。
	7字节的回滚指针(DB_ROLL_PTR)字段：指写入回滚段(rollback segment)的 undo log record (撤销日志记录记录)。如果一行记录被更新, 则 undo log record 包含 重建该行记录被更新之前内容所必须的信息。
	6字节的DB_ROW_ID字段：包含一个随着新行插入而单调递增的行ID，当由innodb自动产生聚集索引时，聚集索引会包括这个行ID的值，否则这个行ID不会出现在任何索引中。

2、undolog版本链

undo log是为回滚而用，具体内容就是copy事务前的数据库内容（行）到undo buffer，在适合的时间把undo buffer中的内容刷新到磁盘。undo buffer与redo buffer一样，也是环形缓冲，但当缓冲满的时候，undo buffer中的内容会也会被刷新到磁盘；与redo log不同的是，磁盘上不存在单独的undo log文件，所有的undo log均存放在主ibd数据文件中（表空间），即使客户端设置了每表一个数据文件也是如此。
对于 InnoDB 存储引擎，每⼀⾏记录都有两个隐藏列DB_TRX_ID、DB_ROLL_PTR
	DB_TRX_ID ，事务 ID，每次修改时，都会把该事务 ID 复制给 DB_TRX_ID ；
	DB_ROLL_PTR ，回滚指针，指向回滚段的 undo ⽇志。
由于每次变动都会先把 undo ⽇志记录下来，并⽤ DB_ROLL_PTR 指向 undo ⽇志地址。因此可以认为，对该条记录的修改⽇志串联起来就形成了⼀个版本链 ，版本链的头节点就是当前记录最新的值。

3、read view

Read View 就是事务执⾏快照读时，产⽣的读视图，相当于某时刻表记录的⼀个快照，通过这个快照，我们可以获取：
	m_ids ：表示在⽣成 ReadView 时当前系统中活跃的读写事务的事务id列表。
	min_trx_id ：表示在⽣成 ReadView 时当前系统中活跃的读写事务中最⼩的事务id ，也就是m_ids中的最⼩值。
	max_trx_id ：表示⽣成 ReadView 时系统中应该分配给下⼀个事务的id 值。
	creator_trx_id ：表示⽣成该 ReadView 的事务的事务id。
有了这个 ReadView ，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可⻅：
	如果被访问版本的 DB_TRX_ID 属性值与 ReadView 中的 creator_trx_id 值相同，意味着当前事务在访问它⾃⼰修改过的记录，所以该版本可以被当前事务访问。
	如果被访问版本的 DB_TRX_ID 属性值⼩于 ReadView 中的 min_trx_id 值，表明⽣成该版本的事务在当前事务⽣成 ReadView 前已经提交，所以该版本可以被当前事务访问。
	
	如果被访问版本的 DB_TRX_ID 属性值⼤于 ReadView 中的 max_trx_id 值，表明⽣成该版本的事务在当前事务⽣成 ReadView 后才开启，所以该版本不可以被当前事务访问。
	
	如果被访问版本的 DB_TRX_ID 属性值在 ReadView 的 min_trx_id 和 max_trx_id 之间，那就需要判断⼀下trx_id 属性值是不是在 m_ids 列表中，如果在，说明创建 ReadView 时⽣成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建 ReadView 时⽣成该版本的事务已经被提交，该版本可以被访问。
	
	如果某个版本的数据对当前事务不可⻅的话，那就顺着版本链找到下⼀个版本的数据，继续按照上边的步骤判断可⻅性，依此类推，直到版本链中的最后⼀个版本。如果最后⼀个版本也不可⻅的话，那么就意味着该条记录对该事务完全不可⻅，查询结果就不包含该记录

14、MySQL有哪些存储引擎，之间的区别，

InnoDB：InnoDB 是 MySQL 默认的事务性存储引擎。它支持事务、行级锁、崩溃恢复和外键约束等特性，适用于需要强调数据完整性和并发性能的应用。
MyISAM：MyISAM 是早期版本的默认存储引擎，但在 MySQL 5.5 版本之后，InnoDB 成为默认引擎。MyISAM 不支持事务和行级锁，但它具有较低的存储和检索开销，适用于读密集型的应用。
MEMORY：MEMORY 存储引擎将表数据存储在内存中，因此读写速度非常快。然而，由于数据存储在内存中，断电或重启会导致数据丢失，适用于需要临时存储数据或高速缓存的应用。

15、MySQL有存储引擎适用于什么样的场景

⼤多数情况下，使⽤默认的 InnoDB 就够了。如果要提供提交、回滚和恢复的事务安全（ACID 兼容）能⼒，并要求实现并发控制，InnoDB 就是⽐较靠前的选择了。
如果数据表主要⽤来插⼊和查询记录，则 MyISAM 引擎提供较⾼的处理效率。
如果只是临时存放数据，数据量不⼤，并且不需要较⾼的数据安全性，可以选择将数据保存在内存的MEMORY 引擎中，MySQL 中使⽤该引擎作为临时表，存放查询的中间结果。

16、MyISAM有什么优势

简单性和易于管理： MyISAM 存储引擎相对于 InnoDB 来说更加简单和易于管理。
高性能读取： 由于 MyISAM 不支持事务和行级锁，它在读取操作上比 InnoDB 更高效。
全文搜索功能： MyISAM 是 MySQL 中唯一支持全文索引的存储引擎。它提供了全文搜索索引和相关的函数，使得在文本数据上执行全文搜索变得更加方便和高效。
较小的存储空间占用： MyISAM 存储引擎在存储数据时占用较小的磁盘空间。
易于导入和导出数据： MyISAM 表的数据存储在独立的文件中，这使得数据的导入和导出操作更加简单和高效。

17、聚集索引和主键区别，其他引擎怎么做的

聚集索引和主键是数据库中两个不同的概念，它们在索引的作用和用途上有一些区别。

聚集索引（Clustered Index）：
- 聚集索引是一种特殊的索引结构，它确定了数据在磁盘上的物理存储顺序。对于聚集索引，数据行的物理顺序与索引的键值顺序一致。
- 每张表只能有一个聚集索引，因为它决定了数据在磁盘上的存储方式。如果表定义了聚集索引，则表的数据行将按照聚集索引的顺序进行存储。
- 聚集索引对于频繁的范围查询和排序操作非常有效，因为相关的数据行在物理上相邻存储。
主键（Primary Key）：
- 主键是用于唯一标识表中每一行数据的字段或一组字段。主键必须具有唯一性和非空性，可以用于保证数据的完整性和关系的引用。
- 主键可以是单个字段或多个字段的组合。一个表可以有多个唯一键，但只能有一个主键。
- 主键可以使用索引实现，以提高对主键列的检索效率。

不同的数据库存储引擎对于聚集索引和主键的实现方式可能有所不同：

在 InnoDB 存储引擎中，聚集索引和主键是紧密相关的。如果没有显式定义主键，则 InnoDB 存储引擎会使用一个隐藏的聚集索引作为主键。这意味着在 InnoDB 中，主键和聚集索引是一回事，主键定义了表的物理存储顺序。
在 MyISAM 存储引擎中，主键和聚集索引是分开的。MyISAM 存储引擎使用一个称为“主索引”（Primary Index）的 B+ 树结构来实现主键索引，而数据行是按照插入顺序存储的。

18、如何实现幂等性，如果请求来自于多个不同的设备呢？

幂等性是指相同的操作在多次执行中具有相同的结果，无论执行多少次，结果都是一致的。在网络应用中，实现幂等性是非常重要的，以确保在网络中出现故障、重试或并发请求时不会导致不一致的结果或重复操作。

下面是一些常见的实现幂等性的方法，即使请求来自于多个不同的设备，仍然可以保持幂等性：

唯一标识符（Unique Identifier）： 为每个请求生成一个唯一的标识符，并将其包含在请求中。在服务端接收到请求时，首先检查该标识符是否已经被处理过。如果已经处理过，直接返回之前的结果；如果没有处理过，执行相应的操作并记录处理状态。
幂等标志位（Idempotency Flag）： 在请求中添加一个幂等性标志位，用于标识请求是否是幂等的。服务端接收到请求时，根据标志位的值判断是否执行操作。如果标志位为真，表示请求是幂等的，执行操作并将标志位置为已处理；如果标志位为假，表示请求不是幂等的，直接返回之前的结果。
使用版本号（Versioning）： 在每个请求中包含一个版本号，用于标识请求的版本。服务端在处理请求时，比较版本号与当前的最新版本号。如果版本号相同，表示请求已经被处理过，直接返回之前的结果；如果版本号不同，执行操作并更新版本号。
使用令牌（Token）： 在每个请求中包含一个令牌，用于验证请求的唯一性。服务端接收到请求时，首先验证令牌的有效性。如果令牌有效，表示请求是幂等的，执行操作并将令牌设置为无效；如果令牌无效，直接返回之前的结果。

19、B树、B+树、红黑树

B树（B-Tree）：
- 特点：B树是一种平衡多路搜索树，每个节点可以包含多个键值和指向子节点的指针。具有较大的节点容量，适合在磁盘或其他外部存储介质上组织数据。B树通常用于数据库和文件系统中，以支持高效的范围查询和数据的有序存储。
- 优点：B树能够有效地减少磁盘访问次数，适用于大规模数据的存储和检索。由于具有较大的节点容量，B树具有较好的存储利用率。
- 缺点：相比于其他平衡树结构，B树的插入和删除操作稍复杂，因为需要维护树的平衡性。
B+树（B+ Tree）：
- 特点：B+树是在B树的基础上进行了一些改进的平衡多路搜索树。与B树不同，B+树的非叶子节点只包含键值，而不存储具体的数据。数据存储在叶子节点上，叶子节点通过链表连接，形成一个有序的数据链表。B+树常用于数据库中的索引结构。
- 优点：B+树的叶子节点形成有序的链表结构，有利于范围查询和顺序访问，提供了更高的查询性能。相比于B树，B+树更适合于内存和磁盘之间的数据存储。
- 缺点：B+树的插入和删除操作相对复杂，需要维护树的平衡性。
红黑树（Red-Black Tree）：
- 特点：红黑树是一种自平衡二叉搜索树，它通过一些特定的规则保持树的平衡。红黑树的每个节点都带有额外的颜色属性，可以是红色或黑色。红黑树常用于编程语言的标准库中，用于实现映射（Map）和集合（Set）等数据结构。
- 优点：红黑树的插入和删除操作相对简单，能够保持树的平衡性。红黑树的查找和插入操作的时间复杂度都是 O(log n)。
- 缺点：相比于B树和B+树，红黑树的节点数量较多，占用的存储空间相对较大。

20、为什么mysql使用B+树而非B树？（Mysql索引用的哪个数据结构？mysql用这个数据结构的好处。）

B+相⽐较 B 树，有这些优势：

它是 B Tree 的变种，B Tree 能解决的问题，它都能解决。：B Tree 解决的两⼤问题：每个节点存储更多关键字；路数更多
**扫库、扫表能⼒更强：**如果我们要对表进⾏全表扫描，只需要遍历叶⼦节点就可以了，不需要遍历整棵 B+Tree 拿到所有的数据。
**B+Tree 的磁盘读写能⼒相对于 B Tree 来说更强，IO 次数更少：**根节点和枝节点不保存数据区，所以⼀个节点可以保存更多的关键字，⼀次磁盘加载的关键字更多，IO 次数更少。
**排序能⼒更强：**因为叶⼦节点上有下⼀个数据区的指针，数据形成了链表。
**效率更加稳定：**B+Tree 永远是在叶⼦节点拿到数据，所以 IO 次数是稳定的。

21、Hash 索引和 B+ 树索引区别是什么？

B+ 树可以进⾏范围查询，Hash 索引不能。
B+ 树⽀持联合索引的最左侧原则，Hash 索引不⽀持。
B+ 树⽀持 order by 排序，Hash 索引不⽀持。
Hash 索引在等值查询上⽐ B+ 树效率更⾼。
B+ 树使⽤ like 进⾏模糊查询的时候，like 后⾯（⽐如 % 开头）的话可以起到优化的作⽤，Hash 索引根本⽆法进⾏模糊查询。

22、主从复制原理了解吗？

master 数据写⼊，更新 binlog
master 创建⼀个 dump 线程向 slave 推送 binlog
slave 连接到 master 的时候，会创建⼀个 IO 线程接收 binlog，并记录到 relay log 中继⽇志中
slave 再开启⼀个 sql 线程读取 relay log 事件并在 slave 执⾏，完成同步
slave 记录⾃⼰的 binglog

给你机会不中用

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
MYSQL

redo log就被引入来解决这个问题(宕机导致BP中的数据没有刷新磁盘，造成数据丢失)，当数据被修改时，除了修改BP中的数据，还会在redo log中记录这次操作，当事务提交时，会调用fsync接口对 redo log进行刷盘，如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复，redo log采用的是WAL(Write-ahead logging，预写式日志), 所有修改先写入日志，在更新到BP，保证了数据不会因为MySQL宕机而丢失，从而满足了持久性的要求。
复制链接

扫一扫