1.MySQL逻辑架构
MySQL服务器逻辑架构图
2.并发控制
①读写锁
共享锁：也叫读锁，相互不阻塞。
排他锁：也叫写锁，一个写锁会阻塞其他的写锁和读锁。
写锁比读锁有更高的优先级，写锁请求可能会被插入到读锁队列的签名，但读锁不能插入写锁的前面。
②锁粒度
锁策略：加锁也需要消耗资源，锁策略就是在锁的开销和数据的安全性之间寻求平衡，这种平衡当然也会影响性能。
大多数商业数据库系统只提供在表上施加行级锁，并以各种复杂的方式来实现。而MySQL则提供了多种选择，每种MySQL引擎都可以实现自己的锁策略和锁粒度。
两种重要的锁策略：
表锁：锁定整张表，开销最小的策略。服务器会为alter table之类的语句使用表锁，而忽略存储引擎中的锁机制。
行级锁：表中每行数据锁定，开销较大的策略。InnoDB和XtraDB以及其他一些存储引擎中实现了行级锁。行级锁只在存储引擎层实现，而MySQL服务层没有实现。服务层完全不了解存储引擎中的锁实现。
3.事务
事务的ACID：
原子性 atomicity：要么全部提交成功，要么全部失败回滚。
一致性 consistency：数据库总是从一个一致性状态转换到另一个一致性的状态。事务没有最终提交，事务中所做的修改不会保存到数据库中。
隔离性 isolation：通常来说（某些隔离级别不适用），一个事务所做的修改在最终提交以前，对其他事务是不可见的。
持久性 durability：一旦事务提交，其所做的修改就会永久保存到数据库中。实际上持久性也分不同的基本，有些持久性策略能提供非常强的安全保障，有些则未必。
实现ACID的数据库通常需要更强的CPU处理能力，更大的内存和更多的磁盘空间。用户可以根据业务是否需要事务处理，来选择合适的存储引擎。
①隔离级别
SQL标准中定义了四种隔离级别。较低级别的隔离通常可以执行更高的并发，系统的开销也更低。
未提交读 READ UNCOMMITTED：（也称为脏读）
事务中的修改，即使没有提交，对其他事务也都是可见的。这个级别会导致很多问题，性能也不会比其他的级别好太多，除非真的非常有必要，实际中很少使用。
提交读 READ COMMITTED：（也叫不可重复读）
一个事务开始时，只能看见已经提交的事务所做的修改。换句话说，一个事务从开始知道提交之前，所做的任何修改对其他事务都是不可见的。
可重复读 REPEATABLE READ：（MySQL默认事务隔离级别）
在同一个事务中，多次读取同样记录的结果是一致的。但不能解决幻读：某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录。InnoDB和XtraDB存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读问题。
可串行化 SERIALIZABLE：
最高的隔离级别。通过强制事务串行执行，避免了幻读问题。由于会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁挣用的问题。实际中很少用到这个隔离级别。
②死锁
死锁：指两个或多个事务在同一资源上互相占用，并请求锁定对方占用的资源。
多个事务试图以不同的顺序锁定资源时、或多个事务同时锁定同一个资源时，就可能会产生死锁。
例子1：
事务1：
start transaction;
update stock_price set close = 45.5 where stock_id = 4 and date = '2018-10-24'；
update stock_price set close = 19.8 where stock_id = 3 and date = '2018-10-25'；
commit;
事务2：
start transaction;
update stock_price set high= 45.5 where stock_id = 3 and date = '2018-10-25'；
update stock_price set high= 19.8 where stock_id = 4 and date = '2018-10-24'；
commit;
例子2：
用户A读一条记录，然后修改该条记录，这时候用户B修改该条记录。
这时候用户B修改该条记录
这里用户A的事务里锁的性质由共享锁企图上升到独占锁，而用户B里的独占锁由于A有共享锁存在所以必须等A释放掉共享锁，而A由于B的独占锁而无法上升到独占锁就不可能释放共享锁，于是出现了死锁。
数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖。InnoDB目前处理死锁的方法是，将持有最少行级排它锁的事务进行回滚。
锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重原因：a.因为真正的数据冲突，这种情况通常很难避免。b.完全由于存储引擎的实现方式导致的。
③事务日志
事务日志可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。
事务日志采用的是追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快的多。
事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘。目前大多数存储引擎都是这样实现的，通常称之为预写式日志，修改数据需要写两次磁盘。
如果数据修改已经记录到事务日志并持久化，但数据本身没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。具体恢复方式规则视存储引擎而定。
④MySQL中的事务
MySQL提供了两种事务型的存储引擎：InnoDB和NDB Cluster。
MySQL默认采用自动提交模式。
MySQL服务层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，使用多种存储引擎是不可靠的。
如果事务中混合使用了事务型和非事务型的表（例如InnoDB和MyISAM表），在正常提交的情况下不会有问题。但是如果该事务需要回滚，非事务型的表上的变更就无法撤销，这会导致数据库处于不一致的状态。
在非事务型的表上执行事务相关操作的时候，MySQL通常不会发出提醒，也不会报错，有时候只有回滚的时候才会发出一个警告。
InnoDB采用的是两阶段锁定协议。在事务执行过程中，随时都可以执行锁定，锁定只有在执行COMMIT或者ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放。前面描述的锁定都是隐式锁定，InnoDB会根据隔离级别在需要的时候自动加锁。
另外InnoDB也支持通过特定的语句进行显示锁定，这些语句不属于SQL规范：
SELECT ... LOCK IN SHARE MODE
SELECT ... FOR UPDATE
MySQL也支持LOCK TABLES和UNLOCK TABLES语句，这是在服务器层实现的，和存储引擎无关呢。但如果用事务型的数据库，如InnoDB，就不要使用，这会严重影响性能。
4多版本并发控制
MySQL的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制（MVCC）。可以认为MVCC是行级锁的一个变种，但是它多数情况下避免了加锁操作，一次开销更低。
MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。
InnoDB的MVCC
通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号（system version number）。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。
REPEATABLE READ隔离级别下，MVCC具体操作：
SELECT
InnoDB会根据以下两个条件检查每行记录：
a.InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或修改过的。
b.行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。
只有符合上述两个条件的记录，才能返回作为查询结果。
INSERT
InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
DELETE
InnoDB为删除的每一行保存当前系统版本号作为行删除标识。
UPDATE
InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。
保存着两个额外系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据库操作很简单，性能很好，并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作。
MVCC只在REPEATABLE READ和READ COMMITTED两个隔离级别下工作。其他两个级别都合MVCC不兼容，因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行，而SERIALIZABLE则会对所有读取的行都加锁。
网友评论