1. 先拆解"Qt 不支持事务"这句话的问题所在

有段时间我经常收到类似的咨询：某开发者接了个老项目，发现一个诡异的现象——他在 Qt 客户端里调用事务，明明写好了回滚逻辑，数据却照样被改掉了。折腾几个小时后，他得出一个结论："MySQL 明明支持事务，但 Qt 不支持。"

我第一次听到这句话时觉得有点哭笑不得。MySQL 支持事务，这没问题；但 Qt 并不是数据库，它是一个 C++ 的跨平台应用框架，Qt 的 SQL 模块只负责帮应用程序和数据库对话。说"Qt 不支持事务"，就像说"外卖平台不支持做饭"一样——平台当然不做饭，但它能把你的订单完整送进后厨，后厨做不做、怎么做，是另一回事。

MySQL 的事务主场永远在数据库服务端，而 Qt 能做的，是把"开始事务""提交事务""回滚事务"这三组请求准确地送到服务端，并接收服务端的结果。只要驱动正常、数据库引擎正常、调用方式正确，Qt 完全支持事务。反过来，凡是让我看到"Qt 事务不生效"的案例，最后几乎都能落到三个层面之一：调用姿势错、数据库引擎或隔离级别不对、驱动或连接状态有问题。这篇文章就把每个层面拆开讲清楚，顺便给出一套可以直接抄的落地写法。

1.1 Qt 不是数据库，事务的"主场"在 MySQL 服务端

先建立一个基本认知：在 Qt + MySQL 这套技术栈里，真正管理事务状态的是MySQL 服务端会话，不是 Qt 进程，也不是你的业务代码。

MySQL 的 InnoDB 存储引擎通过 redo log、undo log 和锁机制来保证事务的原子性与隔离性。当一个连接进入事务后，服务端会为这个连接上的修改记录 undo 日志，回滚时靠 undo log 把数据恢复到事务开始前的样子。这一切都发生在数据库服务端，Qt 既不存 redo log，也不管 undo log，更没有能力直接改变服务端已经落盘的数据。

Qt 扮演的角色更像一个传话筒。它通过 QSqlDatabase 和 QSqlQuery 这两组类，把 SQL 语句发送给驱动插件，驱动插件再通过 MySQL 客户端库把请求发到服务端。事务能不能生效，取决于三层是否都正常工作：

1. Qt 层的 API 是否被正确调用；
2. 驱动插件是否实现了对应的事务能力；
3. MySQL 服务端和存储引擎是否真的支持并完成了事务。

任何一个环节出问题，都可能导致你看到"事务无效"的现象。很多人只盯着第一层，一发现 transaction() 返回 false，就急着下结论说 Qt 不支持事务，这其实是把驱动层和服务端的责任也算到了 Qt 头上。

1.2 Qt 能做的只是把"开始/提交/回滚"这组请求送到服务端

从接口上看，Qt 对事务的支持非常明确。QSqlDatabase 提供了三个最核心的方法：

• QSqlDatabase::transaction()：开始一个事务；
• QSqlDatabase::commit()：提交当前事务；
• QSqlDatabase::rollback()：回滚当前事务。

这三个方法的返回值都是 bool，调用失败时可以通过QSqlDatabase::lastError()拿到具体的错误信息。只要是支持事务的驱动插件（QMYSQL、QPSQL、QSQLITE 等），这三个方法就能正常触发服务端的对应操作。

问题在于，很多开发者不信任这套高层 API，习惯用QSqlQuery::exec("BEGIN")或QSqlQuery::exec("COMMIT")这种裸 SQL 方式来控制事务。这种做法不是绝对不行，但很容易让 Qt 驱动内部的事务状态和 MySQL 服务端的真实状态脱节。关于这一点，我会在下一节展开。

换句话说：Qt 把事务的"开关"和"方向"都暴露给你了，但它不会替你做任何一步数据库操作。你按下开关，服务端执行事务；你按错开关，服务端只能按你按错的去执行。这不是 Qt 的问题，而是你的遥控器没用对。

2. "Qt 不支持事务"最常见的三个来源

既然"Qt 不支持事务"这个结论本身是靠不住的，那是哪些操作让人产生了这种错觉？我把这些年看到的案例归成三类，这三类基本覆盖了市面上九成以上的"事务不生效"问题。

