关于事务的四大特性和隔离级别，我是这样理解的

Atomicity [ˌætəˈmɪsəti] 原子性Consistency [kənˈsɪstənsi] 一致性Isolation [ˌaɪsəˈleɪʃn] 隔离性Durability [dərəˈbɪlɪti] 持久性

ACID：事务的四大特性

事务作为处理中不可分割的最小单元。
一个事务执行结果只有两种：

成功提交失败回滚

不存在执行一部分的情况，这便是事务的原子性。

数据库总是从一个一致性状态转换到另一个一致性状态。

我们可以理解，一个事务完整的执行完毕，便是从原来的一致性状态转换到另一个一致性状态。如果中间执行失败，则不会进行提交（commit），由此可以保证数据库的一致性。

一个事务所做的修改在最终提交之前，对其他事务是不可见的。

假设事务1执行SQL-1时，对数据库的某条数据的字段作了Update操作，执行完毕后，事务2的SQL-1刚好去Select这条数据，此时查询出来的结果并不是事务1的SQL-1更新完后的结果，因为事务1的SQL-1虽然执行完毕，但是并没有commit，因此执行结果对事务2并不可见，这便是事务的隔离性。

一旦事务提交，则所做的修改操作就会永久保存到数据库中。

这点就比较好理解，我们的事务执行完毕，那么数据便会持久化，无论是系统崩溃还是其他情况，数据都不会发生丢失。

每种数据库都有不同的持久性保证策略，但都不可能100%的保证持久性，因此还是做好备份！

事务的隔离性比较复杂，对应四种隔离级别（级别由低到高，性能由高到低）：

未提交读(READ UNCOMMITTED)提交读(READ COMMITTED)可重复读(REPATABLE READ)可串行化(SERIALIZABLE) 2.1. 未提交读

在该级别中，事务中的修改操作，即便没有进行commit操作，只要执行完毕，对于其他事务就是可见的。

如上文隔离性中介绍，在该级别下，事务1中的SQL-1修改操作执行完毕，事务2中的SQL-1去查询，查询的结果是修改完毕后的结果，即便此时事务1没有进行提交！

设想，假设事务2的SQL-1查询完事务1的SQL-1修改后的结果，而此时事务1执行SQL-2发生了错误，导致事务发生了回滚，事务1的SQL-1修改操作被回滚，而事务2的SQL-1使用的数据仍然是修改完的数据，这就是脏读。

该级别一般不会使用。

这个级别即使我们上文隔离性中列举的例子：一个事务只能看见已经提交的事务做的修改。

假设事务2中的两条SQL均为查询同一条数据，SQL-1发生在事务1提交之前，SQL-2发生在事务1提交之后，因为事务1的修改操作再未提交之前对于事务2是不可见的，这就导致两次查询的结果不一致，因此这个级别也被称为不可重复读。

大多数数据库的默认级别。

该级别是在提交读的基础上，保证事务之间的相对独立性，即在事务2中SQL-2的查询结果依旧是事务1修改之前的，即便事务1已经提交，这样保证了在同一事务中，多次读的结果是一致的。

但这种结果一致性是针对修改操作（修改已存在数据的字段），如果事务1的SQL-1执行的是插入或者删除操作，而事务2的查询为范围性查找，这时会发现，两次结果的行数并不一致（可以查询出来插入或者删除而引起行的变化），不一致的行被称为幻行。这便是幻读问题。

MySQL的默认隔离级别，同时MySQL的InnoDB存储引擎是已经解决幻读问题的（多版本并发控制）。

最高的隔离级别。该级别会在读取行上添加锁，强制事务串行化执行来避免出现幻读问题。

我们在MySQL中执行SQL时可以发现，我们不用显式的去进行commit操作，这是因为MySQL默认采用的是自动提交（AutoCommit）模式。在该模式下，所有的查询都被当作一个事务来进行提交。

在mysql库中执行下面SQL可以查看当前连接是否开启了自动提交

SHOW VARIABLES LIKE 'AUTOCOMMIT';

通过下面命令可以修改当前连接禁用自动提交

SET AUTOCOMMIT = 0;

但是需要注意的是，即便关闭了自动提交，有时候也会触发自动提交

非事务型表，例如使用MyISAM引擎的表（MySQL 5.5 之前的默认存储引擎），因为这类表本身就没有提交和回滚，所以无论执行什么SQL，都等同于自动提交。特殊命令。例如一些DDL，由于更改了数据表结构而引起大量的数据发生更改时会触发自动提交。但不同的版本触发自动提交的语句都不同，需要根据版本来进行确定。 3.2. 设置隔离级别

MySQL的默认隔离级别为可重复读（REPATABLE READ）

可以通过下面命令修改当前会话的事务隔离级别（整个数据库的隔离级别需要修改配置文件）

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;