一年又一年，字节跳动 Lark（飞书） 研发团队又双叒叕开始招新生啦！

【内推码】：GTPUVBA

【内推链接】：https://job.toutiao.com/s/JRupWVj

【招生对象】：20年9月后~21年8月前 毕业的同学

【报名时间】：6.16-7.16（提前批简历投递只有一个月抓住机会哦！）

【画重点】：提前批和正式秋招不矛盾！面试成功，提前锁定Offer；若有失利，额外获得一次面试机会，正式秋招开启后还可再次投递。

点击进入我的博客

1 逻辑架构

MySQL逻辑架构图

• 最上层的服务并不是MySQL所独有的，大多数基于网络的客户端/服务器的工具都有类似的架构。比如连接处理、授权认证、安全等等。

• 第二层架构是MySQL比较有意思的部分。大多数MySQL的核心服务功能都在这一层，包括查询解析、分析、优化、缓存以及所有内置函数（例如，日期，时间，数学和加密函数），所有跨存储引擎的功能都在这一层实现：存储过程，触发器，视图等。

• 第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。

连接管理

每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程。

2 锁

读写锁

读锁：读锁是共享的（共享锁），多个线程在同一时刻可以同时读取一个资源；
写锁：写锁是排他的（排他锁），一个写锁会阻碍其他线程的读和写。

锁策略

一方面，锁力度越精细并发能力越强，尽量只锁定需要修改的部分数据，而不是全部的资源；
另一方面，锁的各种操作（获得锁、检查锁、释放锁等）都会增加系统开销，影响系统性能。
锁策略就是在锁的开销和数据的安全性之间寻求一定的平衡，达到最高的并发能力。

表锁

表锁是MySQL最基本的锁策略，也是开销最小的策略，它会锁定整张表。
写锁比读锁有更高的优先级，一个写锁请求可能会被插入到读锁队列的前面。

行级锁

行级锁可以最大程度的支持并发处理，同时开销也是最大的。
InnoDB以及其他存储引擎实现了行级锁。
行级锁只在存储引擎层实现，而MySQL服务器层完全不了解存储引擎中的锁实现。

3 事务

事务就是一组原子性的SQL查询，事务内的语句要么全部执行成功，要么全部执行失败。
可以使用START TRANSACTION开始一个事务，然后要么使用COMMIT提交事务，要么使用ROLLBACK撤销所有修改。

3.1 ACID原则

• 原子性(atomicity)：一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚。
• 一致性(consistency)：数据库总是从一个一致性的状态转换到另外一个一致性的状态。
• 隔离性(isolation)：一个事务所做的修改在最终提交以前，对其他事务是不可见的。
• 持久性(durability)：一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。持久性是个有点模糊的概念，因为实际上持久性也分很多不同的级别。而且不可能有能做到100%的持久性保证的策略（如果数据库本身就能做到真正的持久性，那么备份又怎么能增加持久性呢?)。

3.2 隔离级别

• READ UNCOMMITTED（未提交读）：在该级别，事务中的修改即使没有提交，对其他事务也都是可见的。READ UNCOMMITTED会引起脏读。这个级别会导致很多问题，从性能上来说，READ UNCOMTED不会比其他的级别好太多，但却缺乏其他级别的很多好处。除非真的有非常必要的理由，在实际应用中一般很少使用。
• READ COMMITTED（提交读）：大多数数据库系统的默认隔离级别都是 READ COMMITTED（但 MySQL不是）。READ COMMITTED满足前面提到的隔离性的简单定义——一个事务开始时，只能“看见”已经提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。
• REPEATABLE READ（可重复读）：REPEATABLE READ解决了脏读的问题。该级别保证了在同一个事务中多次读取同样记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读（Phantom Read）的问题。InnoDB和XtraDB存储引擎通过多版本并发控制解决了幻读的问题。可重复读是 MySQL的默认事务隔离级别。
• SERIALIZABLE（串行化）：SERIALIZABLE是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说, SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别。

隔离级别

设置隔离级别

可以通过SET TRANSACTION ISOLATION LEVEL命令来设置隔离级别。新的隔离级别会在下一个事务开始的时候生效。可以在配置文件中设置整个数据库的隔离级别，也可以只改变当前会话的隔离级别：SET TRANSACTION ISOLATION LEVEL READ COMMITTED;。MySQL能够识别所有的4个ANSI隔离级别, InnoDB引擎也支持所有的隔离级别。

3.3 不可重复读与幻读

脏读

指的是事务可以读取未提交的数据。

不可重复读

在一个事务中，两次查询的结果不一致，针对的是update操作。如下所示，(1)和(2)读到的值不一样。

幻读

指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入或删除了记录，当之前的事务再次读取该范围的记录时，会产生幻行（Phantom Row），针对的是insert和delete。如下所示，(1)和(2)处读取的记录行数不一样。

3.4 死锁

• 死锁：死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时，就可能会产生死锁；多个事务同时锁定同一个资源时，也会产生死锁。
• 死锁的产生原因：有些是因为真正的数据冲突，这种情况通常很难避免；有些则完全是由于存储引擎的实现方式导致的。
• 打破死锁：死锁发生以后，只有部分或者完全回滚其中一个事务，才能打破死锁。
• 死锁解决思路：为了解决这种问题，数据库系统实现了各种死锁检测和死锁超时机制。InnoDB可以检测到死锁的循环依赖,并立即返回一个错误。还有一种解决方式，就是当查询的时间达到锁等待超时的设定后放弃锁请求，这种方式通常来说不太好。
• InnoDB策略：将持有最少行级排他锁的事务进行回滚。

