MySQL事务如何开启_MySQL事务处理与ACID特性实现教程-mysql教程-PHP中文网

答案：MySQL事务需显式开启，通过BEGIN或START TRANSACTION启动，COMMIT提交或ROLLBACK回滚，确保原子性、一致性、隔离性和持久性。使用InnoDB引擎支持事务，避免长事务、死锁和隔离级别误用，合理处理错误以保障数据一致性与系统性能。

mysql事务如何开启_mysql事务处理与acid特性实现教程

MySQL事务的开启并非一个独立的“开关”动作，它更多地是数据库存储引擎提供的一种能力，尤其是InnoDB这样的事务型引擎。简单来说，你在MySQL中执行

START TRANSACTION

登录后复制

或

BEGIN

登录后复制

语句，就意味着你明确告诉数据库：“嘿，我接下来要做的这些操作，请把它们当作一个不可分割的整体来处理。”然后，通过

COMMIT

登录后复制

来确认所有操作成功并永久保存，或者通过

ROLLBACK

登录后复制

来撤销所有操作，让数据库回到事务开始前的状态。核心在于，它不是一个你“开启”后就一直存在的模式，而是在你需要时显式声明并使用的操作序列。

解决方案

要使用MySQL事务，你首先需要确保你的表使用的是支持事务的存储引擎，最常见也是默认的就是InnoDB。如果你还在用MyISAM，那事务就跟你没关系了。

基本流程是这样的：

启动事务： 你可以用
```
START TRANSACTION;
```
登录后复制
或者
```
BEGIN;
```
登录后复制
来开始一个事务。在我看来，
```
BEGIN;
```
登录后复制
更简洁，但功能上两者没什么区别。
执行SQL操作： 在事务内部，你可以执行任意数量的DML（数据操作语言）语句，比如
```
INSERT
```
登录后复制
、
```
UPDATE
```
登录后复制
、
```
DELETE
```
登录后复制
。这些操作在事务提交之前，对其他会话来说是不可见的（取决于隔离级别），或者说，它们是临时的、可撤销的。
提交或回滚：
- 如果所有操作都成功，并且你希望它们永久生效，就执行
```
COMMIT;
```
  登录后复制
  。
- 如果任何一步出了问题，或者你改变了主意，想撤销所有操作，就执行
```
ROLLBACK;
```
  登录后复制
  。这会把数据库恢复到事务开始前的状态。

一个简单的例子：

假设我们要从一个账户转账到另一个账户。这通常涉及两个

UPDATE

登录后复制

操作，必须同时成功或同时失败。

-- 确保你的表是InnoDB引擎
-- CREATE TABLE accounts (
--     id INT PRIMARY KEY AUTO_INCREMENT,
--     name VARCHAR(100),
--     balance DECIMAL(10, 2)
-- ) ENGINE=InnoDB;
-- INSERT INTO accounts (name, balance) VALUES ('Alice', 1000.00), ('Bob', 500.00);

START TRANSACTION; -- 或者 BEGIN;

-- Alice给Bob转账100元
UPDATE accounts SET balance = balance - 100 WHERE name = 'Alice';

-- 模拟一个可能出错的情况，比如Bob的账户不存在，或者余额不足等
-- 这里我们假设一切顺利
UPDATE accounts SET balance = balance + 100 WHERE name = 'Bob';

-- 检查是否有错误发生，或者业务逻辑判断是否符合预期
-- 比如，如果Alice的余额不足，我们可能在这里ROLLBACK
-- SELECT @error_flag := (SELECT COUNT(*) FROM accounts WHERE name = 'Alice' AND balance < 0);
-- IF @error_flag > 0 THEN
--     ROLLBACK;
-- ELSE
--     COMMIT;
-- END IF;

-- 假设一切顺利，提交事务
COMMIT;

-- 如果中间出了问题，比如Alice余额不足，我们就会执行：
-- ROLLBACK;

登录后复制

值得一提的是，MySQL默认是开启

