企业官网建设流程全解析

先说一个很多开发者在群里问过我的问题：“MySQL 明明支持事务，为什么我的 Qt 程序里怎么弄都不生效？是不是 Qt 这玩意压根不支持事务？” 我第一次听到这问题时愣了一下，后来发现问的人还真不少。这个问题的骨子里藏着一个特别典型的认知错位：把数据库引擎的能力，和客户端框架的能力混为一谈了。MySQL 当然支持事务，前提是你用的是 InnoDB 引擎、走的是事务安全的表；而 Qt 确实没有“自带一种叫事务的东西”，因为它根本不需要自带——它是通过 Qt SQL 模块去操纵数据库，事务这种机制天然归数据库管。你真正该问的是：我有没有在 Qt 里，用正确的方式“请” MySQL 开启并提交一个事务？

这篇文章就把这件事彻底讲透：先拆清楚事务到底归谁管，再讲 Qt SQL 模块和事务的真实关系，然后给出可以直接抄作业的完整实操方案，最后把我这几年踩过的坑、排查过的案例一并整理出来。不管你是刚接触 Qt 的新手，还是写了几年 C++ 但一直没搞明白事务为什么“时灵时不灵”的老开发，这篇文章应该都能帮上忙。

1. 误解的根源：到底是 MySQL 不支持，还是 Qt 不支持？

1.1 事务的本质归属：数据库的核心能力，不是客户端的义务

先把这个最根本的概念摆正。事务（Transaction）是数据库管理系统提供的一种执行单元，它把一组操作打包成一个“要么全部成功、要么全部回滚”的原子过程。这个能力存储在数据库引擎内部——MySQL 里具体来说就是存储引擎的事，比如 InnoDB 负责实现事务所需的日志、锁、回滚段。客户端框架，无论是 Qt、JDBC 还是 Python 的 sqlite3 模块，都只是“传话筒”，把用户的意图翻译成数据库能理解的协议指令。

打个比方：数据库是一个保险柜，事务是保险柜内部的机械锁结构，而 Qt 是你拿着钥匙的那只手。保险柜能不能锁，取决于锁芯本身；手只是负责转动钥匙。你如果说“我有手，但保险柜怎么锁不上”，大概率是钥匙没插对位置，或者这个柜子装的根本不是带锁芯的型号。放到 MySQL 里，就是两个典型问题：第一，你用的表引擎是 MyISAM，它压根没有事务锁芯；第二，你确实连到了 InnoDB 表，但你的“手”没把钥匙拧到位——没显式开启事务，或者自动提交没关。

所以“Qt 不支持事务”这个命题，从一开始就不成立。Qt 是应用框架，不是数据库。它提供的是访问数据库的统一接口，事务支持能力取决于它对接的那个数据库驱动和数据库本身。换句话说，MySQL 支持事务，Qt SQL 模块就有办法把事务指令发过去；MySQL 某张表不支持事务，Qt 再努力也白搭。

1.2 “Qt 不支持事务”的说法从何而来

我来还原一下这个说法常见的几个来源，避免你以后被类似的说法带偏。

第一种是早期很多 Qt 教程把事务讲得含混。你搜“Qt 事务”，出来的结果经常是“QSqlDatabase::transaction()”“commit()”“rollback()”三个函数，不少人照猫画虎写了一遍，发现数据还是照样提交，根本没回滚，于是得出结论：“Qt 不支持事务”。实际上，绝大多数这种案例都是因为自动提交模式没有关掉，或者用的是 MyISAM 表。

第二种情况是驱动层面的限制。Qt SQL 模块通过驱动插件与数据库通信，常见的 QMYSQL、QPSQL、QODBC、QSQLITE 对事务的支持程度并不完全一样。比如 QSQLITE 驱动在某些旧版本里对事务的处理就比 MySQL 驱动更“敏感”，你开启事务后稍有不慎，连接关闭或者查询对象销毁，事务就直接被隐式提交了。如果一个人先用了 SQLite 的驱动踩了坑，再套到 MySQL 上，很容易产生“Qt 对事务支持不好”的印象。

第三种情况，是开发者把“Qt 在某些场景下没有自动回滚”理解成了“不支持”。实际上事务本身就是需要显式管理的，数据库不会替你决定什么时候提交、什么时候回滚。Qt 只是提供了接口，默认不会帮你把每个操作都包进事务里，这是设计如此，不是缺陷。

