关于使用事务从数据库中读取似乎有非常不同的意见。
引自 DeveloperWorks 文章交易策略：模型和策略概述：
如果您只读取数据，为什么需要事务？答案是你没有。启动事务以执行只读操作会增加处理线程的开销，并可能导致数据库上的共享读锁（取决于您使用的数据库类型和隔离级别设置）。
作为相反的意见，以下引用来自 Hibernate 文档非事务性数据访问和自动提交模式
我们的建议是不要在应用程序中使用自动提交模式，并且仅在有明显性能优势或未来代码更改极不可能时才应用只读事务。无论您是读取还是写入数据，始终更喜欢使用常规 ACID 事务来对数据访问操作进行分组。
在 EclipseLink 邮件列表上也有类似的争论。
那么真相在哪里呢？用于阅读最佳实践的交易是否是最佳实践？如果两者都是可行的解决方案，那么使用事务的标准是什么？
据我所知，只有在隔离级别高于“已提交读”时才会有所不同。它是否正确？
有哪些经验和建议？
Steven Devijver 提供了一些启动事务的充分理由，即使这些操作只是读取数据库：
标准 SQL 要求，如果当前没有正在进行的事务，则即使是查询也必须启动新事务。有些 DBMS 不会发生这种情况——例如，那些具有自动提交模式的 DBMS（语句启动事务并在语句完成后立即提交）。其他 DBMS 默认情况下使语句原子化（有效地自动提交），但使用诸如“BEGIN WORK”之类的语句启动显式事务，取消自动提交直到下一次 COMMIT 或 ROLLBACK（IBM Informix Dynamic Server 就是这样 - 当数据库不是 MODE 时ANSI）。
我不确定永远不要回滚的建议。它对只读事务没有影响，并且在某种程度上它会惹恼您的 DBA，那么最好避免 ROLLBACK。但是，如果您的程序在没有执行 COMMIT 的情况下退出，DBMS 应该对您不完整的事务执行 ROLLBACK - 当然如果它修改了数据库，并且（为简单起见）即使您只选择了数据。
总的来说，如果要更改一系列操作的默认行为，请使用事务，即使事务是只读的。如果您对默认行为感到满意，那么使用事务并不重要。如果您的代码要在 DBMS 之间移植，最好假设您需要一个事务。
首先，这听起来像是过早的优化。正如 Steven 所指出的，大多数健全的数据库无论如何都会让你进入一个事务，而他们真正做的只是在每个语句之后调用 commit。所以从这个角度来看，自动提交的性能可能会降低，因为每个语句都必须启动一个新事务。或者可能不是。只有基准测试才能说明问题，我敢打赌它不会对您的应用程序产生任何影响。
您希望始终使用事务的一个原因是保护的一致性。如果您仅在“需要”时才开始手动声明事务，那么您将在关键时刻忘记。或者那组所谓的只读操作突然不是，要么是因为后来的程序员没有意识到它应该是，要么是因为你的代码调用了一个具有隐藏写入的函数。例如，我将命令行数据库客户端配置为不自动提交。这意味着我可以用手指删除查询并且仍然回滚。
正如所指出的，存在隔离级别。这使您可以进行多次读取，而不必担心是否有其他进程在它们之间写入了您的数据，从而使您的读取有效地原子化。这将使您免于调试竞争条件的许多小时。
最后，您通常可以将事务设置为只读。这会检查您的假设，如果尝试写入，则会出错。
这是一篇很好的文章，总结了这一切。 细节是特定于 Oracle 的，但概念是通用的。
如果要为查询设置特定超时而不是默认超时，或者要更改隔离级别，则只读操作需要事务。
此外，每个数据库——不知道异常——都会在内部为每个查询启动一个事务。当不需要回滚时，通常认为不回滚事务。
DBA 可能正在监视回滚活动，在这种情况下，任何默认的回滚行为都会惹恼他们。
因此，无论您是否启动事务，都将使用事务。如果您不需要它们，请不要启动它们，但不要对只读操作进行回滚。