CI3事务回滚本质是调用数据库引擎的原生回滚机制，非自身日志系统；需启用InnoDB引擎、正确使用trans_start()/trans_complete()，并通过trans_status()判断并验证数据是否真正回滚。
CI3（CodeIgniter 3）本身不内置事务日志回滚能力，它依赖底层数据库引擎（如 MySQL、PostgreSQL 或 SQLite）的 ACID 特性来保障事务一致性。所谓“事务回滚更新失败后的数据恢复”，本质是利用数据库原生事务机制 + CodeIgniter 3 的事务控制接口（$this->db->trans_start() / trans_complete()）实现原子性操作，并在失败时撤销全部变更——不是靠日志重放，而是靠数据库引擎即时回滚。
明确CI3事务回滚的本质
CI3 的事务控制是包装器，不是独立日志系统：
- 它不生成或管理 WAL（Write-Ahead Log）等持久化日志；
- 所有回滚动作由数据库服务端执行（如 MySQL 的 InnoDB 引擎），CI3 只负责发送
ROLLBACKSQL 命令； - 一旦
trans_complete()返回false，CI3 会自动触发ROLLBACK，无需手动调用； - 若未启用事务包装（即没调用
trans_start()），单条insert()或update()出错，不会自动回滚其他已执行语句——这是常见误用点。
实操：正确启用与验证事务回滚
以用户注册+积分初始化为例（两表联动，必须全成功或全失败）：
$this->db->trans_start();
$this->db->insert('users', ['name' => 'Alice', 'email' => 'a@b.com']);
$user_id = $this->db->insert_id();
$this->db->insert('points', ['user_id' => $user_id, 'amount' => 100]);
$this->db->trans_complete();
if ($this->db->trans_status() === FALSE) {
// 回滚已自动发生，此处仅作日志/提示
log_message('error', '注册事务失败，已回滚');
return false;
}
// 成功则继续后续逻辑
关键细节：
- 必须在
trans_start()之后、trans_complete()之前执行所有 DB 操作； - 不能混用
query()手动 SQL 和 Active Record 方法，否则事务状态可能不同步； - MySQL 必须使用 InnoDB 引擎（MyISAM 不支持事务）；
- SQLite 同样支持，但需确保开启
PRAGMA journal_mode = WAL提升并发安全性。
更新失败后如何确认数据已真正回滚？
不能只信返回值，要验证数据库状态：
- 在事务块内故意触发错误（如插入违反唯一索引的 email），然后查表：
SELECT COUNT(*) FROM users WHERE email = 'a@b.com';应为 0； - 启用 CI3 数据库调试：
$this->db->save_queries = TRUE;，检查日志中是否出现ROLLBACK； - 对 MySQL，可临时开启 general_log：
SET GLOBAL general_log = 'ON';，观察实际执行的语句流。
当“回滚看似失效”时排查方向
常见假象及真实原因：
-
表引擎不支持事务：运行
SHOW CREATE TABLE users;确认 ENGINE=InnoDB； -
事务被意外提交：CI3 在脚本结束或连接关闭时会隐式提交，确保没有提前调用
$this->db->trans_commit()； - 跨连接操作：事务只作用于当前数据库连接，避免在事务中调用其他类的 DB 实例；
-
非事务性语句干扰：DDL（如
CREATE TABLE）、LOCK TABLES会隐式提交当前事务。
