Laravel如何在事务中使用原生SQL语句_Laravel原生SQL事务执行方法【数据库】

在日常开发中，当我们需要在Lara vel里执行多条原生SQL语句时，如何保证这些操作要么全部成功、要么全部回滚，是一个很实际的挑战。涉及到插入、更新、删除这类写操作，如果少了事务的约束，一旦某条语句执行失败，就可能导致数据不一致，留下难以排查的隐患。下面就来拆解几种在Lara vel中实现原生SQL事务控制的方案。

其实，Lara vel对事务的支持相当成熟，核心思路就是把这些原生SQL语句包裹在一个事务上下文中，利用数据库的原子性来兜底。下面这些方法，覆盖了从简单到复杂的常见场景。

一、使用 DB::transaction() 包裹 DB::statement()

第一种方法，本质上就是利用 Lara vel 内置的事务管理器，让它自动帮你处理提交和回滚。这对于执行那些不返回结果集的原生SQL来说，是最省心的方式。

具体怎么做？在控制器或者服务类里，先引入 DB 门面，然后调用 DB::transaction()，传入一个闭包，在闭包里面依次执行 DB::statement() 就行了。举个例子：

DB::transaction(function () {
DB::statement('INSERT INTO users (name, email) VALUES (?, ?)', ['Alice', 'alice@example.com']);
DB::statement('UPDATE profiles SET bio = ? WHERE user_id = ?', ['Developer', 1]);
});

这个事务块有一个很聪明的设计：闭包里的任何一条语句抛出异常，整个事务就会自动回滚。如果你需要手动触发回滚，直接在闭包内抛出一个 Throwable 子类异常即可，比如 throw new \Exception('Custom rollback condition')。

二、使用 DB::beginTransaction() 与手动控制

有时候，业务逻辑没那么简单，你可能需要在执行过程中动态判断：是提交还是回滚？比如，根据某条SELECT查询的结果来决定后续操作是否继续。这时候，就需要手动控制事务的生命周期了。

流程很清晰：先显式开启事务，执行多条原生SQL，然后根据业务逻辑来决定提交还是回滚。

DB::beginTransaction();
DB::statement('INSERT INTO logs (action) VALUES (?)', ['user_created']);
$count = DB::select('SELECT COUNT(*) as cnt FROM users WHERE active = ?', [1])[0]->cnt;

if ($count > 100) {
DB::commit();
} else {
DB::rollback();
}

这种手动控制的方式，给了开发者更大的灵活性，但也意味着你要更小心地确保每个分支都把事务给关了，否则很容易出现锁等待或者连接泄漏的问题。

三、在 DB::transaction() 中混合使用 DB::select() 与 DB::update()

在实际项目中，经常会遇到这样一种场景：先读数据，然后根据读到的结果决定怎么写。比如，在转账操作中，先查余额，再决定是否扣款。这种读写混合的操作，如果放在一个事务里，就能有效避免脏读或者部分写入的问题。

做法也很简单：在事务闭包内，先执行原生 SELECT 获取关键值，然后基于这个结果构造并执行 UPDATE 语句。

DB::transaction(function () {
$balance = DB::select('SELECT balance FROM accounts WHERE id = ?', [123])[0]->balance;

if ($balance >= 500) {
DB::statement('UPDATE accounts SET balance = balance - ? WHERE id = ?', [500, 123]);
DB::statement('INSERT INTO transactions (account_id, amount, type) VALUES (?, ?, ?)', [123, -500, 'withdrawal']);
} else {
throw new \RuntimeException('Insufficient balance');
}
});

注意这里的关键点：如果条件不满足，比如余额不足，闭包自然结束并不会自动回滚，因为事务在闭包执行完毕后才会提交。所以，正确的做法是显式抛出一个异常，强制事务回滚。否则，即使没有发生写操作，事务也会正常提交，这往往不是我们想要的结果。

四、使用 DB::unprepared() 执行含多语句的原生 SQL 脚本

最后一种方法，适用于那些需要一次性执行包含多个分号分隔语句的 SQL 脚本，比如存储过程调用、批量 DDL/DML 操作。DB::unprepared() 可以接收一个包含多条语句的字符串，但这需要特别注意一些前置条件。

首先，必须在数据库连接配置中禁用预处理模拟，否则 PDO 无法正确处理多语句。在 config/database.php 里，为对应的连接配置添加：

'options' => [PDO::ATTR_EMULATE_PREPARES => false]

然后，把这个多语句字符串传入 DB::unprepared()，并确保它被包裹在一个事务块内。

DB::transaction(function () {
DB::unprepared('SET @x = 1; INSERT INTO tmp_values (val) VALUES (@x); UPDATE counters SET total = total + @x;');
});

但这里有一个必须警惕的陷阱：DB::unprepared() 不支持参数绑定。这意味着，如果你把用户输入直接拼接到 SQL 字符串里，就会面临严重的 SQL 注入风险。所以，对于敏感数据，要么预先过滤，要么改用参数化语句拆分执行。一句话总结：禁止直接拼接用户输入到 unprepared 字符串中。

以上四种方法，基本覆盖了 Lara vel 中使用原生 SQL 进行事务控制的常见场景。从最省心的自动事务，到手动控制的灵活方案，再到读写混合的原子性保障，最后到多语句脚本的执行，每种方法都有其适用的场景和需要注意的细节。把握好这些原则，就能在原生SQL操作中，稳稳地守住数据一致性的底线。