autocommit

登录后复制

模式的，这意味着你执行的每条SQL语句都会被当作一个独立的事务自动提交。当你使用

START TRANSACTION

登录后复制

或

BEGIN

登录后复制

时，

autocommit

登录后复制

会被临时禁用，直到你

COMMIT

登录后复制

或

ROLLBACK

登录后复制

。如果你想手动控制，也可以通过

SET autocommit = 0;

登录后复制

来全局关闭自动提交，但这样做需要你手动为每个操作序列进行

COMMIT

登录后复制

或

ROLLBACK

登录后复制

，这在日常开发中其实不太推荐，容易忘记提交导致数据不一致。

MySQL中哪些存储引擎支持事务，我该如何选择？

在我看来，这是一个在现代MySQL应用开发中几乎不再需要纠结的问题，因为答案几乎总是：InnoDB。

MySQL最初的默认存储引擎是MyISAM，它以其简单的结构和较快的读操作著称。但说实话，MyISAM最大的“硬伤”就是它不支持事务。这意味着如果你在MyISAM表上执行一系列操作，如果中间某个操作失败了，之前成功的操作也无法回滚，数据就可能处于一种不一致的、半完成的状态。这对于任何需要数据完整性和可靠性的业务场景（比如电商订单、金融交易、用户注册等）来说，简直是灾难性的。此外，MyISAM只支持表级锁定，在高并发写入场景下性能表现非常糟糕。

而InnoDB，它从一开始就被设计为支持事务的，并且完全符合ACID特性。它提供了行级锁定，这意味着在同一时间，多个用户可以更新表的不同行而不会相互阻塞，这大大提升了并发性能。在MySQL 5.5之后，InnoDB就成为了默认的存储引擎，这本身就说明了它的重要性和优越性。

我该如何选择？

99%的情况下，选择InnoDB。 如果你的应用需要数据完整性、高并发写入、崩溃恢复能力，或者任何需要事务支持的场景，InnoDB是唯一合理的选择。它能确保你的数据在面对错误和并发时依然可靠。
什么时候可能考虑其他？ 几乎没有。如果你有一个极度简单的、只读的、对数据一致性完全没有要求的“历史数据归档”表，或者一些临时性的、可以随时重建的数据，你可能会考虑MyISAM（但现在也很少有人这么做了）。甚至在这种情况下，InnoDB的性能也往往足够好，而且省去了管理不同存储引擎的复杂性。

如何查看和修改表的存储引擎？

查看：

SHOW CREATE TABLE your_table_name;
-- 或者
SELECT TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';

登录后复制

修改：
```
ALTER TABLE your_table_name ENGINE = InnoDB;
```
登录后复制
请注意，修改存储引擎是一个DDL（数据定义语言）操作，它会锁定表，并且对于大表来说可能需要较长时间。在生产环境操作前务必做好备份和测试。

理解ACID特性：MySQL事务如何确保数据的一致性与可靠性？

ACID是数据库事务的四大核心特性缩写，它就像是事务型数据库的“宪法”，定义了事务必须遵守的规则，以确保数据在任何情况下都保持可靠和一致。MySQL（特指InnoDB引擎）正是通过实现这些特性，来为我们的数据保驾护航的。

英特尔AI工具

英特尔AI与机器学习解决方案

查看详情

原子性（Atomicity）
- 概念： 事务是一个不可分割的工作单元，要么全部成功提交，要么全部失败回滚。没有“部分完成”的状态。
- MySQL如何实现： InnoDB通过Undo Log（回滚日志）来实现原子性。在事务执行过程中，对数据的任何修改都会被记录到Undo Log中。如果事务需要回滚，系统会根据Undo Log中的记录，将数据恢复到事务开始前的状态。就像你写了一封信，要么整封信都寄出去，要么就彻底撕掉，不会出现只寄了一半的情况。
一致性（Consistency）
- 概念： 事务执行前后，数据库从一个有效状态转换到另一个有效状态。这意味着事务必须遵守所有的预定义规则，比如主键约束、外键约束、唯一约束、检查约束等。
- MySQL如何实现： 这其实是应用程序和数据库共同维护的。数据库层面的约束（如
```
FOREIGN KEY
```
  登录后复制
  、
