本文以MySQL数据库为例：
1、事务的四特性：
原子性(Atomicity)：就是放在一个事务中的几条SQL要么一起成功，要么一起失败(银行转账，A用户增499，B用户减499)；
一致性(Consistency)：事务在提交之前的数据与回滚之后的数据是一致的；
隔离性(Isolation)：A事务执行对B事务执行的影响情况，主要看数据库的隔离级别(根据业务来设置);
持久性(Durability)：事务一旦提交对数据的影响是持久的。
2、数据库的隔离级别
事务在并发过程中不可避免的会发生脏读、不可重复的、幻读的问题，那么就需要设置数据库的隔离级别以及给数据加锁来保证数据的安全。
RU：read uncommitted(读未提交)，A事务执行了一条insert into语句，但是还没有commit，B事务就能够select到刚刚新增的这条记录，此时如果A事务回滚，B事务相当于读到了脏的数据（还未持久化，不能使用）；
RC：read committed(读已提交)，A事务update一条SQL，已经commit进数据库，此时B事务就能读(select)到；解决脏读问题，A事务需要提交了，其他的事务(BCDE)才能读到，但是一个事务在第一次执行select查到的数据是50，第二次查到的数据只有30了，造成本次事务执行过程中，前后读到的数据不一致，主要是看业务如何走向，不影响就使用RC级别也够；Oracle数据库的默认隔离级别就是RC，如果影响就可以将隔离级别设为RR。
RR：repeatable read(可重复读)，如果业务中设计到某一时刻用电量的统计与计算，这个时候可使用RR隔离级别，因为电量时时在变，无法确定计算，A事务在第一次读的时候是3946度，第二次可能就3949............，所以设置RR隔离级别，事务只会以在第一次读取的结果为准，但是会出现幻读问题；A事务第一次读到了数据就不改变，那么B事务如果改了该数据，A事务也无法即刻知晓，明明我没有看到这条数据，但是为什么我就是添加不了这条数据呢？像是出现了幻觉一样；可以加锁来解决数据不一致的问题。
Serializable：串行化，完全遵循ACID，但是事务没有并发性，只能一个一个执行，效率低下，不太考虑；从RU->RC->RR->Serializable，事务并发性越来越严。
3、MVCC设计思想
一图胜千言
事务ABCDE.......属于并发访问的事务；事务id就是记录当前事务的编号，读的时候在某一时刻是一致的，但是涉及到增删改就会更新事务id。
4、查看MySQL锁
SHOW OPEN TABLES WHERe In_use > 0; -- 查询是否锁表 SHOW PROCESSLIST; -- 查询进程 SELECT * FROM information_schema.INNODB_LOCKS; -- 查看正在锁的事务 SELECt * FROM information_schema.INNODB_LOCK_WAITS; -- 查看正在等锁的事务