1.3 把问题追问到正确层级：MySQL 引擎差异才是关键

聊到这里，必须把 MySQL 自身的一个重要差异摆在台面上：存储引擎不同，事务支持完全不同。这是“MySQL 明明支持事务”这句话成立的前提条件。

如果你的表是用 MyISAM 建的，那么无论你在 Qt 里怎么调用transaction()，MySQL 都会默默接受指令然后什么也不做——因为 MyISAM 压根不实现事务。我见过一个真实的排查案例，某公司的统计系统，所有订单表都是 MyISAM，开发在 Qt 里兴致勃勃地写了事务回滚逻辑，测试了好久都没生效，最后 DBA 看了一眼表引擎，全明白了。

所以判断“事务到底支不支持”，正确的追问顺序是：MySQL 实例是什么版本、表是什么引擎、Qt 连的是哪个数据库、驱动是否正常加载、自动提交是否已关闭。这五层都对了，事务一定能够正常运作。

2. Qt SQL 模块与事务的真实关系

2.1 QSqlDatabase 与 QSqlQuery 在事务里扮演的角色

Qt SQL 模块的事务操作，核心对象是两个：QSqlDatabase负责管理连接，QSqlQuery负责执行 SQL。事务的开关由QSqlDatabase管理，这点很多新手容易搞错——他们以为在QSqlQuery上调用某个方法就能开启事务，实际上transaction()、commit()、rollback()这三个方法都在QSqlDatabase上。

// 获取默认数据库连接 QSqlDatabase db = QSqlDatabase::database(); // 开启事务 bool ok = db.transaction(); if (!ok) { qWarning() << "开启事务失败:" << db.lastError().text(); return; } // 执行 SQL QSqlQuery query(db); query.exec("UPDATE accounts SET balance = balance - 100 WHERE id = 1"); // 提交事务 if (!db.commit()) { qWarning() << "提交失败，执行回滚:" << db.lastError().text(); db.rollback(); }

这段代码看起来简单，但里面藏着一个非常重要的细节：QSqlQuery传入db作为参数。这个参数不是可选的摆设，它明确告诉 Qt“这条查询使用哪个数据库连接、归属于哪个事务上下文”。如果你创建一个没有指定数据库的QSqlQuery，它默认走默认连接，在大多数情况下没问题，但在多连接、多事务并发的场景下，极容易把查询发到错误的连接上，造成事务边界错乱。我的习惯是，凡是涉及事务的查询，一律显式传入连接对象，把这个养成肌肉记忆。

2.2 自动提交模式的陷阱

这是导致“Qt 事务不生效”的最大元凶。MySQL 默认的会话状态是自动提交（autocommit = 1），每一条 SQL 执行完都会被立即持久化。Qt 的QSqlDatabase::transaction()实际上做的是把自动提交临时关掉，然后发送START TRANSACTION或BEGIN指令给数据库，等commit()或rollback()时再恢复。

如果某个连接处在自动提交模式下，你执行的每条语句都会立即生效，回滚自然无从谈起。Qt 6 里提供了一个明确的接口来控制这个行为：

// 设置为手动提交模式 db.setCommitMode(QSqlDatabase::CommitMode::ManualCommit); // 手动开启事务 db.transaction(); // 这里执行的所有 SQL 都在事务保护内 // ... // 提交 db.commit();

在 Qt 5 及更早的版本里，没有setCommitMode这个公开接口，事务的开启依然是通过transaction()完成。关键区别在于：transaction()一旦成功调用，后续的语句就处于事务保护下；如果transaction()失败，代码又没有做错误处理，后续语句会在自动提交模式下裸奔。所以无论哪个版本，调用transaction()之后检查返回值，是绝对不能省的一步。

2.3 不同数据库驱动的事务能力差异

Qt 支持的数据库驱动不少，但每个驱动背后对应的数据库事务机制并不相同。这不代表 Qt“不支持”，而是说你在不同数据库上，需要了解对方的事务语义。

QSQLITE 驱动值得多提一句：SQLite 本身对事务的约束和 MySQL 不太一样，它的提交行为在某些边界情况下（比如连接中途关闭、查询对象析构时仍处于活动状态）会直接触发隐式提交。这导致不少开发者第一次接触 Qt 事务用的是 SQLite，然后留下心理阴影。其实 MySQL 的 QMYSQL 驱动稳定得多，只要引擎和自动提交没问题，事务行为是完全可以预期的。

