一句话核心总结：completion_type 就是控制「事务提交/回滚之后，MySQL 自动帮你做什么」的开关，它和 autocommit 是两个不同维度的配置。

很多同学在初学 MySQL 事务时，都会把 completion_type 和 autocommit 混为一谈，结果在实践中踩坑。本文会用“占桌子吃饭”的比喻，配合实战案例，帮你彻底分清这两个参数，并吃透 completion_type 的三个取值。

一、什么是 completion_type？

一个事务的完整生命周期是：

BEGIN / START TRANSACTION  →  执行 SQL  →  COMMIT / ROLLBACK  →  事务结束

completion_type 控制的就是「事务结束（COMMIT/ROLLBACK）的那一瞬间，MySQL 接下来做什么」。

它有三个可选值：0、1、2，下面我们用吃饭的比喻一个个解释。

二、三个值的解释（附比喻 + 代码）

我们把“事务”比作“占桌子吃饭”，事务结束就是“吃完饭结账”。

1. completion_type = 0（默认值）

行为：吃完饭，结账走人，桌子直接空了。
含义：事务提交或回滚后，彻底结束当前事务，什么都不做。

-- 假设 autocommit=1（默认自动提交）
CREATE TABLE t (name VARCHAR(20));
SET @@completion_type = 0;  -- 也可以不设，因为默认就是 0

BEGIN;                      -- 占桌子，开始事务（自动提交被临时禁用）
INSERT INTO t VALUES ('张三');  -- 吃饭（执行SQL）
COMMIT;                     -- 结账走人，事务彻底结束，桌子空了

-- 此时事务已经没了，下一条独立 SQL：
INSERT INTO t VALUES ('张三');  -- 因为 autocommit=1，这条会自动提交
SELECT * FROM t;             -- 结果：两条「张三」

特点：事务是“一次性”的，提交/回滚后立刻关闭，下次要开事务必须重新写 BEGIN。

2. completion_type = 1（链式事务 – CHAIN）

行为：吃完饭结账，服务员立刻擦好桌子、帮你把新位置占上，你可以直接接着吃。
含义：事务提交/回滚后，自动开启一个和当前隔离级别完全一样的新事务，不需要再写 BEGIN。
它相当于 COMMIT AND CHAIN，即 COMMIT 执行完，MySQL 立刻帮你执行了一次隐式 BEGIN，两个事务像链条一样无缝衔接。

SET @@completion_type = 1;      -- 开启链式事务

BEGIN;
INSERT INTO t VALUES ('张三');  -- 第一个事务
COMMIT;                         -- 结账，并触发 completion_type=1：自动开启新事务！

-- 此时新事务已经自动存在啦！下一条 SQL 会挂在里面：
INSERT INTO t VALUES ('张三');  -- 这条 SQL 在新事务里，还没有提交
-- 因为没有手动 COMMIT，所以这条记录最终不会生效
SELECT * FROM t;                 -- 结果：只有一条「张三」！

如果你想保留第二条记录，必须在新事务里再执行一次 COMMIT（或者等到连接结束时自动回滚）。这种链式特性特别适合需要连续执行多个独立事务的场景，省掉了反复写 BEGIN 的麻烦。

3. completion_type = 2（提交后释放连接 – RELEASE）

行为：吃完饭结账，直接把桌子拆了，这张桌子再也用不了。
含义：事务提交后，立即断开当前客户端与 MySQL 服务器的连接。无论后面还有多少 SQL，连接都已不存在。

SET @@completion_type = 2;

BEGIN;
INSERT INTO t VALUES ('张三');
COMMIT;   -- 提交成功的同时，连接被主动断开

-- 此后如果再执行任何 SQL，会直接报错：
-- ERROR 2013 (HY000): Lost connection to MySQL server during query

特点：这个值在生产环境中极不常用，只在“提交后彻底不用当前连接”的特殊场合才会出现，并且需要客户端能妥善处理断连。

三、completion_type 与 autocommit 的区别

很多人会将二者混淆，它们的职责完全不同：

参数	控制对象	核心作用
autocommit	单条 SQL	决定一条独立的 SQL 是否自动提交。1：自动提交；0：必须手动 COMMIT
completion_type	事务结束点	决定 COMMIT/ROLLBACK 之后 MySQL 的后续动作（无动作 / 自动开事务 / 断连）

