原子性 (Atomicity):一个事务是一个不可分割的工作单元；事务中的所有操作要么全部成功执行，要么全部不执行。如果事务中的任何部分失败，则整个事务将被回滚到事务开始前的状态。
一致性 (Consistency):在事务开始和结束时，数据库都必须处于一致状态。这意味着事务的执行不会违反任何数据库约束或规则，并且会保持业务逻辑上的一致性。一旦事务完成，它应该使数据库从一个有效状态变为另一个有效状态。
隔离性 (Isolation):并发执行的多个事务之间互不干扰，如同它们是按顺序独立执行一样。这防止了脏读（读取未提交的数据）、不可重复读（在同一事务内多次读取同一数据时结果不同）和幻读（在事务中多次执行相同的查询时，由于其他已提交事务的插入或删除操作导致结果集发生变化）等现象。
持久性 (Durability):当事务成功提交后，其对数据库所做的修改将会永久保存，即使系统发生故障（如崩溃、重启等）也不会丢失这些修改。持久性通常是通过日志记录和恢复机制来保证的。

隔离级别：

事务内具有原子性，但是事务间不具有原子性，并发情况下，多事务间仍然会存在脏数据的问题。

1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据。

2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。

3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

隔离级别就是为了保证事务之间不产生脏数据。

2.锁

2.1.分类

按照对数据的操作类型分类，分为：读锁、写锁。

按照对数据操作的粒度分类，分为：行锁、表锁、

表锁：

开销小、加锁快，无死锁，锁的粒度大，发生锁冲突的概率最高，并发度最低。

读锁：

又叫共享锁，针对同一份数据，多个读操作可以同时进行而不互相影响。针对被锁表，所有客户端都可以进行读操作，所有客户端都无法进行写操作，加锁方和其他客户端的区别是，加锁方直接不允许进行写操作，而其他客户端的写操作允许进行，只是会被阻塞挂起。锁解开后，所有挂起的操作线程会去重新争抢资源。

写锁：

又叫排它锁，当前写操作没有完成前，它会阻断其他写锁和读锁。针对被锁表，加锁方可以读写，其他客户端不行。其他客户端的写操作会直接失败，读操作会被阻塞挂起，解锁以后，被挂起的线程会重新去争抢资源。

保护机制：

读锁、写锁中，加锁方都只能读当前被自己锁定的表，这是MySQL的一个保护机制，为的就是强制要求加锁方给出一个说法，到底准备锁多久，不给说法不让走。

MySQL中不同引擎支持不同级别的锁，myIsam支持表锁，innodb支持行锁。

2.2.表锁

表锁，我们当然是要基于使用表锁的存储引擎来聊，也就是基于myIsam引擎。

myIsam引擎中的读写锁是自动加的。

myIsam引擎在解锁后的阻塞队列中进行读写锁调度是写优先，这样一旦阻塞队列中大量都是写操作，那么读操作会很难得到锁，变得很慢，从而造成永久堵塞。

当然除了自动加锁，表锁可以通过指令来加锁。

查看所有锁：

show open tables

解锁：

解铃还须系铃人，只有加锁方能解锁。

unlock  tables

加读锁:

lock table 表名 read

加写锁

lock table 表名 write

2.3.行锁（MVCC）

行锁，我们当然是要基于使用行锁的存储引擎来聊，也就是基于innodb引擎。innodb和myIsam最大的不同有两点，一是支持事务，二是采用了行级锁。innodb下读写都是自动加行锁，这没有什么好说的。但是行锁因为粒度太细了，会影响效率的，innodb没有傻傻的只用了行锁，还给出了行锁的优化方案——MVCC。

MVCC，多版本并发控制，本质上就是使用行锁锁定数据。

对于锁的实现方式来说无非就两种

悲观锁：基于锁的并发控制，认为数据大概率会存在并发问题，所以进行数据更改前先给要操作的数据加上锁。程序员B开始修改数据时，给这些数据加上锁，程序员A这时再读，就发现读取不了，处于等待情况，只能等B操作完才能读数据，这保证A不会读到一个不一致的数据，但是这个会影响程序的运行效率。
乐观锁：基于版本号的并发控制，认为数据大概率不会存在并发问题，所以在进行数据操作的时候不加锁，而是在提交修改操作的时候通过版本号来确定数据有没有被第三方动过。

对于行级锁这种粒度这么细的锁，选用悲观锁性能肯定是不佳的，所以mvcc其实选用的都是乐观锁。

举个例子：

当使用mysql的innodb模式的时候，在mvcc的机制下，当事务A读取了表a的快照，在事务A提交前事务B又去读取了表a并且修改了数据，接下来事务A提交时会有什么效果，直接失败回滚事务还是？

在这种情况下：
事务A提交时，InnoDB会检查事务A对数据进行更新时的数据版本是否与事务A最初读取数据时的版本一致。如果事务B修改的数据行与事务A无关，那么事务A可以正常提交，因为它们操作的是不同的数据行。
如果事务B修改的数据行正好是事务A准备更新的那部分数据，由于事务A处于可重复读隔离级别，它看到的是先前的版本，不会看到事务B的修改。当事务A尝试提交时，InnoDB的事务处理机制会确保事务的一致性，通常有两种可能的结果：
a. 如果InnoDB检测到事务A试图更新的数据已经被事务B更新过（即版本冲突），事务A的更新操作可能会导致一个死锁错误（Deadlock），在这种情况下，InnoDB会选择回滚其中一个事务以解决死锁问题，通常会回滚较晚开始或者较晚修改数据的事务（在这里可能是事务A）。
b. 如果InnoDB的并发控制机制足够强大（例如使用Next-Key Locks来防止幻读），事务A在更新数据时就已经被阻止，也就是说事务A在尝试更新数据时就会被阻塞，直到事务B完成并释放锁，事务A才能继续，进而根据实际情况决定是成功提交还是因数据已改变而回滚。