3. 用 Qt 正确开启 MySQL 事务的完整实操

3.1 环境准备与驱动装载检查

在写任何事务代码之前，先确认 Qt 能正常连上 MySQL。这一步看似基础，但很多人栽在驱动上——Qt 默认不附带 MySQL 驱动，需要你自己编译或从安装包中选择。检查驱动是否可用：

// 打印所有可用的数据库驱动 QStringList drivers = QSqlDatabase::drivers(); qDebug() << "Available drivers:" << drivers; // 检查 MySQL 驱动是否在列表中 if (!drivers.contains("QMYSQL")) { qCritical() << "QMYSQL driver not available!"; return; }

如果输出里没有 QMYSQL，别急着写业务代码。常见原因是 Qt 安装时没选数据库驱动组件，或者系统缺少 MySQL 客户端库。以 Ubuntu 系为例，你可以安装libqt5sql5-mysql包；Windows 上则要确保 Qt 的 bin 目录下有qsqlmysql.dll或qsqlmysql.dll对应的调试版本。编译自研驱动时，需要把 MySQL 的 include 和 lib 路径传给 Qt，这个过程虽然有点繁琐，但一旦装好，后面就一劳永逸了。

连接数据库的完整代码：

QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL"); db.setHostName("127.0.0.1"); db.setPort(3306); db.setDatabaseName("test_db"); db.setUserName("app_user"); db.setPassword("your_password"); if (!db.open()) { qCritical() << "Cannot open database:" << db.lastError().text(); return; } qDebug() << "Database connected successfully";

注意一点：addDatabase的第一个参数是驱动名，第二个参数是连接名（可选）。如果你只创建一个连接，用默认连接名就行；如果你的程序需要同时操作多个数据库，每个连接都要起不同的连接名，并通过QSqlDatabase::database("conn_name")获取。事务是与连接绑定的，多个连接之间的事务互不干扰，这一点在并发场景下特别重要。

3.2 显式事务流程：transaction、commit、rollback 的工程写法

一个完整的事务流程，不只是“开事务、执行 SQL、提交”这么简单。真正工程级的写法，要处理中途失败、部分成功、连接异常等多个分支。我常用的模板如下：