关键点：

• 显式使用 BEGIN 或 START TRANSACTION 开启事务后，自动提交会被临时禁用，直到 COMMIT/ROLLBACK 为止。
• completion_type 只对显式事务的结束（COMMIT/ROLLBACK）起作用，跟 autocommit 是 0 还是 1 无关。
• 当 completion_type = 1 时，提交后自动开启的新事务依然是显式事务，里面的 SQL 不会自动提交，必须手动 COMMIT，这也是为什么前面例子中第二条记录会丢失。

四、实战案例拆解：为什么链式事务里“张三”少了一条？

用上一节的例子来详细对比，你就会彻底明白。

初始条件：autocommit = 1，表 t 为空。

场景 A：completion_type = 0（默认）

BEGIN;
INSERT INTO t VALUES ('张三');   -- ①
COMMIT;                          -- ② 事务结束，回到 autocommit=1 的状态
INSERT INTO t VALUES ('张三');   -- ③ 独立 SQL，自动提交

最终 SELECT * FROM t 得到两条「张三」。
因为 ① 在第一个事务中提交，③ 作为独立语句自动提交，两次写入都生效了。

场景 B：completion_type = 1（链式事务）

SET @@completion_type = 1;
BEGIN;
INSERT INTO t VALUES ('张三');   -- ① 事务 T1
COMMIT;                          -- ② T1 提交，同时自动开启事务 T2
INSERT INTO t VALUES ('张三');   -- ③ 这条 SQL 在 T2 中，未提交
-- 没有执行 COMMIT，T2 被回滚（连接关闭或后续 ROLLBACK）

最终 SELECT * FROM t 只有一条「张三」。
因为 ① 已提交生效；③ 被挂在了自动开启的 T2 里，只要没有显式提交，它就不会生效。
这正好解释了为什么同样两条 INSERT，链式模式下结果少了一条。

五、延伸阅读：事务的常见分类与 completion_type 的定位

通过前面的讲解，你已经看到 completion_type=1 对应的就是 链式事务（Chained Transaction）。那么从事务理论的角度来看，数据库事务可以分为哪些类型？链式事务又处在什么位置？这一节做一个简要梳理，帮助你建立更完整的知识体系。

1. 扁平事务（Flat Transactions）

扁平事务是最简单、但在生产中使用最频繁的事务类型。所有操作都处于同一层次，由 BEGIN WORK 开始，由 COMMIT WORK 或 ROLLBACK WORK 结束，其间的操作是原子的，要么都执行，要么都回滚。扁平事务是应用程序实现原子操作的基本模块，但它的主要限制是不能提交或回滚事务的某一部分，也无法分步骤提交。

扁平事务一般有三种最终结果：① 事务成功完成，在常见应用中约占 96%；② 应用程序主动要求停止事务（如捕获异常后回滚），约占 3%；③ 外界因素强制终止事务（如连接超时或断开），约占 1%。我们平时使用的普通 BEGIN ... COMMIT，没有启用链式模式时，就是扁平事务。

2. 带有保存点的扁平事务（Flat Transactions with Savepoints）

除了支持扁平事务的操作外，还允许在事务执行过程中回滚到同一个事务中较早的一个状态。这是因为某些错误并不导致所有操作都无效，放弃整个事务代价太大。保存点（Savepoint） 用来让事务系统记住事务当前的状态，以便之后发生错误时能回滚到该保存点。对于普通的扁平事务来说，隐式地只有一个保存点，也就是事务开始的状态，因此回滚只能回到最初。

3. 链事务（Chained Transactions）

链事务可以被看作是保存点模式的一种变种。带有保存点的扁平事务在系统崩溃时，所有保存点都会消失，恢复时必须从最开始重新执行，而无法从最近的保存点继续。链事务的思想是：在提交一个事务时，释放不需要的数据对象，将必要的处理上下文隐式地传给下一个要开始的事务，前一个子事务的提交和下一个子事务的开始被合并成一个原子操作。这意味着下一个事务可以看到上一个事务的结果，就像在同一个事务中一样，同时又能在子事务提交时释放掉不再需要的数据对象，不必等到整个事务完成。

其工作方式示意如下：

事务 T1  →  提交并触发链  →  事务 T2  →  提交并触发链  →  事务 T3  →  提交

