MySQL之入门必备知识总结

我的学习MySQL的总结学习笔记，参考资料都在文末给出，建议阅读

---

1、读写锁

• 互斥锁（Exclusive），简写为 X 锁，又称写锁。
• 共享锁（Shared），简写为 S 锁，又称读锁。

有如下两个规定：

• 一个事务对数据对象 A 加了 X 锁，就能够对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何锁。
• 一个事务对数据对象 A 加了 S 锁，能够对 A 进行读取操做，可是不能进行更新操做。加锁期间其它事务能对 A 加 S 锁，可是不能加 X 锁。

锁的兼容关系以下：

2、锁粒度

一种提升共享资源并发性的方式就是让锁定对象更具备选择性。

应该尽可能只锁定须要修改的那部分数据，而不是全部的资源。在给定的资源上，锁定的数据量越少，发生锁争用的可能性就越小，于是能够提升系统的并发程度。

可是加锁须要消耗资源，锁的各类操做（包括得到锁、释放锁、检查锁是否已经解除）都会增长系统开销。所以封锁粒度越小，系统开销就越大。

所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡。MySQL 中提供了两种封锁粒度：行级锁以及表级锁。

通常都是在表上施加行级锁，并以各类复杂的方式来实现，以便锁在比较多的状况下尽量地提供更好的性能。

每种MySQL存储引擎均可以实现本身的锁策略和锁粒度，因此能够根据应用场景选择不一样的方案。

表锁

锁定整张表，是MySQL中最基本的锁策略，而且是开销最小的策略。

READ_LOCAL表锁支持某些类型的并发操做。在表锁中，写锁比读锁具备更高的优先级，所以写锁能够插入到锁队列中读锁的前面，反之则不能。

MySQL服务器会为诸如ALTER_TABLE之类的语句使用表锁，而忽略存储引擎的锁机制。

行锁

最大程度地支持并发处理，同时带来了最大的锁开销。

行级锁只在存储引擎层面实现，MySQL服务器层彻底不了解存储引擎的锁实现。

3、事务

概念

事务指的是知足 ACID 特性的一组操做，事务内的语句要么所有执行成功，要么所有执行失败，能够经过 Commit 提交一个事务，也可使用 Rollback 进行回滚。

可使用START TRANSACTION显式地开启一个事务，而后使用COMMIT提交事务将修改的数据持久保留，或者使用ROOLBACK撤销全部的修改（回滚）。

MySQL 默认采用自动提交模式。也就是说，若是不显式START TRANSACTION使用语句来开始一个事务，那么每一个查询操做都会被当作一个事务并自动提交。

ACID

原子性（Atomicity）

一个事务被视为一个不可分割的最小工做单元，整个事务中的全部操做要么所有提交成功，要么所有失败回滚。

回滚能够用回滚日志（Undo Log）来实现，回滚日志记录着事务所执行的修改操做，在回滚时反向执行这些修改操做便可。

一致性（Consistency）

数据库老是从一个一致性状态转换到另外一个一致性状态。事务若是最终没有提交，那么事务的修改也不会保存到数据库中。在一致性状态下，全部事务对同一个数据的读取结果都是相同的。

隔离性（Isolation）

一个事务所作的修改在最终提交之前，对其它事务是不可见的。

持久性（durability）

一旦事务提交，则其所作的修改将会永远保存到数据库中。即便系统发生崩溃，事务执行的结果也不能丢失。持久性策略有多种级别，但不可能作到100%的持久性保证。

系统发生奔溃能够用重作日志（Redo Log）进行恢复，从而实现持久性。与回滚日志记录数据的逻辑修改不一样，重作日志记录的是数据页的物理修改。

事务的 ACID 特性概念简单，但不是很好理解，主要是由于这几个特性不是一种平级关系：

• 只有知足一致性，事务的执行结果才是正确的。
• 在无并发的状况下，事务串行执行，隔离性必定可以知足。此时只要能知足原子性，就必定能知足一致性。
• 在并发的状况下，多个事务并行执行，事务不只要知足原子性，还须要知足隔离性，才能知足一致性。
• 事务知足持久化是为了能应对系统崩溃的状况。

对于一些不须要事务的查询类应用，选择一个非事务型的存储引擎（如MyISAM），能够得到更高的性能。即便存储引擎不支持事务，也能够经过使用LOCK TABLES为应用提供保护。

4、隔离级别

未提交读（READ UNCOMMITTED)

事务中的修改即便没有提交，对其余事务也都是可见的，事务能够读取未提交的数据，叫作脏读。

未提交读的性能不会比其余级别好太多，但却缺少其余级别的不少优势，在实际应用中不多使用。

提交读（READ COMMITTED)

