下面引用的摘录在这一点上似乎是矛盾的。
（我认为它们都很老了，第二个是从2004年开始，第一个提到Borland所以一定也要老了，所以也许它们已经过时了。）
第一个似乎暗示提交保留会使事务处于活动状态，因此会坚持使用OIT。
第二，如果我理解它意味着通过保留提交，现有的TID被标记为已提交，并且事务保持活动但具有新的TID，因此不会粘贴OIT。第二个摘录与Interbase有关，我不知道这是否解释了看似矛盾的原因。
使用Firebird（和InterBase），Commit Retaining会导致事务处理 无限期地保持有趣。垃圾收集有效停止 关于“标准”Borland RAD工具数据库应用程序和任何其他 使用Commit Retaining的应用程序。
读取已提交，读写：
此交易可以永久运行而不会产生负面影响 如果你不时保留提交的话。
答案 0 :(得分：4)
当您对Firebird使用提交保留（使用API或使用COMMIT RETAIN）时，启动的事务并未真正结束，它只是与已启动的新事务中的可见事务集相关联在内部，同时也保持旧的活跃。
这意味着Oldest Interesting和Oldest Active事务不会移动，并且返回的版本会累积，在真正提交事务之前无法进行垃圾回收。这意味着最终查询将需要扫描更长的记录版本链，这可能会对性能产生影响。
我假设有一些可能的优化，例如，如果没有在事务中启动的游标打开，原始事务可能会被标记为已提交（提交保留的一个特性是游标未关闭）事务提交，如果我没有弄错的话 - 要求旧的事务上下文保持可用。这可能是InterBase为读取已提交事务所做的事情。
这可以通过启动isql会话并与提交保留一起执行一些插入来自己看到：如果组合检查gstat -h，您会注意到最有趣和最旧的活动事务不会移动直到你真的承诺。