SQLite事务回滚失败的影响及事务内修改可见性咨询

让我分两部分来逐一解答你的疑问：

1. ROLLBACK执行失败会发生什么？ #

首先，SQLite中ROLLBACK执行失败的情况并不常见，但可能由这些原因导致：比如数据库连接意外中断、磁盘IO错误、数据库文件被其他进程锁定、或者事务本身已经处于某种异常状态（比如之前的操作已经导致事务隐式回滚）。

当ROLLBACK返回非SQLITE_OK的错误码时，当前的事务状态会变得不确定——你无法确定事务是否真的回滚成功，数据库可能处于部分回滚或者完全未回滚的不一致状态。这种情况下，继续使用这个数据库连接是非常危险的，后续操作可能会导致更严重的数据损坏。

针对这种情况的处理建议：

• 首先记录下ROLLBACK的错误码和错误信息（可以通过sqlite3_exec的最后一个参数获取），方便排查问题根源；
• 立即关闭当前的数据库连接，不要尝试在这个连接上继续执行任何操作；
• 重新打开数据库连接后，建议先执行完整性检查（比如PRAGMA integrity_check;），确认数据库文件没有损坏；
• 如果是因为锁定导致的回滚失败，可以在短时间后尝试重新连接并处理，但不要在同一个连接上重试回滚。

另外补充一点：你提到会检查COMMIT的返回值并回滚，这是个很好的习惯，但要注意COMMIT失败时，SQLite通常会自动隐式回滚事务（除非是严重的IO错误），不过显式执行ROLLBACK还是更稳妥的做法。

2. 事务未提交时能否立即查询到自己的修改？ #

你的这个假设是完全正确的。

在SQLite中，默认的事务隔离级别是SERIALIZABLE（你也可以显式设置其他级别，但默认是这个）。在同一个事务内，你执行的INSERT/UPDATE/DELETE操作所做的修改，会立即对当前连接的SELECT查询可见——这是事务的“一致性”特性决定的，同一个事务内的读写操作是原子且一致的，你看到的是自己修改后的数据库状态。

不过要注意：这些未提交的修改不会被其他数据库连接看到，直到你执行COMMIT提交事务。其他连接要么看到事务开始前的数据库状态，要么看到提交后的状态，不会看到中间的部分修改。

内容的提问来源于stack exchange，提问作者matteof93