mysql-并发控制

读写锁

读锁：共享锁，
写锁：排他锁，阻止其他的读锁和写锁行为

锁粒度

在锁机制存在的情况下，提高共享资源并发性的方法是让锁定对象更准确。尽量只锁定需要修改的数据部分。理想的情况下，精确锁定会修改的数据片段。
另一方面，加锁也需要消耗资源。锁的各种操作，包括获得锁、检查锁是否已解除、释放锁等，都会增加系统开销。如果锁的操作比较频繁，系统会花大量的时间来管理锁，如不是执行数据存储，则兄台那个的性能也会受到影响。
可见，锁管理的实现对性能指标存在着相互冲突的正反影响，将锁粒度固定在某个级别，可以实现锁管理的灵活性、系统消耗两方面的综合考虑。表锁、行级锁是比较常见、重要的锁策略。

• 表锁
  用户在对表进行写操作前，需获得写锁，如果是写锁是行级锁，则会阻塞其他用户对该表的所有读写操作。
  尽管存储引擎可以管理自己的锁，MySQL本身还是会使用各种有效的表锁来实现不同的目的。例如ALTER TABLE语句的执行会触发表锁，而忽略存储引擎的锁机制。

• 行级锁

事务

一组原子性的操作。ACID概念。

• 原子性(atomicity)：最小工作单元，要么都成功，要么都失败。
• 一致性(consistency)：从一个一致性的状态转到另外一个一致性的状态，从原子性理解，事务的操作不会部分成功，部分失败，因此不会对系统数据造成不一致
• 隔离性(isolation)：通常来说，事务在最终提交前，对其他事务是不可见的。事务执行的部分对数据的变更对其他事务屏蔽。
• 持久性(durability)：一旦事务提交，所执行的修改会永久的保存到数据库中

隔离级别

SQL标准中定义了4中隔离级别，低级别的隔离可以执行更高的并发，系统的开销也更低。

• READ UNCOMMITTED（未提交读）该隔离级别下，事务中的修改，即使没有提交，对其他事务也都是可见的。因此，对于其他业务，可能会产生“脏读”（读取到部分修改的、事务未提交的数据），从而引起很多问题。同时从性能层面考虑，
• READ UNCOMMITED 和其他隔离级别也差不多，因此实际场景中一般很少使用。脏读：事务T1更新了一行记录的内容，但是并没有提交所做的修改。事务T2读取更新后的行，然后T1执行回滚操作，取消了刚才所做的修改。现在T2所读取的行就无效了
• READ COMMITTED（提交读）大多数据库的默认隔离级别，但MySQL不是。本隔离级别下，满足隔离的基本定义：事务在提交前所做的修改对其他业务不可见。该级别下，两次执行同样的查询，可能会得到不一样的结果，产生不可重复读的效果。不可重复读：事务T1读取一行记录，紧接着事务T2修改 了T1刚才读取的那一行记录。然后T1又再次读取这行记录，发现与刚才读取的结果不同。这就称为“不可重复”读，因为T1原来读取的那行记录已经发生了变化。
• REPEATABLE READ（可重复读）MySQL默认隔离级别。该隔离级别解决了不可重复读问题，但还是存在幻读。InnoDB 通过多版本并发控制（MVCC）解决幻读问题。幻读：事务T1读取一条指定的WHERE子句所返回的结果集。然后事务T2新插入 一行记录，这行记录恰好可以满足T1所使用的查询条件中的WHERE 子句的条件。然后T1又使用相同的查询再次对表进行检索，但是此时却看到了事务T2刚才插入的新行。这个新行就称为“幻像”，因为对T1来说这一行就像突然出现的一样。
  SERIALIZE（可串行化）它强制事务串行执行。该隔离级别下，会对读取的每一行数据上都加上锁。因而对锁机制的管理比较耗系统资源。

隔离级别	脏读可能性	不可重复读可能性	幻读可能性	加锁读
READ UNCOMMITTED	是	是	是	否
READ COMMITTED	否	是	是	否
REPEATABLE READ	否	否	是	否
SERIALIZE	否	否	否	是

死锁

在事务中混合使用存储引擎

MySQL服务器层不管理事务，事务是由存储引擎实现的。所以在同一个事务中，使用多个存储引擎是不可靠的。
具体为：在正常提交情况下不会有问题，但如果事务需要回滚，非事务型的表变更会无法撤销，从而导致数据库表数据不一致。

多版本并发控制

MVCC, 前面有提到。MySQL的大多数事务型存储引擎的实现都不是简单的行级锁。
MVCC 的实现，是通过保存数据在某个时间点的快照实现的。即不管需要执行多长时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。
InnoDb 的 MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号都会自动增加。