Transactions Firebird只读事务

使用Firebird只读事务的优点是什么？我在Firebird数据库工作了七年多。我从未使用过这个选项。我只是好奇这个功能的典型场景是什么？我正在使用Firebird 2.5.x，但如果您对Firebird 3.x（或更新版本）有有用的见解，欢迎您发表意见。

当事务生效时，您会看到数据库的一致视图-其他连接或会话中的数据修改（删除/更新/插入）将不可见

用于组合报告，其中对同一数据运行多个查询以不同方式显示数据。如果每个查询独立运行，报告可能彼此不一致，因为后面的查询可能会看到不同的数据

---

不特定于Firebird-只读事务是一个常见的数据库短语，您可以在其上搜索更多信息

Firebird中的只读事务使用预先提交的事务（尽管它仍然需要以

提交

结束）。它不能更改数据库（除了在提交删除行时处于

状态的全局临时表），也不能锁定行或表。它确实提供了事务配置的可见性保证

使用只读事务的好处是它可以保证事务不会阻止其他事务。然而，由于Firebird中的大多数读取操作都不会阻止其他事务，所以这种好处并不是很大

此外，您可以使用只读事务来验证事务是否（直接或间接）修改数据库。
Firebird中只读事务的主要优点是此类事务不保存记录版本。因此，垃圾收集器可以有效地清理它们

此外，如上所述，只读事务永远不会阻止其他事务

为了提供最大的性能并将事务死锁风险降至最低，应用程序应使用短期更新事务和一个长期的只读事务（读取提交，REC版本）来读取数据。
如果事务隔离级别为读取提交，该怎么办？即使在这种情况下，其他事务的更改也不可见，这是真的吗？正如我在Firebird文档中看到的，只读和事务隔离级别是不同的。（）@truthseeker事务查看允许其查看的数据。对于read committed，这意味着它将状态视为在读取发生之前已提交，对于snapshot和并发，它将状态视为在事务启动之前已提交。这不会改变您是使用只读还是读写事务。它不会修改数据库的“逻辑视图”。它仍然可以创建许多BLOB，尽管这些BLOB将在事务终止时被删除。。。但是，由于只读转换往往寿命较长，正是在它们不改变任何符号且不花费任何成本的前提下，这一问题可能非常重要