2.1 交叉使用裸 SQL 和 Qt 的事务 API，把状态搞乱了

我见过最典型的错误写法是这样：

// 错误示范 QSqlQuery query(db); query.exec("BEGIN"); query.exec("UPDATE account SET balance = balance - 100 WHERE id = 1"); db.commit(); // 期望提交，但 Qt 根本不知道你执行过 BEGIN

或者反过来，先用db.transaction()开启了事务，执行完业务逻辑后，又手写了一条COMMIT：

// 错误示范 db.transaction(); QSqlQuery query(db); query.exec("UPDATE account SET balance = balance - 200 WHERE id = 1"); query.exec("COMMIT"); // Qt 侧的事务状态和 MySQL 侧已经对不上了

裸 SQL 和 Qt API 混用的后果是：MySQL 服务端的事务状态是真实现不可控的，而 Qt 驱动内部的事务状态是另一套。db.commit()被调用时，Qt 认为"我在提交我现在这个事务"，但服务端可能早就因为你的手写COMMIT结束了事务，也可能还停留在一个你完全没意识到的事务里。驱动对自动提交的恢复时机、事务计数、连接池归还的判定都会错乱。

正确做法是选定一种方式，二选一。我强烈建议用 Qt 的QSqlDatabase::transaction()/commit()/rollback()这套高层 API，因为它能保证驱动内部的状态和 MySQL 服务端的状态同步。没必要自己拿手写 SQL 去跟驱动抢活干。

2.2 transaction() 返回 false，却不继续深挖失败原因

另一个常见来源是：db.transaction()返回 false，于是开发者直接认定"Qt 不支持事务"。这个结论下得太早了。

transaction()返回 false 意味着"驱动没能成功开启事务"，但原因可能有一长串：

• 当前连接的驱动插件本身没有实现事务能力；
• 驱动插件虽然实现了事务能力，但连接没有正确打开；
• 连接处于错误状态，比如上一条查询的结果集还没释放；
• 服务器端执行 START TRANSACTION 时失败，比如权限不足；
• 正在使用的表是 MyISAM 引擎，虽然服务端接受了指令，但引擎层面根本没有事务语义。

只看返回值，不读db.lastError()，差不多等于去医院只说了句"我难受"就走，连化验单都不拿。哪怕事务开启失败，Qt 也会在错误对象里留下具体线索。我的排查习惯是，遇到transaction()返回 false 的第一件事，先把db.lastError().text()打出来看，再决定往哪个方向查。

2.3 把存储引擎、隔离级别这些数据库能力误当成 Qt 的责任

第三类来源最隐蔽。有些时候，transaction()返回 true，rollback()也返回 true，但数据该变还是变。这时候很多人慌不择路，把 Qt 骂一顿，实际上问题往往出在数据库服务端的配置上。

最典型的就是MyISAM 表。MyISAM 是 MySQL 里一种不支持事务的存储引擎，它连 undo log 都没有，自然也就谈不上回滚。即使 MySQL 服务端收到了BEGIN/ROLLBACK这些指令，MyISAM 表也会直接忽略事务语义。所以你在 Qt 里兴冲冲地调用了rollback()，MySQL 也诚实地返回成功，但数据已经被 MyISAM 表永久性地改了。

还有一种情况是隔离级别不符合预期。MySQL 默认隔离级别是 REPEATABLE READ，但如果服务端或会话层面被改成了 READ COMMITTED，某些事务内的查询行为就和默认表现不一致。Qt 没有提供"隔离级别设置"的专用 API，这不是缺陷，因为隔离级别本就属于数据库会话级配置，理应由 SQL 或服务端配置来控制。你需要做的是在启动事务之前，通过 SQL 调整隔离级别，然后用 Qt 正常开启事务。

这些都是数据库能力层面的问题。把数据库引擎的锅、隔离级别的锅都扣到 Qt 头上，自然就会得出"Qt 不支持事务"的结论。

3. Qt 事务 API 的完整链路：三层请求的真相

理解"Qt 支持事务"不能停留在 API 层面，最好能看到调用背后发生了什么。我用 QMYSQL 驱动为例，把transaction()/commit()/rollback()这条链路完整走一遍。