```
CHECK
```
  登录后复制
  、
```
UNIQUE
```
  登录后复制
  ）确保了数据的结构性一致。而事务本身则确保了业务逻辑上的一致性。比如，转账事务中，Alice的钱减少了，Bob的钱增加了，但总金额不变，这就是业务层面的一致性。如果Alice的钱减少了，但Bob的钱没增加，这个事务就破坏了一致性，应该回滚。InnoDB会检查这些约束，如果事务违反了任何约束，它会阻止提交并回滚。
隔离性（Isolation）
- 概念： 多个并发事务之间互不干扰，就好像它们是串行执行的一样。一个事务的中间状态对其他事务是不可见的。
- MySQL如何实现： InnoDB通过锁机制和MVCC（多版本并发控制）来实现隔离性。
  - 锁：当一个事务修改数据时，会锁定相关行，防止其他事务同时修改。
  - MVCC： 这是InnoDB实现高并发的关键。它为每个事务提供了一个数据的“快照”，即使其他事务正在修改数据，当前事务也能看到一个一致性的视图，而无需等待。这避免了读写冲突，提高了并发度。
- 隔离级别： MySQL提供了四种隔离级别（读未提交、读已提交、可重复读、串行化），每种级别在并发性和数据一致性之间做出了不同的权衡。InnoDB的默认隔离级别是
```
REPEATABLE READ
```
  登录后复制
  ，它能有效避免脏读和不可重复读，但在特定情况下可能会有幻读（虽然InnoDB通过间隙锁在一定程度上解决了幻读）。
持久性（Durability）
- 概念： 一旦事务提交，其所做的更改就是永久性的，即使系统发生故障（如断电、崩溃），这些更改也不会丢失。
- MySQL如何实现： InnoDB主要通过Redo Log（重做日志）和双写缓冲区（Doublewrite Buffer）来实现持久性。
  - Redo Log： 事务提交时，其对数据页的修改会先写入Redo Log，而不是直接写入数据文件。Redo Log是顺序写入的，速度非常快。即使数据库崩溃，重启后可以通过Redo Log来恢复那些已经提交但还没来得及写入数据文件的数据。
  - 双写缓冲区： 这是一个额外的安全机制。在将数据页写入数据文件之前，InnoDB会先将数据页写入双写缓冲区，然后再写入数据文件。这可以防止部分写失败（partial page write）的问题，确保数据页的完整性。

这些特性共同构成了事务型数据库的基石，确保了我们的数据在复杂、高并发的环境下，依然能够保持其完整性和可靠性。

在实际开发中，如何避免MySQL事务的常见陷阱和性能问题？

说实话，事务虽然强大，但用不好也容易给自己挖坑。在实际开发中，我见过不少因为事务使用不当而导致的问题，从性能下降到数据死锁，不一而足。这里我总结一些常见的陷阱和避免策略。

警惕长事务（Long-running Transactions）
- 陷阱： 事务开始后迟迟不提交，长时间持有锁资源。这会导致其他事务被阻塞，等待锁释放，从而拉低整个系统的并发性能。而且，长事务还会消耗更多的Undo Log空间，增加数据库恢复的难度和时间。
- 避免：
  - 保持事务尽可能短小。 只在真正需要原子性操作的业务逻辑范围内开启事务。一旦业务逻辑完成，立即提交或回滚。
  - 避免在事务中包含用户交互。 用户思考、输入、确认的时间是不可控的，如果把这些时间也包含在事务里，那这个事务就太长了。
  - 分批处理大量数据。 如果你需要处理大量数据，考虑将它们拆分成多个小事务来提交，而不是在一个大事务中处理所有数据。
