MySQL事务入门

数据库事务管理是保证数据一致性和完整性的核心机制，尤其对于需要高并发处理的业务系统来说，理解其运作原理至关重要。今天，我们从一个从业者的视角，把这块内容掰开揉碎了聊聊。

事务的四大特性

简单来说，事务就是一组不可分割的SQL操作，要么全部成功，要么全部失败。这背后依赖的是ACID四大特性：原子性、一致性、隔离性、持久性。原子性强调操作要么全做，要么全不做；一致性确保数据从一种合法状态变为另一种合法状态；隔离性让并发执行的事务互不干扰；持久性则保证一旦事务提交，数据变更就永久的保存下来。

事务的使用方法

在实际操作中，事务的开启、执行和提交是有明确流程的。

首先，需要开始事务处理，启动整个事务操作流程。然后，执行常规的SQL操作，对数据库进行查询和更新。最后，根据业务逻辑，选择提交事务来确认所有更改，或者回滚事务来撤销所有操作，从而确保数据一致性与完整性。

这里有几个关键点需要特别注意。

第一，创建表时必须选用InnoDB引擎，才能支持事务处理功能。这是MySQL里最常用的支持事务的存储引擎，MyISAM等引擎是不行的。

第二，默认情况下，MySQL会自动提交事务，每执行一条SQL语句成功后，数据就立刻写入磁盘，无法通过ROLLBACK回滚。如果想把多个操作放到同一个事务里来执行，那就得用START TRANSACTION手动开启一个事务。此后所有操作都处于这个事务内，直到执行COMMIT提交更改，或者ROLLBACK撤销操作，事务才会结束。一旦事务结束，后续的SQL语句又恢复为自动提交模式。

第三，如果希望在整个会话过程中都关闭自动提交功能，转而采用手动控制事务提交，可以执行set autocommit = false;或set autocommit = 0;。设置之后，每一条SQL语句不会立即生效，必须通过显式执行commit才能真正提交更改。在执行commit或rollback之前的所有数据库操作，会被视为一个完整的事务单元，之后的操作则属于新的事务。因此，在这种模式下，每一次数据变更都必须手动调用commit确认提交，或者使用rollback进行回滚，否则更改不会持久化。

第四，与Oracle类似，DDL语句（如CREATE TABLE、ALTER TABLE等）是无法回滚的，而且部分DDL语句还会触发隐式提交，导致当前事务意外中断。因此，建议在事务中避免使用DDL语句，以防破坏事务的完整性。

数据库事务隔离等级

当多个事务并发执行时，如果它们同时访问数据库中的相同数据，并且缺乏适当的隔离措施，就可能引发各种并发问题，比如脏读、不可重复读、幻读等。这些问题的根本原因在于共享数据的线程安全问题——多个线程对同一数据的读写操作没有有效协调，最终导致数据不一致或逻辑错误。

为了解决这些问题，数据库提供了四种隔离级别：读未提交、读已提交、可重复读、序列化。隔离级别越高，数据一致性越强，但并发性能也越差。在实际开发中，MySQL默认使用可重复读隔离级别，Oracle和SQL Server默认使用读已提交。

锁

锁是实现事务隔离的核心机制，主要有两种类型：行级锁和表级锁。

行级锁定机制

InnoDB引擎在读未提交、读已提交和可重复读三种隔离级别下，都支持行级锁定机制。这意味着，锁定只作用于被操作的特定行，其他行仍然可以被并发访问，这大大提升了系统的并发处理能力。

表级锁机制

当InnoDB事务隔离级别设置为序列化时，情况就完全不同了。在这个最高级别的隔离下，读写操作都会导致整表被锁定，也就是说，一个事务中的任何操作都会锁住整个表，其他事务必须等待。这虽然保证了最高的一致性，但也彻底牺牲了并发性能，通常只在极少数对数据一致性要求极端严苛的场景下才会使用。