链事务与带有保存点的扁平事务有两处明显不同：

• ① 带有保存点的扁平事务能回滚到任意正确的保存点，而链事务中的回滚仅限于当前事务，即只能恢复到最近的一个保存点（当前子事务的开始处）。
• ② 锁的处理不同：链事务在执行 COMMIT 后即释放当前所持有的锁，而带有保存点的扁平事务并不影响迄今为止所持有的锁。

现在再回头看 MySQL 的 completion_type=1，你就会明白它实现的正是“链事务”模型：每次提交后自动开启一个相同隔离级别的新事务，前一个事务的锁被释放，上下文无缝传递给下一个事务，省去反复写 BEGIN 的麻烦。

4. 嵌套事务（Nested Transactions）

嵌套事务是一个层次结构框架，由一个顶层事务（Top-Level Transaction）控制着各个层次的事务。顶层事务之下嵌套的事务被称为子事务（Subtransaction），它控制着每一个局部的变换，子事务本身也可以再嵌套。因此，嵌套事务的层次结构可以看作是一棵树。MySQL 的 InnoDB 存储引擎原生不支持嵌套事务，但可以通过保存点间接模拟部分效果。

5. 分布式事务（Distributed Transactions）

分布式事务通常是在分布式环境下运行的扁平事务，需要根据数据所在位置访问网络中不同节点的数据库资源。例如，一个银行用户从招商银行的账户向工商银行的账户转账 1000 元，就需要使用分布式事务来保证跨数据库操作的原子性，不能仅调用某一家银行的数据库就完成任务。MySQL 通过 XA 协议支持分布式事务。

六、如何查看和设置 completion_type

查看当前会话值

SELECT @@session.completion_type;
-- 或
SHOW SESSION VARIABLES LIKE 'completion_type';

查看全局值

SELECT @@global.completion_type;
SHOW GLOBAL VARIABLES LIKE 'completion_type';

修改

会话级（立即生效，只对当前连接有效）：

SET SESSION completion_type = 1;   -- 开启链式事务

全局级（新建连接生效，重启后失效；永久修改需写配置文件）：

SET GLOBAL completion_type = 1;

若想让所有连接默认就采用链式事务，可以在 MySQL 配置文件（如 my.cnf）中添加：

[mysqld]
completion_type = 1

然后重启 MySQL。

七、注意事项与适用场景

1. 链式事务 (completion_type = 1) 的妙用
   当你需要连续执行一批彼此独立、且必须手动控制提交点的事务时，链式事务可以免去频繁写 BEGIN 的重复劳动，让代码更简洁。
   但要特别小心：每次 COMMIT 后已经身处一个新事务里，如果最后忘记提交，所有未提交的工作都会丢失。
2. 默认值 0 是最安全的选择
   99% 的应用场景用默认值就够了。如果你没有明确需要“提交后自动开新事务”或“提交后断连”，就不要修改它。
3. completion_type = 2 的风险
   连接被服务器端主动断开，客户端很容易未处理就抛出异常。
   通常仅在古老的批处理脚本或某些特殊的连接管理场景中使用，现代应用开发基本不会碰它。
4. 与 autocommit 的配合
   如果 autocommit=0 且 completion_type=1，那么不写 BEGIN 的 SQL 同样处于事务中；当执行 COMMIT 后，也会自动开启一个新事务，整体行为依旧保持手动提交模式。
   如果 autocommit=1 且使用了 BEGIN 显式事务，加上 completion_type=1，则会出现“提交→自动开显式事务→必须再提交”的连锁，就像上文例子一样。

八、总结

• completion_type 是事务结束时的“附加动作开关”：
  0 = 无声无息结束事务（默认）；
  1 = 自动开启一条新事务（链式）；
  2 = 提交后立即断开连接（极少用）。
• 它和 autocommit 各司其职，切勿混淆。autocommit 管单条 SQL，completion_type 管事务结束瞬间。
• 从理论分类看，链式事务是一种独立的事务模型，completion_type=1 正是 MySQL 对链事务的实现，理解其原理能帮你更好驾驭这种模式。
• 理解了这个参数，你就再也不怕看到 COMMIT AND CHAIN，也能一眼看穿“为什么少了一条数据”之类的问题。