A(原子性)：

要么全部完成，要么完全不起作用。底层实现原理：undo log（当这个事务对数据库进行修改的时候，innodb 生成对应 undo log，他会记录这个 SQL 执行的相关信息，如果 SQL 执行失败发生这个回滚，innodb 根据这个 undo log 内容去做相反的工作，比如说我执行了一个 insert 操作，那么回滚的时候，就会执行一个相反的操作，就是 delete,对应 update，回滚的时候也是执行相反的 update）

C(一致性)：

一旦事务完成（不管成功还是失败），业务处于一致的状态，而不会是部分完成，部分失败。事务执行前后，数据库的完整约束没有遭受破坏，事务执行前后都是合法的一个数据状态。

I(隔离性)：

多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。底层实现原理：写-写操作：锁（和 java 里面的锁机制是一样的）。写-读操作：MVCC（多版本并发控制，可以通过乐观锁和悲观锁实现，只在读已提交和可重复读二个隔离级别，事务的排它锁形式修改数据，修改之前把数据放到 undolog 里面，通过回滚指针关联，成功了什么都不做，失败了，从 undolog 回滚数据。）

D(持久性)：

一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响，事务的结果被写到持久化存储器中。底层实现原理：redo log（mysql 的数据是存放在这个磁盘上的，但是每次去读数据都需要通过这个磁盘 io，效率就很低，使用 innodb 提供了一个缓存 buffer,这个 buffer 中包含了磁盘部分数据页的一个映射，作为访问数据库的一个缓冲，当从这个数据库读取一个数据，就会先从这个 buffer 中获取，如果 buffer 中没有，就从这个磁盘中获取，读取完再放到这个 buffer 缓冲中，当数据库写入数据的时候，也会首先向这个 buffer 中写入数据，定期将 buffer 中的数据刷新到磁盘中，进行持久化的一个操作。如果 buffer 中的数据还没来得及同步到这个磁盘上，这个时候 MySQL 宕机了，buffer 里面的数据就会丢失，造成数据丢失的情况，持久性就无法保证了。使用 redolog 解决这个问题，当数据库的数据要进行新增或者是修改的时候，除了修改这个 buffer 中的数据，还会把这次的操作写入到这个 redolog 中，如果 msyql 宕机了，就可以通过 redolog 去恢复数据，redolog 是预写式日志（会先将所有的修改写入到日志里面，然后再更新到 buffer 里面，保证了这个数据不会丢失，保证了数据的持久性））