Pandaer杂货铺

​呼~~，我们从MySQL最基础的架构聊起，最后聊到了MySQL最核心的事务实现。其中可能会有一些不对的地方，如果你发现了，你可以在评论区指出，我们共同讨论！最后，我们江湖再见！

我认为有两种，一个经常被拿来举例的例子就是转账，比如用户A给用户B转账，这个业务至少需要两步，用户A的余额减去一个值，用户B的余额加上一个值，如果用户A的值成功修改后，这个时候数据库崩溃了，那么就出现了数据不一致的情况，即没有符合预期。之所以有隔离级别，其实就是。这个的加锁过程是这样的，针对写操作和读已提交一样，但是针对读操作，是不加锁的读。针对可重复读而言，在每个事务中，在执行SQL语句的时候，就会开始加锁，不过这个锁是读写锁，根据SQL语句的类型加对应的锁，比如是查询操作就加读锁，是写操作就加写锁。

我们都知道数据库是用来持久化数据的，能够在需要的时候检索出我们需要的数据，然而随着数据越来越多，从海量的数据中查找出我们需要的数据，无异于大海捞针，费时又费力。很显然不是，因为它存在一个缺陷，那就是范围查询需要遍历整个数据，而往往数据库中的数据是海量的，这不合适。我们可以利用二分查找在O(logn)的代价下找到我们需要的值，又因为有序，针对范围查询也不过是O(logn)的代价，这很优秀，但是数组也有一个致命的问题，插入和删除某个元素，需要挪移位置，这代价很大，最坏的时候能够达到O(n)。

所以当执行器调用存储引擎的写接口的时候，InnoDB只不过是记录了一条日志，即磁盘中的那一块数据发生了改变。准备工作完成之后，我们先来回顾一下Mysql的架构设计，在Server端，一条SQL的语句的执行流程是这样的，SQL语句从连接器到达解析器，解析器进行一定的语法分析与语义分析知道了这条SQL是干什么的，然后优化器进行优化处理，并知道了为了执行这条SQL，应该怎么一步一步来做，将这些步骤组合成一个执行计划，并把这个执行计划交给执行器来做，执行器将具体的需要和磁盘打交道的操作委派给了存储引擎。

上面的那张图片，展示了MySQL的全景图，总体而言，MySQL采用了C/S架构设计，客户端只负责发送指令和展示结果，大部分的功能都集中在Server端，而Server端也采用了我们都熟悉的分层架构，Server端具体被分为了两层，一个是Service层，主要负责管理客户端的连接，解析SQL，以及优化SQL，最后生成执行计划也就是完成一条SQL语句需要做哪些操作。然后这些操作的具体如何执行是由Storage层来完成的，而Storage层的设计很有意思，采用了插件式的设计，提供统一的抽象的数据存取的接口定义。