| 序号 | 名称 | 链接地址 |
| 1 | mysql系列(一) centos7 安装msql | https://blog.csdn.net/qq_38130094/article/details/103529535 |
| 2 | mysql系列(二)mysql简介之逻辑架构/锁粒度/事务/死锁/事务日志/MVCC | https://blog.csdn.net/qq_38130094/article/details/103549194 |
| 3 | mysql系列(三) mysql存储引擎简介 | https://blog.csdn.net/qq_38130094/article/details/103599497 |
| 4 | mysql系列(四) mysql数据库设计优化 | https://blog.csdn.net/qq_38130094/article/details/103551778 |
| 5 | mysql系列(五) mysql索引详细解析及使用 | https://blog.csdn.net/qq_38130094/article/details/103553971 |
| 6 | mysql系列(六)mysql 慢日志查询(pt-query-digest)/如何单条SQL分析和Explain及trace工具 | https://blog.csdn.net/qq_38130094/article/details/103551705 |
| 7 | mysql系列(七)mysql 主从复制和mysql查询优化 | https://blog.csdn.net/qq_38130094/article/details/103603586 |
1. mysql 逻辑架构
第一层：并不是mysql独有的的，大多数基于网络的客户端/服务器的工具或者服务都有类似的架构，比如说连接处理，授权认证，安全等，在这层上也引入了线程池的概念；
第二层：是mysql多数核心功能位置，包含查询解析，分析，优化，缓存以及所有的内置函数（日期，时间，数学和加密函数等）所有跨存储引擎的功能都在这一层实现：存储过程，触发器，视图。
第三层：包含存储引擎，存储引擎负责mysql中数据的存储和提取，服务器通过API与存储引擎进行通信，这些API屏蔽了不同存储引擎之间的差异
4.数据存储层，主要是将数据存储在运行于裸设备的文件系统之上，并完成与存储引擎的交互；
MySQL为了减少IO的预读操作，磁盘并非根据需要的数据读取，而是每次都会预读一部分数据。即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。
依据局部性原理：时间局部性、空间局部性、顺序局部性
2. 锁粒度
表锁：MyISAM和MEMORY存储引擎采用的是表级锁，InnoDB存储引擎既支持表级锁也支持行级锁（默认是行级锁），Mysql中开销最小的策略，加锁块，锁定整张表，力度大，不会出现死锁，发生锁竞争的概率最高，并发最低，性能最差；
行锁：开销大，加锁速度慢，锁定一行数据，粒度小，会出现死锁，发生锁竞争的概率最低，并发读最高，性能高；行级锁可以最大程度地支持并发处理（同时也带来了最大的锁开销）。
叶锁：BDB引擎采用的叶级锁，开销和加锁速度介于表锁和行锁之间，锁定一页的数据(一次锁定相邻的一组记录)，会出现死锁，锁竞争概率，并发性，性能均位于表锁和行锁之间。
3. mysql事务简介
事务就是一组原子性的SQL查询，或者说一个独立的工作单元。如果数据库引擎能够成功地对数据库 应用该组查询的全部语句，那么执行该组查询。如果其中有任何一条语句应为崩溃或其他原因无法执行， 那么所有的语句都不会执行。也就是说，事务内的语句，要么全部执行成功，要么全部执行失败。良好的 事务必须满足四大特性。
3.1 事务的四大特性
- 原子性(Atomicity) :一个事务中的SQL，要么全部执行，要么全部不执行；
- 一致性(Consistency) : 一个事务执行前后，数据库中的所有约束依然满足；
- 隔离性(Isolation) :一个事务执行过程中，数据不受另一个事务的影响；
- 持久性(Durability) : 一个事务执行完成后，事务对数据的修改必须持久化到数据库中
3.2 事务隔离级别
详细请见事物的隔离机制
4. mysql死锁
mysql中不同事务互相抢占对方的锁导致的死锁情况
如果刚好两个事务都执行了一条update语句，更新了一行数据，同时也锁定了该行数据。接着两 个事务都尝试去执行第二条update语句，发现该行数据已经被对方锁定，然后两个事务都等待对方释放锁， 同时又持有对方需要的锁，则陷入了死循环
注意：InnoDB目前处理死锁的方法是，将持有最少行级排它锁的事务进行回滚（这是相对比较简单的死锁回滚算法）如果行锁数量一样就会回滚提交导致死锁的事务[最后提价的事务]
mysql事务日志简介：
存储引擎在修改表的数据时，使用事务日志，使得只需要修改其内存拷贝，再把该修改行为记录到持 久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久化到磁盘。 事务日志采用追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要 在磁盘的多个地方移动磁头。事务日志持久化以后，内存中被修改的数据在后台可以慢慢的刷回到磁盘。我 们通常称为预写式日志，修改数据需要写两次磁盘。 如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据；
多版本控制器MVCC：
InnoDB是一个 多版本的存储引擎：它保留有关已更改行的旧版本的信息，以支持诸如并发和回滚之类的事务功能 。此信息存储在表空间中的数据结构中，该数据结构称为 回滚段（在Oracle中类似的数据结构之后）。InnoDB 使用回滚段中的信息来执行事务回滚中所需的撤消操作。它还使用该信息来构建行的早期版本，以实现 一致的读取。
在内部，InnoDB向数据库中存储的每一行添加三个字段。6个字节的DB_TRX_ID字段表示插入或更新该行的最后一个事务的事务标识符。同样，删除在内部被视为更新，在该更新中，行中的特殊位被设置为将其标记为已删除。每行还包含一个7字节的 DB_ROLL_PTR字段，称为滚动指针。回滚指针指向写入回滚段的撤消日志记录。如果行已更新，则撤消日志记录将包含在更新行之前重建行内容所必需的信息。一个6字节的DB_ROW_ID字段包含一个行ID，该行ID随着插入新行而单调增加。如果 InnoDB自动生成聚集索引，该索引包含行ID值。否则，该 DB_ROW_ID列不会出现在任何索引中。
以上部分内容摘自mysql官方文档；官方文档对多版本并发进行了详尽的解释