3.1 transaction() 在 QMYSQL 驱动里到底触发了什么

当你在 Qt 里写下db.transaction()，QSqlDatabase 首先会询问驱动插件：

bool ok = db.driver()->hasFeature(QSqlDriver::Transactions);

这一步是在确认当前驱动是否声明支持事务。QMYSQL 驱动正常编译时，对这个问题的回答是 true。如果返回 false，那说明驱动插件本身没实现事务能力，或者你的驱动是残缺版本。

接着，QSqlDatabase 会把请求透传给驱动层的beginTransaction()。在 MySQL 客户端库里，这个操作的本质是把连接的自动提交模式关掉。MySQL 默认情况下 autocommit 是开启的，意味着每一条 SQL 执行完就立即提交。事务开启后，autocommit 被关闭，后续执行的 DML 语句都会进入一个"未提交"的状态，直到 connection 上出现显式的 COMMIT 或 ROLLBACK。

注意这里的措辞：事务状态存放在服务端连接会话里。也就是说，同一个连接上开启的事务，只能由同一个连接来提交或回滚。如果你在 Qt 里开了事务，然后跑到另一个线程拿另一个连接去提交，根本提交不了，因为服务端只认事务所属的连接。

3.2 commit/rollback 之后自动提交怎么恢复

db.commit()和db.rollback()的调用路径类似，都会把指令发送到服务端，让当前连接上的挂起事务完成"提交"或"回滚"。提交之后，事务相关的结果会被最终写入数据文件；回滚之后，则依据 undo log 把数据恢复到事务开始前的状态。

这里有一个容易踩的坑：如果事务在 Qt 里是通过transaction()开启的，那提交和回滚也应该通过commit()/rollback()来完成。原因在于 Qt 驱动在开启事务时关闭了自动提交，正常情况下，提交或回滚动作本身不会自动把 autocommit 恢复到原来的值，具体恢复时机和驱动版本有关。

如果你非要在事务中间手写一条COMMIT，Qt 驱动并不知道你已经在服务端完成了提交，它内部还会保留"当前正处于事务中"的状态。之后你再调用db.commit()，就可能出现空提交、无效提交或状态错乱。解决办法我刚才已经强调过：别混用，全部交给 Qt API。

3.3 QSqlQuery 的副作用：为什么提交前必须先释放结果集

这是我自己做 Qt 事务时踩过最深的一个坑，也是排查"提交失败"时需要第一时间检查的点。

MySQL 的客户端 C API 有一个非常古老的限制：当一条语句已经返回结果集，而客户端还没有把结果集读完或释放时，同一连接上不允许再执行新的命令。直接执行，会得到一个经典的错误：

Commands out of sync; you can't run this command now

在 Qt 里，QSqlQuery对象持有数据库查询的结果集。如果你执行了一条 SELECT 并取得了结果，但既没有遍历完，也没有显式释放QSqlQuery，紧接着就调用db.commit()，这条提交命令很可能就撞上"结果集未释放"的墙壁，导致提交失败。

我见过一个实际案例，开发者在事务里跑了好几条 UPDATE，又在中间穿插了一条 SELECT，SELECT 的结果没处理完就提交。结果偶尔成功，偶尔报 out of sync，非常难复现。最终定位到的原因就是：提交前，那条 SELECT 对应的QSqlQuery没有调用finish()或析构。

正确的习惯是：任何QSqlQuery在执行完查询后，要么确保它已经走出作用域被析构，要么显式调用finish()释放结果集，再执行事务提交。代码上可以这样组织：

