ACID特性
- atomicity 原子性，一个事务中的所有操作要么全部成功，要么全部失败，不能只成功一部分。
- consistency 一致性，从一个一致性状态到另一个一致性状态的转换。（一致性和隔离性保证了数据的一致性）
- isolation 隔离性，一个事务在提交之前对其它事务是不可见的。
- durability 持久性，一个事务一旦被提交就会永久的保存到数据库中。
概念澄清
一个事务在进行数据变更时对另一个事务产生的可见性影响描述，表达为 脏读、幻读、不可重复读三个概念。下面具体解释下对应概念。
- 脏读：当前事务能够读取其它事务未提交的数据。
- 幻读：当前事务中在前后两次相同查询中读取的数据不一致，原因在第一次查询后第二次查询前提交了数据产生的。（侧重于插入了新的数据）
- 不可重复读：当前事务中查询相同的范围数据，同一数据的内容发生了变化。（侧重于数据的更新）
基于这三个现象描述，主要因为 MySQL 设置的隔离级别不同导致的。
InnoDB 事务隔离级别
- Read Uncommitted（读取未提交内容）
- Read Committed（读取提交内容）
- Repeatable Read（可重读）
- Serializable（可串行化）
这四种隔离级别可能产生的问题关系表：
查询 MySQL 当前事务隔离级别：
1 | SELECT @@tx_isolation; |
查询 InnoDB 的默认隔离级别是 RR，按照四种隔离级别的关系来看是会出现幻读情况，但实际上 InnoDB 引擎下的两次查询是一致的，那么它是帮我们解决幻读了吗？
解决幻读
根据维基幻读定义，当我们两次 SELECT 期间，另个一事务提交了一条插入语句正好命中查询结果，如果两次结果不一致则出现了幻读。所以可以明确的是 innoDB 帮我们在 RR 界别解决了部分幻读问题，默认情况下并没有在查询中加锁，导致另一事务可以插入数据，原来事务在做数据插入时可能出现 duplicate key error 。需要我们配合使用 SELECT … FOR UPDATE 加锁来保证不会出现幻读。InnoDB 这样做的一个原因猜测是考虑性能问题，如果每个查询都增加锁，性能上会打折扣。
参考：
https://www.cnblogs.com/likui360/p/9632641.html
https://en.wikipedia.org/wiki/Isolation_(database_systems)#Phantom_reads