死锁（Deadlock）
- 陷阱： 两个或多个事务互相持有对方需要的锁，形成循环等待，谁也无法继续执行。MySQL通常会检测到死锁，并选择一个事务（“牺牲者”）回滚，以解除死锁。
- 避免：
  - 保持一致的锁定顺序。 无论何时访问多个表或多行，始终以相同的顺序获取锁。例如，如果你总是先更新
```
accounts
```
    登录后复制
    表，再更新
```
orders
```
    登录后复制
    表，那么所有相关的事务都应该遵循这个顺序。
  - 缩短事务持续时间。 事务越短，持有锁的时间越短，发生死锁的概率就越低。
  - 使用索引。 确保
```
WHERE
```
    登录后复制
    子句中的条件列有索引，这样可以使InnoDB使用行级锁而不是表级锁，减少锁的范围。
  - 尝试使用
    SELECT ... FOR UPDATE
    登录后复制
    。如果你需要先读取数据再更新，使用
```
FOR UPDATE
```
    登录后复制
    可以提前锁定行，避免在更新时才发现冲突。
  - 处理死锁错误。 即使你尽力避免，死锁也可能发生。你的应用程序应该能够捕获MySQL的死锁错误（通常是错误码1213），然后重试事务。
不合适的隔离级别
- 陷阱： 选择了过低的隔离级别（如
```
READ UNCOMMITTED
```
  登录后复制
  ），可能导致脏读、不可重复读等数据不一致问题；选择了过高的隔离级别（如
```
SERIALIZABLE
```
  登录后复制
  ），则可能严重牺牲并发性能。
- 避免：
  - 理解隔离级别。 搞清楚每种隔离级别解决了什么问题，又带来了什么性能开销。
  - 默认通常是最好的起点。 InnoDB的默认隔离级别
```
REPEATABLE READ
```
    登录后复制
    在大多数业务场景下都是一个很好的平衡点。它避免了脏读和不可重复读，提供了相当高的数据一致性。
  - 根据需求调整。 如果你的应用对数据一致性要求极高，且并发量不是瓶颈，可以考虑
```
SERIALIZABLE
```
    登录后复制
    。如果只是报表统计等对实时性要求不高的场景，
```
READ COMMITTED
```
    登录后复制
    可能就足够了，它能减少锁的持有时间。但请记住，任何非默认的调整都应经过充分的测试。
```
autocommit
```
登录后复制
的误解
- 陷阱： 有些开发者可能会忘记MySQL默认是
```
autocommit=1
```
  登录后复制
  ，导致他们以为自己执行的每一条语句都在一个事务里，但实际上每条语句都是一个独立的事务并立即提交了。
- 避免：
  - 明确使用
    START TRANSACTION
    登录后复制
    或
    BEGIN
    登录后复制
    。这是最清晰、最推荐的方式。
  - 理解
    SET autocommit = 0
    登录后复制
    的含义。这种全局设置需要你为所有操作手动
```
COMMIT
```
    登录后复制
    或
```
ROLLBACK
```
    登录后复制
    ，这很容易出错。除非你有非常特殊的理由，否则不建议在会话或全局级别关闭
```
autocommit
```
    登录后复制
    。
事务中的错误处理
- 陷阱： 在事务中执行多个操作，但没有在任何一个操作失败时执行
```
ROLLBACK
```
  登录后复制
  ，导致部分操作提交，部分操作未提交，数据陷入不一致。
- 避免：
  - 始终在代码中捕获异常。 无论你用的是哪种编程语言，在执行数据库操作时，都要有完善的异常处理机制。
  - 失败即回滚。 一旦事务中的任何一个操作失败，立即执行
```
ROLLBACK
```
    登录后复制
    。
  - 示例伪代码：
```
try {
    START TRANSACTION;
    执行第一个SQL;
    执行第二个SQL;
    COMMIT;
} catch (Exception e) {
    ROLLBACK;
    记录错误;
    抛出异常;
}
```
    登录后复制