QSqlQuery query(db); query.exec("SELECT id, name FROM account WHERE status = 1"); while (query.next()) { // 处理查询结果 } query.finish(); // 释放结果集资源 bool ok = db.commit();

这里的finish()在 Qt 文档里的意思是"结束查询并释放数据库资源"，调用之后，这个查询对象不再占用连接，提交命令就能顺利执行。

4. 一个能落地的 Qt 事务封装：把最常见的坑挡在外面

知道了原理，接下来给一个实战封装。我自己在项目里习惯用一个 RAII 风格的小类来管理事务生命周期，好处是代码简洁、不容易忘提交或忘回滚，遇到异常时也安全。

4.1 标准事务函数：用 RAII 管理生命周期

看下面这段示例代码，它把开启、提交、回滚全部封装在一个对象里：

#include <QSqlDatabase> #include <QSqlQuery> #include <QSqlError> #include <QDebug> class TransactionGuard { public: explicit TransactionGuard(QSqlDatabase &db) : m_db(db) { if (!m_db.transaction()) { m_active = false; qCritical() << "transaction failed:" << m_db.lastError().text(); } else { m_active = true; } } ~TransactionGuard() { if (m_active) { if (!m_db.rollback()) { qWarning() << "rollback failed:" << m_db.lastError().text(); } } } bool isActive() const { return m_active; } void commit() { if (!m_active) return; if (!m_db.commit()) { qCritical() << "commit failed:" << m_db.lastError().text(); } else { m_active = false; } } private: QSqlDatabase &m_db; bool m_active = false; };

使用方式是这样的：

QSqlDatabase db = QSqlDatabase::database("main_connection"); TransactionGuard guard(db); if (!guard.isActive()) { return; } QSqlQuery q1(db); q1.prepare("UPDATE account SET balance = balance - :amount WHERE id = :id"); q1.bindValue(":amount", 100); q1.bindValue(":id", 1); if (!q1.exec()) { qCritical() << q1.lastError().text(); return; // 析构时自动回滚 } QSqlQuery q2(db); q2.prepare("UPDATE account SET balance = balance + :amount WHERE id = :id"); q2.bindValue(":amount", 100); q2.bindValue(":id", 2); if (!q2.exec()) { qCritical() << q2.lastError().text(); return; // 析构时自动回滚 } q1.finish(); q2.finish(); guard.commit();

这个封装的核心价值在于：即使业务代码中间出了异常直接 return，析构函数也会自动执行回滚，不会让未提交事务悬在那。开发时，你需要留意的只有一件事：如果你长期持有一个QSqlQuery实例，提交之前记得调用finish()，避免结果集占用连接导致 out of sync。

4.2 隐式提交的雷区：别在事务里执行 DDL

MySQL 有一个非常隐蔽、但杀伤力极大的机制叫隐式提交。在事务进行中，一旦执行了某些特定的 SQL 语句，MySQL 会强制把当前事务提交掉，这个行为不受 Qt 控制，也不受autocommit设置控制。

常见会触发隐式提交的语句包括：

• CREATE TABLE、ALTER TABLE、DROP TABLE、RENAME TABLE
• TRUNCATE TABLE
• CREATE INDEX、DROP INDEX
• CREATE DATABASE、ALTER DATABASE、DROP DATABASE
• GRANT、REVOKE、SET PASSWORD等权限管理语句

举个实际的例子：

START TRANSACTION; UPDATE account SET balance = balance - 100 WHERE id = 1; ALTER TABLE account ADD COLUMN remark VARCHAR(255); -- 这里触发了隐式提交 ROLLBACK;

这段 SQL 看起来像是"先改数据，再改表结构，最后回滚"，但实际效果是：UPDATE这条语句在ALTER TABLE被执行时就已经被永久提交了，最后那句ROLLBACK什么都救不回来。

你可能会想：我用的不是裸 SQL，是 Qt 的transaction()，会不会就没事？不会。隐式提交是 MySQL 服务端的规则，和客户端用什么框架没有任何关系。无论你用裸 SQL 还是 Qt API，只要在事务中间执行了 DDL，前面的 DML 就会被隐式提交掉。

所以，事务里最好不要夹带任何 DDL 操作。表结构变更、索引调整这类动作，应该放到事务之外单独执行。如果你确实需要"事务 + DDL"的组合，那不要用 MySQL 这种隐式提交模型，换 PostgreSQL 这类支持事务性 DDL 的数据库，或者重新设计流程。

4.3 多线程与连接池场景的提交纪律

多线程是另一个容易让事务"看起来失效"的重灾区。

Qt 的数据库连接默认不允许在线程间乱用。一个连接在哪个线程创建，就应该主要在那个线程中使用。如果在一个线程里开启事务，再把这个 QSqlDatabase 传给另一个线程去提交，轻则报驱动错误，重则连接状态崩溃。多线程场景下的事务纪律是：每个线程维护自己的数据库连接。事务的开启、提交、回滚，必须发生在同一个连接、同一个线程上。

连接池场景也要特别注意。很多连接池在连接被归还时不会自动回滚未完成的事务。假设线程 A 从连接池取走一个连接，开启事务后处理到一半崩溃了，连接被归还时事务还挂着。线程 B 再从池里取同一个连接时，做的第一条写入操作可能就落在了一个"未提交事务"的真空中。更严重的，线程 B 的操作会长时间持有锁，拖慢整个数据库。

我的做法是在连接归还前强制终结事务。连接池实现层面，最好在releaseConnection()或等价方法里检查一次，如果当前连接仍然处于事务中，就执行rollback()再归还。别指望业务代码每次都能记着收尾。

5. 遇到"事务像没生效"时的排查顺序表

最后，把我这几年排查这类问题的经验浓缩成一张实战清单。如果你现在正被"Qt 事务不生效"困扰，按顺序查这几项，大概率能定位到根因。

5.1 从现象到根因的快速判断

先根据你观察到的现象，定位排查方向：

这张表覆盖了我遇到的大部分场景。每次排查，我都建议从最底层的"引擎和连接状态"开始看，因为这两项是数据库事务生效的基础。

5.2 通过 SQL 验证存储引擎和隔离级别

在 Qt 里也可以直接执行 SQL 来验证环境。用 QSqlQuery 跑一句：

SHOW CREATE TABLE account;

重点看输出里的ENGINE=InnoDB。如果是ENGINE=MyISAM，那你真的不用再找 Qt 的问题了——MyISAM 不支持事务，回滚无效是必然的。

再看隔离级别和自动提交状态：

SELECT @@transaction_isolation; SELECT @@autocommit;

如果@@autocommit是 1，说明这个会话默认自动提交；这种情况下，Qt 的transaction()会负责把自动提交关掉。如果@@autocommit是 0，那意味着你在这个连接上的每一个 SQL 都处在事务中，直到显式提交或回滚。有些程序员在命令行客户端里执行过SET autocommit=0，然后换到 Qt 程序里用同一个连接池，会发现所有操作都"莫名进事务"，这也是一个隐藏坑。

5.3 驱动层排查：QMYSQL 是否真的加载成功

最后再提一个容易被忽略的底层原因：QMYSQL 驱动插件本身有没有加载成功。

如果你在 Qt 里调用：

qDebug() << QSqlDatabase::drivers();

输出列表里没有QMYSQL，那说明驱动插件没有正确编译或部署。这种情况下，你连连接都建立不起来，更别说事务了。很多人把"连接失败"带来的连锁反应，也怪到了"Qt 不支持事务"头上，其实链路完全不在一个层面。

驱动加载正常后，还可以顺手确认它对事务能力的声明：

QString driverName = "QMYSQL"; QSqlDatabase db = QSqlDatabase::addDatabase(driverName, "check_conn"); db.setHostName("127.0.0.1"); db.setDatabaseName("your_db"); db.setUserName("your_user"); db.setPassword("your_password"); if (db.open()) { qDebug() << "Transactions supported:" << db.driver()->hasFeature(QSqlDriver::Transactions); } else { qDebug() << "open failed" << db.lastError().text(); }

如果这一句输出Transactions supported: true，那就没什么好争论的了——Qt 的驱动层明确支持事务。剩下的问题，就要往调用方式、存储引擎、隔离级别和连接管理这些方向继续查了。

我个人的排查习惯是：遇到"事务像没生效"的反馈，第一步不看 Qt 代码，先看数据库侧。开启事务之前，ENGINE是什么，autocommit是什么，隔离级别是什么，这三件事确认完，再回头看transaction()和commit()的调用姿势。绝大多数情况下，问题都藏在"服务端会话状态"或"驱动与连接使用方式"里，而不是那句被人反复提起的"Qt 不支持事务"。

说到底，MySQL 提供了一个足够可靠的事务引擎，Qt 也提供了完整的事务调用接口，而你的职责是弄清楚这两者之间的每一层细节。别急着下结论，先把引擎、驱动、调用方式这三件事排干净，再回头审视代码——你会发现，事务一直都在，只是你还没找到和它正确打招呼的方式。