From 56e33d7242070fa37ff6034831d71255a8bd8902 Mon Sep 17 00:00:00 2001 From: TommyMerlin <786731256@qq.com> Date: Thu, 17 Jun 2021 16:05:39 +0800 Subject: [PATCH 1/7] fix typo --- docs/database/MySQL.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/database/MySQL.md b/docs/database/MySQL.md index afac2396..36bd8f6c 100644 --- a/docs/database/MySQL.md +++ b/docs/database/MySQL.md @@ -4,7 +4,7 @@ 顾名思义，关系型数据库就是一种建立在关系模型的基础上的数据库。关系模型表明了数据库中所存储的数据之间的联系（一对一、一对多、多对多）。 -关系型数据库中，我们的数据都被存放在了各种表中（比如用户表），表中的每一列就存放着一条数据（比如一个用户的信息）。 +关系型数据库中，我们的数据都被存放在了各种表中（比如用户表），表中的每一行就存放着一条数据（比如一个用户的信息）。 ![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/5e3c1a71724a38245aa43b02_99bf70d46cc247be878de9d3a88f0c44.png) @@ -34,7 +34,7 @@ mysql> show engines; ![查看MySQL提供的所有存储引擎](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/mysql-engines.png) -从上图我们可以查看出 MySQL 当前默认的存储引擎是 InnoDB,并且在 5.7 版本所有的存储引擎中只有 InnoDB 是事务性存储引擎，也就是说只有 InnoDB 支持事务。 +从上图我们可以查看出 MySQL 当前默认的存储引擎是 InnoDB，并且在 5.7 版本所有的存储引擎中只有 InnoDB 是事务性存储引擎，也就是说只有 InnoDB 支持事务。 **查看 MySQL 当前默认的存储引擎** From 3b44d9e093a0a18f77adcdfa87b5c5d397d1aab0 Mon Sep 17 00:00:00 2001 From: TommyMerlin <786731256@qq.com> Date: Thu, 17 Jun 2021 16:05:39 +0800 Subject: [PATCH 2/7] fix typo --- docs/database/MySQL.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/database/MySQL.md b/docs/database/MySQL.md index afac2396..5edb178d 100644 --- a/docs/database/MySQL.md +++ b/docs/database/MySQL.md @@ -4,7 +4,7 @@ 顾名思义，关系型数据库就是一种建立在关系模型的基础上的数据库。关系模型表明了数据库中所存储的数据之间的联系（一对一、一对多、多对多）。 -关系型数据库中，我们的数据都被存放在了各种表中（比如用户表），表中的每一列就存放着一条数据（比如一个用户的信息）。 +关系型数据库中，我们的数据都被存放在了各种表中（比如用户表），表中的每一行就存放着一条数据（比如一个用户的信息）。 ![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/5e3c1a71724a38245aa43b02_99bf70d46cc247be878de9d3a88f0c44.png) @@ -34,7 +34,7 @@ mysql> show engines; ![查看MySQL提供的所有存储引擎](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/mysql-engines.png) -从上图我们可以查看出 MySQL 当前默认的存储引擎是 InnoDB,并且在 5.7 版本所有的存储引擎中只有 InnoDB 是事务性存储引擎，也就是说只有 InnoDB 支持事务。 +从上图我们可以查看出 MySQL 当前默认的存储引擎是 InnoDB，并且在 5.7 版本所有的存储引擎中只有 InnoDB 是事务性存储引擎，也就是说只有 InnoDB 支持事务。 **查看 MySQL 当前默认的存储引擎** @@ -227,7 +227,7 @@ MySQL InnoDB 引擎通过 **锁机制**、**MVCC** 等手段来保证事务的 - **脏读（Dirty read）:** 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。 - **丢失修改（Lost to modify）:** 指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务 1 读取某表中的数据 A=20，事务 2 也读取 A=20，事务 1 修改 A=A-1，事务 2 也修改 A=A-1，最终结果 A=19，事务 1 的修改被丢失。 -- **不可重复读（Unrepeatableread）:** 指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。 +- **不可重复读（Unrepeatable read）:** 指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。 - **幻读（Phantom read）:** 幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。 **不可重复读和幻读区别：** @@ -269,7 +269,7 @@ mysql> SELECT @@tx_isolation; 🐛 问题更正：**MySQL InnoDB 的 REPEATABLE-READ（可重读）并不保证避免幻读，需要应用使用加锁读来保证。而这个加锁度使用到的机制就是 Next-Key Locks。** -因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 **READ-COMMITTED(读取提交内容)** ，但是你要知道的是 InnoDB 存储引擎默认使用 **REPEAaTABLE-READ（可重读）** 并不会有任何性能损失。 +因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 **READ-COMMITTED(读取提交内容)** ，但是你要知道的是 InnoDB 存储引擎默认使用 **REPEATABLE-READ（可重读）** 并不会有任何性能损失。 InnoDB 存储引擎在 **分布式事务** 的情况下一般会用到 **SERIALIZABLE(可串行化)** 隔离级别。 From b26f3777cda526b48cc2337b9ec5538fe31e986b Mon Sep 17 00:00:00 2001 From: TommyMerlin <786731256@qq.com> Date: Fri, 18 Jun 2021 11:16:47 +0800 Subject: [PATCH 3/7] fix typo --- docs/database/MySQL Index.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/docs/database/MySQL Index.md b/docs/database/MySQL Index.md index ea683c15..32d88388 100644 --- a/docs/database/MySQL Index.md +++ b/docs/database/MySQL Index.md @@ -28,11 +28,9 @@ select username , age from user where username = 'Java' and age = 22 ## 选择索引和编写利用这些索引的查询的3个原则 -1. 单行访问是很慢的。特别是在机械硬盘存储中(SSD的随机I/O要快很多，不过这一点仍然成立）。如果服务器从存储中读取一个数据块只是为了获取其中一行，那么就浪费了很多工作。最好读取的块中能包含尽可能多所需要的行。使用索引可以创建位置引，用以提升效率。 +1. 单行访问是很慢的。特别是在机械硬盘存储中（SSD的随机I/O要快很多，不过这一点仍然成立）。如果服务器从存储中读取一个数据块只是为了获取其中一行，那么就浪费了很多工作。最好读取的块中能包含尽可能多所需要的行。使用索引可以创建位置引，用以提升效率。 2. 按顺序访问范围数据是很快的，这有两个原因。第一，顺序 I/O 不需要多次磁盘寻道，所以比随机I/O要快很多（特别是对机械硬盘）。第二，如果服务器能够按需要顺序读取数据，那么就不再需要额外的排序操作，并且GROUPBY查询也无须再做排序和将行按组进行聚合计算了。 -3. 索引覆盖查询是很快的。如果一个索引包含了查询需要的所有列，那么存储引擎就 - 不需要再回表查找行。这避免了大量的单行访问，而上面的第1点已经写明单行访 - 问是很慢的。 +3. 索引覆盖查询是很快的。如果一个索引包含了查询需要的所有列，那么存储引擎就不需要再回表查找行。这避免了大量的单行访问，而上面的第1点已经写明单行访问是很慢的。 ## 为什么索引能提高查询速度 @@ -58,7 +56,7 @@ MySQL的基本存储结构是页(记录都存在页里边)： 1. **定位到记录所在的页：需要遍历双向链表，找到所在的页** 2. **从所在的页内中查找相应的记录：由于不是根据主键查询，只能遍历所在页的单链表了** -很明显，在数据量很大的情况下这样查找会很慢！这样的时间复杂度为O（n）。 +很明显，在数据量很大的情况下这样查找会很慢！这样的时间复杂度为O(n)。 ### 使用索引之后 @@ -95,7 +93,7 @@ select * from user where city=xx ; // 无法命中索引 ### 注意避免冗余索引 -冗余索引指的是索引的功能相同，能够命中索引(a, b)就肯定能命中索引(a) ，那么索引(a)就是冗余索引。如（name,city ）和（name ）这两个索引就是冗余索引，能够命中前者的查询肯定是能够命中后者的 在大多数情况下，都应该尽量扩展已有的索引而不是创建新索引。 +冗余索引指的是索引的功能相同，能够命中索引(a, b)就肯定能命中索引(a) ，那么索引(a)就是冗余索引。如（name,city）和（name）这两个索引就是冗余索引，能够命中前者的查询肯定是能够命中后者。在大多数情况下，都应该尽量扩展已有的索引而不是创建新索引。 -MySQL 5.7 版本后，可以通过查询 sys 库的 `schema_redundant_indexes` 表来查看冗余索引 +MySQL 5.7 版本后，可以通过查询 sys 库的 `schema_redundant_indexes` 表来查看冗余索引。 From 8b3f852fe17a9324b30bcd0a57e33b8ea858725b Mon Sep 17 00:00:00 2001 From: TommyMerlin <786731256@qq.com> Date: Fri, 18 Jun 2021 11:16:47 +0800 Subject: [PATCH 4/7] fix typo --- docs/database/MySQL Index.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/docs/database/MySQL Index.md b/docs/database/MySQL Index.md index ea683c15..32d88388 100644 --- a/docs/database/MySQL Index.md +++ b/docs/database/MySQL Index.md @@ -28,11 +28,9 @@ select username , age from user where username = 'Java' and age = 22 ## 选择索引和编写利用这些索引的查询的3个原则 -1. 单行访问是很慢的。特别是在机械硬盘存储中(SSD的随机I/O要快很多，不过这一点仍然成立）。如果服务器从存储中读取一个数据块只是为了获取其中一行，那么就浪费了很多工作。最好读取的块中能包含尽可能多所需要的行。使用索引可以创建位置引，用以提升效率。 +1. 单行访问是很慢的。特别是在机械硬盘存储中（SSD的随机I/O要快很多，不过这一点仍然成立）。如果服务器从存储中读取一个数据块只是为了获取其中一行，那么就浪费了很多工作。最好读取的块中能包含尽可能多所需要的行。使用索引可以创建位置引，用以提升效率。 2. 按顺序访问范围数据是很快的，这有两个原因。第一，顺序 I/O 不需要多次磁盘寻道，所以比随机I/O要快很多（特别是对机械硬盘）。第二，如果服务器能够按需要顺序读取数据，那么就不再需要额外的排序操作，并且GROUPBY查询也无须再做排序和将行按组进行聚合计算了。 -3. 索引覆盖查询是很快的。如果一个索引包含了查询需要的所有列，那么存储引擎就 - 不需要再回表查找行。这避免了大量的单行访问，而上面的第1点已经写明单行访 - 问是很慢的。 +3. 索引覆盖查询是很快的。如果一个索引包含了查询需要的所有列，那么存储引擎就不需要再回表查找行。这避免了大量的单行访问，而上面的第1点已经写明单行访问是很慢的。 ## 为什么索引能提高查询速度 @@ -58,7 +56,7 @@ MySQL的基本存储结构是页(记录都存在页里边)： 1. **定位到记录所在的页：需要遍历双向链表，找到所在的页** 2. **从所在的页内中查找相应的记录：由于不是根据主键查询，只能遍历所在页的单链表了** -很明显，在数据量很大的情况下这样查找会很慢！这样的时间复杂度为O（n）。 +很明显，在数据量很大的情况下这样查找会很慢！这样的时间复杂度为O(n)。 ### 使用索引之后 @@ -95,7 +93,7 @@ select * from user where city=xx ; // 无法命中索引 ### 注意避免冗余索引 -冗余索引指的是索引的功能相同，能够命中索引(a, b)就肯定能命中索引(a) ，那么索引(a)就是冗余索引。如（name,city ）和（name ）这两个索引就是冗余索引，能够命中前者的查询肯定是能够命中后者的 在大多数情况下，都应该尽量扩展已有的索引而不是创建新索引。 +冗余索引指的是索引的功能相同，能够命中索引(a, b)就肯定能命中索引(a) ，那么索引(a)就是冗余索引。如（name,city）和（name）这两个索引就是冗余索引，能够命中前者的查询肯定是能够命中后者。在大多数情况下，都应该尽量扩展已有的索引而不是创建新索引。 -MySQL 5.7 版本后，可以通过查询 sys 库的 `schema_redundant_indexes` 表来查看冗余索引 +MySQL 5.7 版本后，可以通过查询 sys 库的 `schema_redundant_indexes` 表来查看冗余索引。 From c0bdcfaee8120d992640b8153c7c8ee578fa6ea3 Mon Sep 17 00:00:00 2001 From: TommyMerlin <786731256@qq.com> Date: Fri, 18 Jun 2021 16:48:47 +0800 Subject: [PATCH 5/7] fix typo --- docs/database/MySQL数据库索引.md | 2 +- docs/database/MySQL高性能优化规范建议.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/database/MySQL数据库索引.md b/docs/database/MySQL数据库索引.md index 31ed9a66..d797144e 100644 --- a/docs/database/MySQL数据库索引.md +++ b/docs/database/MySQL数据库索引.md @@ -8,7 +8,7 @@ **优点** ： -- 使用索引可以大大加快 数据的检索速度（大大减少的检索的数据量）, 这也是创建索引的最主要的原因。 +- 使用索引可以大大加快 数据的检索速度（大大减少检索的数据量）, 这也是创建索引的最主要的原因。 - 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。 **缺点** ： diff --git a/docs/database/MySQL高性能优化规范建议.md b/docs/database/MySQL高性能优化规范建议.md index 1e380508..240a1dd9 100644 --- a/docs/database/MySQL高性能优化规范建议.md +++ b/docs/database/MySQL高性能优化规范建议.md @@ -266,7 +266,7 @@ Innodb 是按照主键索引的顺序来组织表的 ### 7. 对于频繁的查询优先考虑使用覆盖索引 -> 覆盖索引：就是包含了所有查询字段 (where,select,ordery by,group by 包含的字段) 的索引 +> 覆盖索引：就是包含了所有查询字段 (where,select,order by,group by 包含的字段) 的索引 **覆盖索引的好处：** From eae908533efb54046c493ab0b42f635163fc01ab Mon Sep 17 00:00:00 2001 From: TommyMerlin <786731256@qq.com> Date: Fri, 18 Jun 2021 17:18:13 +0800 Subject: [PATCH 6/7] fix typo --- .../关于数据库存储时间的一点思考.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/database/关于数据库存储时间的一点思考.md b/docs/database/关于数据库存储时间的一点思考.md index ab4e62c6..8eccaff2 100644 --- a/docs/database/关于数据库存储时间的一点思考.md +++ b/docs/database/关于数据库存储时间的一点思考.md @@ -1,4 +1,4 @@ -我们平时开发中不可避免的就是要存储时间，比如我们要记录操作表中这条记录的时间、记录转账的交易时间、记录出发时间等等。你会发现这个时间这个东西与我们开发的联系还是非常紧密的，用的好与不好会给我们的业务甚至功能带来很大的影响。所以，我们有必要重新出发，好好认识一下这个东西。 +我们平时开发中不可避免的就是要存储时间，比如我们要记录操作表中这条记录的时间、记录转账的交易时间、记录出发时间等等。你会发现时间这个东西与我们开发的联系还是非常紧密的，用的好与不好会给我们的业务甚至功能带来很大的影响。所以，我们有必要重新出发，好好认识一下这个东西。 这是一篇短小精悍的文章，仔细阅读一定能学到不少东西！ @@ -9,7 +9,7 @@ 但是，这是不正确的做法，主要会有下面两个问题： 1. 字符串占用的空间更大！ -2. 字符串存储的日期比较效率比较低（逐个字符进行比对），无法用日期相关的 API 进行计算和比较。 +2. 字符串存储的日期效率比较低（逐个字符进行比对），无法用日期相关的 API 进行计算和比较。 ### 2.Datetime 和 Timestamp 之间抉择 @@ -17,7 +17,7 @@ Datetime 和 Timestamp 是 MySQL 提供的两种比较相似的保存时间的 **通常我们都会首选 Timestamp。** 下面说一下为什么这样做! -#### 2.1 DateTime 类型没有时区信息的 +#### 2.1 DateTime 类型没有时区信息 **DateTime 类型是没有时区信息的（时区无关）** ，DateTime 类型保存的时间都是当前会话所设置的时区对应的时间。这样就会有什么问题呢？当你的时区更换之后，比如你的服务器更换地址或者更换客户端连接时区设置的话，就会导致你从数据库中读出的时间错误。不要小看这个问题，很多系统就是因为这个问题闹出了很多笑话。 @@ -106,7 +106,7 @@ Timestamp 只需要使用 4 个字节的存储空间，但是 DateTime 需要耗 ![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/FhRGUVHFK0ujRPNA75f6CuOXQHTE.jpeg) -可以看出 5.6.4 之后的 MySQL 多出了一个需要 0 ～ 3 字节的小数位。Datatime 和 Timestamp 会有几种不同的存储空间占用。 +可以看出 5.6.4 之后的 MySQL 多出了一个需要 0 ～ 3 字节的小数位。DateTime 和 Timestamp 会有几种不同的存储空间占用。 为了方便，本文我们还是默认 Timestamp 只需要使用 4 个字节的存储空间，但是 DateTime 需要耗费 8 个字节的存储空间。 From 79f6bfc18d77296b2b706582dbfa6fc27b3b84d7 Mon Sep 17 00:00:00 2001 From: TommyMerlin <786731256@qq.com> Date: Fri, 18 Jun 2021 20:44:32 +0800 Subject: [PATCH 7/7] fix typo --- ...条sql语句在mysql中如何执行的.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/database/一条sql语句在mysql中如何执行的.md b/docs/database/一条sql语句在mysql中如何执行的.md index 261a0c0b..9798df73 100644 --- a/docs/database/一条sql语句在mysql中如何执行的.md +++ b/docs/database/一条sql语句在mysql中如何执行的.md @@ -20,7 +20,7 @@ 本篇文章会分析下一个 sql 语句在 MySQL 中的执行流程，包括 sql 的查询在 MySQL 内部会怎么流转，sql 语句的更新是怎么完成的。 -在分析之前我会先带着你看看 MySQL 的基础架构，知道了 MySQL 由那些组件组成已经这些组件的作用是什么，可以帮助我们理解和解决这些问题。 +在分析之前我会先带着你看看 MySQL 的基础架构，知道了 MySQL 由那些组件组成以及这些组件的作用是什么，可以帮助我们理解和解决这些问题。 ## 一 MySQL 基础架构分析 @@ -30,11 +30,11 @@ 先简单介绍一下下图涉及的一些组件的基本作用帮助大家理解这幅图，在 1.2 节中会详细介绍到这些组件的作用。 -- **连接器：** 身份认证和权限相关(登录 MySQL 的时候)。 -- **查询缓存:** 执行查询语句的时候，会先查询缓存（MySQL 8.0 版本后移除，因为这个功能不太实用）。 -- **分析器:** 没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。 -- **优化器：** 按照 MySQL 认为最优的方案去执行。 -- **执行器:** 执行语句，然后从存储引擎返回数据。 +- **连接器：**身份认证和权限相关(登录 MySQL 的时候)。 +- **查询缓存：**执行查询语句的时候，会先查询缓存（MySQL 8.0 版本后移除，因为这个功能不太实用）。 +- **分析器：** 没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。 +- **优化器：**按照 MySQL 认为最优的方案去执行。 +- **执行器：**执行语句，然后从存储引擎返回数据。 ![](https://user-gold-cdn.xitu.io/2019/3/23/169a8bc60a083849?w=950&h=1062&f=jpeg&s=38189) @@ -96,7 +96,7 @@ select * from tb_student A where A.age='18' and A.name=' 张三 '; 结合上面的说明，我们分析下这个语句的执行流程： * 先检查该语句是否有权限，如果没有权限，直接返回错误信息，如果有权限，在 MySQL8.0 版本以前，会先查询缓存，以这条 sql 语句为 key 在内存中查询是否有结果，如果有直接缓存，如果没有，执行下一步。 -* 通过分析器进行词法分析，提取 sql 语句的关键元素，比如提取上面这个语句是查询 select，提取需要查询的表名为 tb_student,需要查询所有的列，查询条件是这个表的 id='1'。然后判断这个 sql 语句是否有语法错误，比如关键词是否正确等等，如果检查没问题就执行下一步。 +* 通过分析器进行词法分析，提取 sql 语句的关键元素，比如提取上面这个语句是查询 select，提取需要查询的表名为 tb_student，需要查询所有的列，查询条件是这个表的 id='1'。然后判断这个 sql 语句是否有语法错误，比如关键词是否正确等等，如果检查没问题就执行下一步。 * 接下来就是优化器进行确定执行方案，上面的 sql 语句，可以有两种执行方案： a.先查询学生表中姓名为“张三”的学生，然后判断是否年龄是 18。 @@ -112,7 +112,7 @@ select * from tb_student A where A.age='18' and A.name=' 张三 '; ``` update tb_student A set A.age='19' where A.name=' 张三 '; ``` -我们来给张三修改下年龄，在实际数据库肯定不会设置年龄这个字段的，不然要被技术负责人打的。其实条语句也基本上会沿着上一个查询的流程走，只不过执行更新的时候肯定要记录日志啦，这就会引入日志模块了，MySQL 自带的日志模块式 **binlog（归档日志）** ，所有的存储引擎都可以使用，我们常用的 InnoDB 引擎还自带了一个日志模块 **redo log（重做日志）**，我们就以 InnoDB 模式下来探讨这个语句的执行流程。流程如下： +我们来给张三修改下年龄，在实际数据库肯定不会设置年龄这个字段的，不然要被技术负责人打的。其实这条语句也基本上会沿着上一个查询的流程走，只不过执行更新的时候肯定要记录日志啦，这就会引入日志模块了，MySQL 自带的日志模块是 **binlog（归档日志）** ，所有的存储引擎都可以使用，我们常用的 InnoDB 引擎还自带了一个日志模块 **redo log（重做日志）**，我们就以 InnoDB 模式下来探讨这个语句的执行流程。流程如下： * 先查询到张三这一条数据，如果有缓存，也是会用到缓存。 * 然后拿到查询的语句，把 age 改为 19，然后调用引擎 API 接口，写入这一行数据，InnoDB 引擎把数据保存在内存中，同时记录 redo log，此时 redo log 进入 prepare 状态，然后告诉执行器，执行完成了，随时可以提交。 @@ -121,7 +121,7 @@ update tb_student A set A.age='19' where A.name=' 张三 '; **这里肯定有同学会问，为什么要用两个日志模块，用一个日志模块不行吗?** -这是因为最开始 MySQL 并没与 InnoDB 引擎( InnoDB 引擎是其他公司以插件形式插入 MySQL 的) ，MySQL 自带的引擎是 MyISAM，但是我们知道 redo log 是 InnoDB 引擎特有的，其他存储引擎都没有，这就导致会没有 crash-safe 的能力(crash-safe 的能力即使数据库发生异常重启，之前提交的记录都不会丢失)，binlog 日志只能用来归档。 +这是因为最开始 MySQL 并没有 InnoDB 引擎（InnoDB 引擎是其他公司以插件形式插入 MySQL 的），MySQL 自带的引擎是 MyISAM，但是我们知道 redo log 是 InnoDB 引擎特有的，其他存储引擎都没有，这就导致会没有 crash-safe 的能力(crash-safe 的能力即使数据库发生异常重启，之前提交的记录都不会丢失)，binlog 日志只能用来归档。 并不是说只用一个日志模块不可以，只是 InnoDB 引擎就是通过 redo log 来支持事务的。那么，又会有同学问，我用两个日志模块，但是不要这么复杂行不行，为什么 redo log 要引入 prepare 预提交状态？这里我们用反证法来说明下为什么要这么做？ @@ -138,10 +138,10 @@ update tb_student A set A.age='19' where A.name=' 张三 '; ## 三 总结 -* MySQL 主要分为 Server 层和引擎层，Server 层主要包括连接器、查询缓存、分析器、优化器、执行器，同时还有一个日志模块（binlog），这个日志模块所有执行引擎都可以共用,redolog 只有 InnoDB 有。 +* MySQL 主要分为 Server 层和引擎层，Server 层主要包括连接器、查询缓存、分析器、优化器、执行器，同时还有一个日志模块（binlog），这个日志模块所有执行引擎都可以共用，redolog 只有 InnoDB 有。 * 引擎层是插件式的，目前主要包括，MyISAM,InnoDB,Memory 等。 -* 查询语句的执行流程如下：权限校验（如果命中缓存）---》查询缓存---》分析器---》优化器---》权限校验---》执行器---》引擎 -* 更新语句执行流程如下：分析器----》权限校验----》执行器---》引擎---redo log(prepare 状态---》binlog---》redo log(commit状态) +* 查询语句的执行流程如下：权限校验（如果命中缓存）--->查询缓存--->分析器--->优化器--->权限校验--->执行器--->引擎 +* 更新语句执行流程如下：分析器---->权限校验---->执行器--->引擎---redo log(prepare 状态)--->binlog--->redo log(commit状态) ## 四 参考