3.5 事务日志

• 事务日志可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。
• 事务日志采用的是追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序IO，而不像随机IO需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。
• 事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘。目前大多数存储引擎都是这样实现的，我们通常称之为预写式日志(Write- Ahead Logging)，修改数据需要写两次磁盘。
• 如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。具体的恢复方式则视存储引擎而定。

3.6 MySQL的事务

MySQL提供了两种事务型的存储引擎：InnoDB和NDB Cluster。MyISAM是非事务的。

自动提交（AUTOCOMMIT）

# 查看AUTOCOMMIT的值
SHOW VARIABLES LIKE 'AUTOCOMMIT';
# 设置AUTOCOMMIT的值，1或者ON表示启用，0或者OFF表示禁用。
SET AUTOCOMMIT = 0;

• MySQL默认采用自动提交模式，即如果不是显式地开始一个事务，则毎个査询都被当作一个事务执行提交操作。
• 当AUTOCOMMIT=0时，所有的查询都是在一个事务中，直到显式地执行COMMIT提交或者ROLLBACK回滚，该事务结束，同时又开始另一个新事务。
• 修改AUTOCOMMIT对非事务型的表，比如 MyISAM或者内存表不会有任何影响。对这类表来说，没有COMMIT或者R0 ROLLBACK的概念，也可以说是相当于一直处于AUTOCOMMIT启用的模式。
• 有一些命令在执行之前会强制执行COMMIT提交当前的活动事务。典型的例子，就是
  数据定义语言(DDL)中会导致大量数据改变的操作，比如 ALTER TABLE。

事务中混合使用存储引擎

• MySQL服务器层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，使用多种存储引擎是不可靠的。如果在事务中混合使用了事务型和非事务型的表，正常提交的情况下不会有什么问题，但如果该事务需要回滚，非事务型的表上的变更就无法撤销，这会导致数据库处于不致的状态,这种情况很难修复，事务的最终结果将无法确定。

隐式和显示锁定

• 两阶段锁定协议（two-phase locking protocol）：InnoDB采用的是两阶段锁定协议，整个事务分为两个阶段，前一个阶段为加锁，后一个阶段为解锁。在加锁阶段，事务只能加锁，也可以操作数据，但不能解锁；直到事务释放第一个锁，就进入解锁阶段，此过程中事务只能解锁，也可以操作数据，不能再加锁。两阶段锁协议使得事务具有较高的并发度，因为解锁不必发生在事务结尾。它的不足是没有解决死锁的问题，因为它在加锁阶段没有顺序要求。
• 隐式锁定：InnoDB会根据隔离级别在需要的时候自动加锁。
• 显示锁定：在事务执行过程中，随时都可以执行锁，锁只有在执行C0MMT或者ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放**。

LOCK TABLES和UNLOCK TABLES

MySQL也支持LOCK TABLES和UNLOCK TABLES语句，这是在服务器层实现的，和存储引擎无关。它们有自己的用途，但并不能替代事务处理。如果应用需要用到事务，还是应该选择事务型存储引擎。

LOCK TABLES和事务之间相互影响的话，情况会变得非常复杂。因此除了事务中禁用了AUTOCOMMIT，可以使用LOCK TABLES之外,其他任何时候都不要显式地执行LOCK TABLES，不管使用的是什么存储引擎。

4 多版本并发控制

什么是多版本并发控制

• MVCC（Multi-Version Concurrency Control）多版本并发控制，是一种并发控制的方法，可以认为MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低。
• 当一个 MVCC 数据库需要更新一条数据记录的时候，它不会直接用新数据覆盖旧数据，而是将旧数据标记为过时（obsolete）并在别处增加新版本的数据。这样就会有存储多个版本的数据，但是只有一个是最新的。这种方式允许读者读取在他读之前已经存在的数据，即使这些在读的过程中半路被别人修改、删除了，也对先前正在读的用户没有影响。
• 简单的说，MVCC就是用同一份数据临时保留多版本的方式，实现并发控制。
• 很多数据库都用其独特的实现机制，但大都实现了非阻塞的读操作，写操作也只锁定必要的行。

InnoDB的MVCC

• InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。一列保存了行的创建时间，另一列保存行的过期时间（不是实际的时间值，而是系统版本号），每开始一个新的事务,系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。
• MVCC只在REPEATABLE READ和 READ COMMITTED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容。

5 InnoDB概览

• InnoDB的数据存储在表空间（tablespace）中，表空间是由 InnoDB管理的一个黑盒子，由一系列的数据文件组成。
• InnoDB采用MVCC来支持高并发，并且实现了四个标准的隔离级别，其默认级别是REPEATABLE READ（可重复读），并且通过间隙锁（next-key locking）策略防止幻读的出现。
• InnoDB表是基于聚簇索引建立的，聚簇索引对主键查询有很高的性能。不过它的二级索引（secondary index，非主键索引）中必须包含主键列。
• InnodB内部做了很多优化，包括从磁盘读取数据时采用的可预测性预读，能够自动在内存中创建hash索引以加速读操作的自适应哈希索引（adaptive hash index），以及能够加速插入操作的插入缓冲区（insert buffer）等。
• 作为事务型的存储引擎，InnodB通过一些机制和工具支持真正的热备份，如MySQL Enterprise Backup、 XtraBackup等。