大多数据库系统的默认隔离级别都是提交读，但MySQL不是。也可叫作不可重复度级别，由于执行两次相同的查询，可能会获得不同的结果。

一个事务开始时，只能读取到已经被提交的修改。换句话说，一个事务所作的修改在提交以前对其它事务是不可见的。

可重复读（REPEATABLE READ)

可重复读是MySQL的默认事务隔离级别。

解决了未提交读级别中的脏读问题。该级别保证在同一个事务中屡次读取同一数据的结果是同样的。

可重复读没法解决幻读问题。所谓幻读，指的是，T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不一样。

可串行化（SERIALIZABLE)

经过强制事务串行执行，在读取的每一行数据上都加锁，解决了幻读的问题，可是可能会致使超时和锁争用问题。

产生并发不一致性问题的主要缘由是破坏了事务的隔离性，解决方法是经过并发控制来保证隔离性。并发控制能够经过封锁来实现，可是封锁操做须要用户本身控制，至关复杂。数据库管理系统提供了事务的隔离级别，让用户以一种更轻松的方式处理并发一致性问题。

5、封锁协议

1. 三级封锁协议

一级封锁协议

事务 T 要修改数据 A 时必须加 X 锁，直到 T 结束才释放锁。

能够解决丢失修改问题，由于不能同时有两个事务对同一个数据进行修改，那么事务的修改就不会被覆盖。

二级封锁协议

在一级的基础上，要求读取数据 A 时必须加 S 锁，读取完立刻释放 S 锁。

能够解决读脏数据问题，由于若是一个事务在对数据 A 进行修改，根据 1 级封锁协议，会加 X 锁，那么就不能再加 S 锁了，也就是不会读入数据。

三级封锁协议

在二级的基础上，要求读取数据 A 时必须加 S 锁，直到事务结束了才能释放 S 锁。

能够解决不可重复读的问题，由于读 A 时，其它事务不能对 A 加 X 锁，从而避免了在读的期间数据发生改变。

2. 隐式锁定与显示锁定

隐式锁定

InnoDB采用两阶段锁定协议，也叫两段锁协议。

在事务执行过程当中，随时均可以执行锁定，锁只有在执行提交或者回滚时才会同时释放。InnoDB会根据隔离级别在须要的时候自动加锁

显示锁定

* SELECT ... LOCK IN SHARE MODE
* SELECT ... FOR UPDATE

MySQL也能够在服务器层面实现 LOCK TABLES 和 UNLOCK TABLES。

3. 两段锁协议

加锁阶段

在该阶段能够进行加锁操做。在对任何数据进行读操做以前要申请并得到共享锁锁，在进行写操做以前要申请并得到排他锁。加锁不成功，则事务进入等待状态，直到加锁成功才继续执行。

解锁阶段

当事务释放了一个封锁之后，事务进入解锁阶段，在该阶段只能进行解锁操做不能再进行加锁操做。

6、多版本并发控制

多版本并发控制（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别老是读取最新的数据行，要求很低，无需使用 MVCC。可串行化隔离级别须要对全部读取的行都加锁，单纯使用 MVCC 没法实现。

实现原理

MVCC是经过保存数据在某个时间点的快照来实现的，不一样的存储引擎的MVCC实现是不一样的，典型的有乐观并发控制和悲观并发控制。

InnoDB的MVCC经过在每行记录后面保存两个隐藏的列来实现。一个列保存建立时的系统版本号，一个列保存行的过时时（删除时间）的系统版本号。

每开始一个新的事务，系统版本号都会自动递增。事务开始时刻系统的版本号会做为事务的版本号，用来和查询到的每行记录的版本号进行比较。

具体实现

SELECT

InnoDB会根据两个条件检查每行记录，只有符合如下两个条件的记录才会被做为结果返回

1. 只查找行的系统版本号小于或等于事务的系统版本号。可确保读取到的记录要么在本事务以前已存在，要么是本事务进行的修改。
2. 行的版本号要么未定义，要么大于当前事务的版本号。能够确保事务读取的行在事务开始以前未被删除。

INSERT

InnoDB为新插入的每一行保存当前系统版本号做为行版本号。

DELETE

InnoDB为删除的每一行保存当前系统版本号做为删除标识。

UPDATE

InnoDB新插入一条纪录，保存当前系统版本号为行版本号，同时保存当前系统版本号到原来的行做为行删除标识。

优缺点

使用系统版本号，在大多数状况下的读操做均可以不用加锁，使得读数据变得更简单，提供系统性能，而且保证读取到的记录符合标准。

可是每一行都须要额外使用存储空间，且须要作更多的检查以及维护。

---

参考资料

《高性能MySQL》
cyc2018
美团技术团队——InnoDB中的事务隔离级别和锁的关系