finished all

docs/MySQL/22 锁机制详解.md

@@ -142,7 +142,7 @@ mysql> INSERT INTO `mylock` (`id`, `NAME`) VALUES ('1', 'a');
 
 ### 表元数据锁
 
-MDL 不需要显式使用，在访问一个表的时候会被自动加上。MDL 的作用是，保证读写的正确性
+MDL 不需要显式使用，**在访问一个表的时候会被自动加上**。MDL 的作用是，保证读写的正确性
 
 如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做变更，删了一列，那么查询线程拿到的结果跟表结构对不上，肯定是不行的
 
@@ -417,5 +417,5 @@ show engine innodb status\G;
 - 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
 - 合理设计索引，尽量缩小锁的范围
 - 尽可能减少检索条件范围，避免间隙锁
-- 尽量控制事务大小，减少锁定资源量和时间长度，涉及事务加锁的sql尽量放在事务最后执行
+- 尽量控制事务大小，减少锁定资源量和时间长度，**涉及事务加锁的sql尽量放在事务最后执行**
 - 尽可能低级别事务隔离

docs/MySQL/24 mvcc机制.md

@@ -65,7 +65,7 @@ undo日志版本链是指一行数据被多个事务依次修改过后，在每
 
 因为磁盘随机读写的性能是非常差的，所以直接更新磁盘文件是不能让数据库抗住很高并发的。
 
-Mysql这套机制看起来复杂，但它可以保证每个更新请求都是**更新内存BufferPool**，然后**顺序写日志文件**，同时还能保证各种异常情况下的数据一致性。
+Mysql这套机制看起来复杂，但它可以保证每个更新请求都是**更新内存BufferPool**，然后**顺序写日志文件**，同时还能**保证各种异常情况下的数据一致性**。
 
 更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。
 
@@ -176,7 +176,7 @@ InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view
 
 在执行事务 B 查询语句的时候，一看自己的版本号是 101，最新数据的版本号也是 101，是自己的更新，可以直接使用，所以查询得到的 k 的值是 3
 
-这里我们提到了一个概念，叫作当前读。其实，除了 update 语句外，select 语句如果加锁，也是当前读。
+这里我们提到了一个概念，叫作**当前读**。其实，除了 update 语句外，select 语句如果加锁，也是当前读。
 
 > 所以，如果把事务 A 的查询语句 `select * from t where id=1` 修改一下，加上 lock in share mode 或 for update，也都可以读到版本号是 101 的数据，返回的 k 的值是 3。下面这两个 select 语句，就是分别加了读锁（S 锁，共享锁）和写锁（X 锁，排他锁）。
 

docs/MySQL/47 Undo Log是如何回滚事务的.md

@@ -0,0 +1,26 @@
+---
+sidebarDepth: 3
+sidebar: auto
+prev:
+  text: Back To 目录
+  link: /MySQL/
+typora-root-url: ..\.vuepress\public
+---
+
+
+
+
+
+**首先，**获取事务的回滚指针或Undo Log的起始位置。
+
+从Undo Log的末尾开始逆向扫描，按照事务操作的逆序依次处理每个日志记录。
+
+**然后，**针对 INSERT 操作，执行 DELETE 操作来撤销插入的数据。对于 UPDATE 操作，使用Undo Log 中记录的旧值将数据还原到之前的状态。
+
+在回滚过程中，对于已经提交的其他事务所做的修改需要跳过，只处理属于当前回滚事务的 Undo Log 记录。
+
+按照逆序依次处理所有的日志记录，直到达到回滚指针位置或 Undo Log 的起始位置。
+
+**回滚完成后，**清除或标记已回滚的 Undo Log 记录。
+
+总体而言，事务回滚是通过执行 Undo Log 中记录的反向操作，将事务的修改操作撤销，恢复到事务开始前的状态。

docs/MySQL/48 B树与B+树.md

@@ -0,0 +1,17 @@
+---
+sidebarDepth: 3
+sidebar: auto
+prev:
+  text: Back To 目录
+  link: /MySQL/
+typora-root-url: ..\.vuepress\public
+---
+
+
+
+1. **数据存储方式：**在B树中，每个节点都包含键和对应的值，叶子节点存储了实际的数据记录；而B+树中，只有叶子节点存储了实际的数据记录，非叶子节点只包含键信息和子节点的指针。
+2. **数据检索方式：**在B树中，由于非叶子节点也存储了数据，所以查询时可以直接在非叶子节点找到对应的数据，具有更短的查询路径；而B+树的所有数据都存储在叶子节点上，只有通过叶子节点才能获取到完整的数据。
+3. **范围查询效率：**由于B+树的所有数据都存储在叶子节点上，并且**叶子节点之间使用链表连接，所以范围查询的效率较高**。而在B树中，范围查询需要通过遍历多个层级的节点，效率相对较低
+4. **适用场景：**B树适合进行随机读写操作，因为每个节点都包含了数据；而B+树适合进行范围查询和顺序访问，因为数据都存储在叶子节点上，并且叶子节点之间使用链表连接，有利于顺序遍历。
+
+**总结来说：** B树和B+树在数据存储方式、数据检索方式、范围查询效率以及适用场景方面存在区别。B树适合随机读写操作，而B+树适合范围查询和顺序访问。在实际应用中，根据不同的场景和需求选择合适的树结构可以带来更高效的数据处理和索引操作。

docs/MySQL/49 in和exist的区别.md

@@ -0,0 +1,29 @@
+---
+sidebarDepth: 3
+sidebar: auto
+prev:
+  text: Back To 目录
+  link: /MySQL/
+typora-root-url: ..\.vuepress\public
+---
+
+
+
+1. **IN关键字：**使用 IN 条件时，我们提供一个固定的值列表，然后将其与指定列的值进行比较。如果列中的值与列表中的任何一个值匹配，就会返回结果。IN 条件适合用于确定某个字段的值是否在给定的值列表中。
+
+   ```sql
+   SELECT * FROM table_name WHERE column_name IN (value1, value2, value3); 
+   # 如果 column_name 的值与 value1、value2 或 value3 中的任何一个相匹配，那么这条记录将会被返回。
+   ```
+
+2. **EXISTS关键字：**使用 EXISTS 条件时，我们需要指定一个子查询。查询的结果并不重要，而是判断子查询是否返回了至少一行结果。如果子查询返回了结果，EXISTS 条件就会被认为是满足的。EXISTS 条件适合用于判断某个条件是否至少存在于子查询的结果中。
+
+   ```sql
+   SELECT * FROM table_name WHERE EXISTS (SELECT * FROM another_table WHERE condition); 
+   # 如果子查询(SELECT * FROM another_table WHERE condition)返回了至少一行结果，那么主查询中的记录将会被返回。
+   ```
+
+## 小结
+
+- 使用 IN 条件时，比较的是指定列的值是否在给定的值列表中。
+- 使用 EXISTS 条件时，判断的是子查询是否返回了至少一行结果。