bool executeTransfer(QSqlDatabase &db, int fromAccount, int toAccount, double amount) { // 1. 检查连接和事务状态 if (!db.isOpen()) { qWarning() << "Database connection is not open"; return false; } // 2. 开启事务，失败立即返回 if (!db.transaction()) { qWarning() << "Failed to start transaction:" << db.lastError().text(); return false; } QSqlQuery query(db); // 3. 执行第一条更新：扣款 query.prepare("UPDATE accounts SET balance = balance - :amount WHERE id = :id AND balance >= :amount"); query.bindValue(":amount", amount); query.bindValue(":id", fromAccount); if (!query.exec()) { db.rollback(); qWarning() << "Deduct failed, rolled back:" << query.lastError().text(); return false; } // 4. 检查受影响行数，确认余额足够且账户存在 if (query.numRowsAffected() != 1) { db.rollback(); qWarning() << "Account not found or insufficient balance"; return false; } // 5. 执行第二条更新：入账 query.prepare("UPDATE accounts SET balance = balance + :amount WHERE id = :id"); query.bindValue(":amount", amount); query.bindValue(":id", toAccount); if (!query.exec()) { db.rollback(); qWarning() << "Credit failed, rolled back:" << query.lastError().text(); return false; } // 6. 全部成功，提交 if (!db.commit()) { db.rollback(); qWarning() << "Commit failed, rolled back:" << db.lastError().text(); return false; } return true; }

这个模板里有几个细节值得展开说明。

第一，扣款语句里加了AND balance >= :amount条件，这是典型的乐观防超扣写法。如果余额不够，SQL 执行成功但不影响任何行，通过numRowsAffected()判断是否为 1，可以避免“先查后改”的竞态问题。

第二，QSqlQuery在prepare、bindValue、exec的循环中会被反复复用。每次exec之后，之前的绑定值会被清空，必须重新绑定。如果你有多个不同的 SQL，也可以在同一个QSqlQuery上反复调用prepare，这是允许的。

第三，commit()失败后调用rollback()看上去有点别扭，但这是有实际意义的：提交失败并不意味着事务一定已经结束，有些数据库在提交过程中发生网络中断等异常，事务可能还挂在会话上，此时主动调一次rollback()，可以确保会话状态被清理干净。

3.3 事务隔离级别的设置与代码示范

默认情况下，MySQL InnoDB 的隔离级别是REPEATABLE READ，这个级别在绝大多数业务场景下是安全的。但也有些场景，比如做报表统计、批量更新，你可能希望用更低级别的READ COMMITTED来减少锁竞争。Qt 没有提供直接设置隔离级别的 API，你需要在开启事务之前，通过 SQL 设置会话级隔离级别。

// 开启事务前，设置当前会话的隔离级别 QSqlQuery query(db); if (!query.exec("SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED")) { qWarning() << "Failed to set isolation level:" << query.lastError().text(); } // 再开启事务 db.transaction(); // ... 执行业务 SQL ...

为什么放在transaction()之前？因为 MySQL 中SET TRANSACTION的生效时机有讲究：会话级设置对后续事务生效，如果事务已经开启，再设置隔离级别，对当前事务是否生效取决于 MySQL 版本和设置方式。为了保险，我总是在开启事务前设置，并且明确使用SET SESSION而不是SET TRANSACTION。SET SESSION影响整个会话后续所有事务；SET TRANSACTION只影响下一个事务，而且需要在事务外执行。如果这两者混了，容易出现“设置了但没生效”的奇怪现象。

3.4 一个真实转账场景的完整演示

为了让上面的知识点串起来，我写一个完整可运行的例子。这个例子模拟两个账户之间的转账：在 Qt 界面里输入转出账户、转入账户、金额，点击按钮后调用事务逻辑。

#include <QCoreApplication> #include <QSqlDatabase> #include <QSqlQuery> #include <QSqlError> #include <QDebug> bool transferMoney(QSqlDatabase &db, int fromId, int toId, double amount) { if (fromId == toId) { qWarning() << "Cannot transfer to the same account"; return false; } if (!db.transaction()) { qWarning() << "Start transaction failed:" << db.lastError().text(); return false; } QSqlQuery query(db); // 扣款，注意余额校验 query.prepare("UPDATE accounts SET balance = balance - :amount " "WHERE id = :id AND balance >= :amount"); query.bindValue(":amount", amount); query.bindValue(":id", fromId); if (!query.exec() || query.numRowsAffected() != 1) { db.rollback(); qWarning() << "Deduct failed:" << (query.lastError().isValid() ? query.lastError().text() : "balance insufficient"); return false; } // 入账 query.prepare("UPDATE accounts SET balance = balance + :amount WHERE id = :id"); query.bindValue(":amount", amount); query.bindValue(":id", toId); if (!query.exec()) { db.rollback(); qWarning() << "Credit failed:" << query.lastError().text(); return false; } // 提交 if (!db.commit()) { db.rollback(); qWarning() << "Commit failed:" << db.lastError().text(); return false; } return true; } int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL"); db.setHostName("127.0.0.1"); db.setPort(3306); db.setDatabaseName("bank_demo"); db.setUserName("bank_user"); db.setPassword("bank_pass"); if (!db.open()) { qCritical() << "Open database failed:" << db.lastError().text(); return 1; } // 测试转账 if (transferMoney(db, 1001, 1002, 50.0)) { qDebug() << "Transfer succeeded"; } else { qDebug() << "Transfer failed"; } return 0; }

这个例子完整覆盖了：连接、开启事务、条件更新、受影响行数校验、失败回滚、成功提交。你把它抄到自己的项目里，替换成自己的表结构和业务 SQL，就是一个坚实的事务底子。

4. 事务与查询对象生命周期：一个容易踩的大坑

4.1 QSqlQuery 在事务中的活动状态问题

很多人在事务代码里踩过一个非常隐蔽的坑——QSqlQuery对象在事务未提交时被销毁，导致事务被隐式提交或者行为异常。这是怎么回事呢？

当一个QSqlQuery执行完一条 SQL 后，它可能还处于“活动”状态，尤其是执行了SELECT但还没有取完所有结果的时候。如果此时这个查询对象被销毁，Qt 驱动在清理对象时，会对数据库连接做一些收尾操作，这在某些数据库驱动下会触发事务中断或隐式提交。

// 危险写法 { QSqlQuery query(db); query.exec("SELECT ..."); } db.commit(); // 可能失效，事务在 query 销毁时已发生变化

正确的做法，是先确保查询对象不再活动，再结束事务。对于SELECT，可以调用query.finish()主动结束查询；对于INSERT/UPDATE/DELETE，exec()完成后查询对象通常已经结束活动，问题一般不大。稳妥的写法是：

{ QSqlQuery query(db); query.exec("SELECT ..."); // 处理结果集 while (query.next()) { // ... } query.finish(); // 显式结束活动状态 } // 现在再提交事务 db.commit();

这个细节在 MySQL 驱动上不一定每次都会出问题，但一旦出问题，现象非常诡异：同一段代码，有时事务生效有时不生效，或者提交时报错“Query is still active”。从养成良好的编码习惯出发，事务内创建的查询对象，在事务提交前明确结束活动状态，能省掉大量排查时间的浪费。

4.2 多个 QSqlQuery 实例在事务中的行为

一个事务里，能否创建多个QSqlQuery实例同时操作？答案是可以，但这中间有讲究。多个QSqlQuery实例共享同一个连接的事务上下文，只要它们都是基于同一个QSqlDatabase连接创建的，它们执行的 SQL 就都在同一个事务保护范围内。

// 两个查询对象，同一个事务 QSqlQuery q1(db); QSqlQuery q2(db); q1.exec("UPDATE accounts SET balance = balance - 100 WHERE id = 1"); q2.exec("UPDATE accounts SET balance = balance + 100 WHERE id = 2"); db.commit();

这里要注意，q1和q2不是线程安全的，如果两个线程分别持有一个QSqlQuery但共用同一个数据库连接，Qt 文档明确指出这不安全。多线程环境下的事务，必须为每个线程建立独立的数据连接。一个常见的架构错误是：主线程开事务，工作线程用同一个连接执行 SQL，结果要么事务边界被破坏，要么直接崩溃。

4.3 嵌套事务与保存点的 Qt 实现

MySQL 的 InnoDB 引擎支持嵌套事务的替代方案——保存点（SAVEPOINT）。真正的嵌套事务在 MySQL 中并不存在，但你可以通过保存点在事务内部设置回滚点，实现“部分回滚”的效果。Qt 没有封装保存点 API，只能通过原生 SQL 操作。

// 开启外层事务 db.transaction(); QSqlQuery query(db); // 操作 A query.exec("INSERT INTO logs (message) VALUES ('step1')"); // 设置保存点 query.exec("SAVEPOINT sp1"); // 操作 B query.exec("INSERT INTO logs (message) VALUES ('step2')"); // 回滚到保存点 sp1，操作 B 被取消，操作 A 保留 query.exec("ROLLBACK TO SAVEPOINT sp1"); // 继续操作 C query.exec("INSERT INTO logs (message) VALUES ('step3')"); // 外层事务提交，最终只有 step1 和 step3 被持久化 db.commit();

这个模式在处理复杂业务时非常有用。比如一个批处理任务，处理前 100 条数据成功，第 101 条失败，你只想回滚到某个检查点，而不是把整个批次都回滚掉。保存点就是把“全有或全无”的事务，变成“可以有条件放弃一部分”的灵活工具。但使用时要清楚：保存点在 MySQL 中是 InnoDB 的特性，MyISAM 表不生效；而且保存点数量不宜过多，每个保存点都会占用 InnoDB 内部资源，批量插入场景下一两条保存点没问题，别在循环里无脑设置。

5. 常见问题排查与实操经验

5.1 典型问题速查表

我梳理了这几个问题最常出现的现象、原因和解决办法，做成一个速查表，你遇到类似问题时可以对照着查。

5.2 事务不生效的排查套路

如果你遇到事务不生效，先别急着怀疑 Qt，按下面的顺序一步步排查，八成能定位到问题。

第一步，确认表引擎。执行SHOW TABLE STATUS LIKE 'your_table'，看 Engine 列是不是 InnoDB。不是的话，一切免谈。这是最基础的一步，但也是最容易被忽略的一步。

第二步，确认自动提交状态。在 MySQL 客户端里执行SELECT @@autocommit;，如果结果是 1，说明会话是自动提交模式。Qt 的transaction()理论上会改变这个状态，但如果你在业务代码里不小心重连了数据库，或者某个操作把连接重置了，自动提交就可能恢复。

第三步，确认连接没有在中途被替换。很多人写代码时用了个单例函数返回数据库连接，每次获取都调用QSqlDatabase::database()，这个函数在没有连接时会默认创建一个新连接。如果你的事务开始用的是连接 A，中间某个查询因为连接名不对又创建了连接 B，那事务自然就“断”了。

第四步，确认commit()和rollback()的调用位置。事务必须在同一个连接上完成，跨连接提交是无效的。打印一下数据库连接名和指针，确认事务的 begin 和 end 都在同一个连接实例上。

第五步，开启 Qt SQL 日志。通过QLoggingCategory设置 Qt SQL 模块的调试输出，能看到 Qt 实际发送给数据库的 SQL 指令，包括START TRANSACTION、COMMIT等。这个方法在大多数疑难杂症面前都有效，推荐优先使用。

QLoggingCategory::setFilterRules("qt.sql.qmysql=true"); QLoggingCategory::setFilterRules("qt.sql=true");

5.3 QMYSQL 驱动的一些工程细节

最后聊几个我在实际项目里积累的细节，这些经验不一定写在 Qt 文档里，但确实能帮你少走弯路。

关于驱动加载，如果你的程序部署到一台没有安装 MySQL 客户端的机器上，QMYSQL 驱动会加载失败。我用过一个办法，把 MySQL 客户端库一起打包到应用目录，然后在代码里用QCoreApplication::addLibraryPath()添加驱动搜索路径，或者在部署脚本里把驱动和客户端库放到对应位置。Windows 下常见的是目录结构：sqldrivers/qsqlmysql.dll和libmysql.dll或libmariadb.dll放在 EXE 同目录。这两者缺一不可，很多人只拷贝了 qsqlmysql.dll，没拷贝 libmysql.dll，导致运行时直接报“Driver not loaded”。

关于setCommitMode，这是 Qt 6 引入的接口，目的是让开发者显式控制提交模式。我有一次处理一个大批量导入场景，每秒要插入上千条记录，每条都走默认的自动提交模式，性能惨不忍睹。后来改成：先setCommitMode(ManualCommit)，然后transaction()，分批插入 500 条后commit()一次，性能直接提升了近十倍。这不是事务本身的魔法，而是减少了每次插入后的磁盘同步开销。如果你在 Qt 5 上，没有这个接口，也可以频繁调用transaction()和commit()达到类似效果，但每次调用都有额外开销，尽量拉大事务的粒度。

关于异常安全，事务代码最怕的就是函数中途抛出异常或者提前 return，导致事务既没提交也没回滚。我的习惯是用一个 RAII 风格的辅助类：

class TransactionGuard { public: explicit TransactionGuard(QSqlDatabase &db) : m_db(db) { m_active = m_db.transaction(); } ~TransactionGuard() { if (m_active) { m_db.rollback(); } } bool commit() { if (!m_active) return false; bool ok = m_db.commit(); if (ok) m_active = false; return ok; } bool isActive() const { return m_active; } private: QSqlDatabase &m_db; bool m_active = false; };

用这个类包住事务代码，函数里不管走哪个分支，只要没有显式commit()，析构时都会自动回滚。我把它用在一个反复重构过的老项目里，极大地减少了“忘记回滚导致脏数据”的问题。

关于多行插入的事务边界，有一点容易被忽略：execBatch()方法批量插入数据时，如果一条失败，驱动的行为可能不是回滚整批，而是跳过错误继续。如果你依赖execBatch()保证数据一致性，需要自己检查返回值并决定是否回滚整个事务。这一点我踩过坑，某次批量导入用户数据时，中间一条数据因为字段过长失败，结果前后数据都进了库，而我只检查了execBatch()的返回值，它返回 true 但实际有些行没插进去。从那以后，批量导入场景我都会先做数据清洗，或者在事务里逐条exec()，确保每条都成功后才提交。

结尾

写了这么多，最后分享一点个人的感受。这个问题的答案，其实早就在问题本身里——“MySQL 支持事务”是数据库的承诺，“Qt 不支持”是框架的边界。两者并不矛盾，也不冲突，真正的鸿沟在开发者对工具层次的理解上。我见过太多人把时间浪费在“Qt 到底行不行”的纠结上，却忽略了真正的问题：自己的表是不是 InnoDB、自己在代码里有没有正确管理事务边界、有没有在事务里做不该做的耗时操作。你在自己的项目里动手验证一遍，把事务日志打开，亲眼看看START TRANSACTION和COMMIT是怎么发出去的，这些概念就再也难不倒你了。