我们在不需要的情况下使用XA JDBC驱动程序（不参与分布式事务的只读工作）。
只是想知道是否有任何已知的性能提升需要切换到非XA JDBC驱动程序 - 如果不是，它可能不值得切换？
FWIW我们正在使用MySQL 5.1
答案 0 :(得分：22)
与性能相关的所有事情一样，答案是：它取决于。具体来说，它取决于您使用驱动程序的确切方式。
与数据库进行事务交互的成本大致分为：代码复杂性开销，通信开销，SQL处理和磁盘I / O.
XA和非XA案例之间的通信开销略有不同。在其他条件相同的情况下，XA事务在这里需要更多的成本，因为它需要更多的往返数据包。对于手动提交模式下的非XA事务，成本至少为两次调用：sql操作和提交。在XA的情况下，它是启动，sql操作，结束，准备和提交。针对您的具体用例，将自动优化启动，sql操作，结束，准备。并非所有调用都具有相同的成本：结果集中移动的数据通常占主导地位。在局域网上，额外往返的费用通常不大。
但是请注意，有一些有趣的陷阱潜伏在等待粗心的人。例如，某些驱动程序不支持在XA模式下使用预准备语句缓存，这意味着XA使用会带来在每次调用时重新解析SQL的额外开销，或者要求您在驱动程序之上使用单独的语句池。关于池的主题，正确池化XA连接比池化非XA连接要复杂一些，因此根据连接池的实现，您可能会看到轻微的打击。如果某些ORM框架在事务范围内使用激进的连接释放和重新获取，则它们特别容易受到连接池开销的影响。如果可能，配置为在tx的生存期内抓取并保持连接，而不是多次点击池。
通过前面提到的关于缓存预准备语句的警告，XA和非XA tx之间的sql处理成本没有实质性差异。但是，对于数据库服务器上的资源使用存在小的差异：在某些情况下，服务器可能会在非XA情况下更快地释放资源。但是，交易通常很短，这不是一个重要的考虑因素。
现在我们考虑磁盘I / O开销。这里我们关注的是XA协议引起的I / O而不是业务逻辑所使用的SQL，因为后者在任何一种情况下都没有变化。对于只读事务，情况很简单：合理的db和tx管理器不会执行任何日志写入，因此没有开销。对于写案例，由于XA的一阶段提交优化，db是唯一涉及的资源，因此也是如此。对于2PC情况，每个数据库服务器或其他资源管理器需要两个磁盘写入而不是非XA情况下使用的磁盘写入，并且tx管理器同样需要两个。由于磁盘存储速度缓慢，这是XA与非XA性能开销的主要来源。
几段回来我提到了代码的复杂性。 XA比非XA需要稍多的代码执行。在大多数情况下，复杂性都隐藏在事务管理器中，尽管如果您愿意，您当然可以直接驱动XA。根据已经提到的警告，费用大多是微不足道的。除非您使用特别差的事务管理器，否则您可能会遇到问题。只读的情况特别有趣 - 事务管理器提供程序通常将其优化工作放在磁盘I / O代码中，而锁争用对于只读用例来说是一个更重要的问题，特别是在高度并发的系统上。
另请注意，tx管理器中的代码复杂性在具有应用服务器或其他标准事务管理器提供程序的体系结构中是一种红色鲱鱼，因为这些代码通常使用与XA和非XA事务协调相同的代码。在非XA情况下，要完全错过tx管理器，通常必须告诉应用服务器/框架将连接视为非事务性连接，然后使用JDBC直接驱动提交。
所以摘要是：无论XA /非XA选择，您的SQL查询的成本将主导只读事务时间，除非您搞乱配置中的某些内容或者在每个tx中执行特别简单的sql操作，后者是一个标志，您的业务逻辑可能会使用一些重组来改变每个tx中tx管理开销与业务逻辑的比率。
对于只读情况，通常的事务协议不可知建议因此适用：在ORM解决方案中考虑事务感知级别二级缓存，而不是每次都访问DB。如果失败了，请调整sql，然后增加db的缓冲区缓存，直到看到90％+命中率或最大化服务器的RAM插槽，以先到者为准。只有在你做完之后才会担心XA与非XA，发现事情仍然太慢。
答案 1 :(得分：0)
简要解释一下， XA交易是一个全球交易＆＃34;。 非XA交易是＆＃34;本地交易＆＃34;。
XA事务涉及协调事务管理器，其中一个或多个数据库（或其他资源，如JMS）都涉及单个全局事务。 非XA事务没有事务协调器，并且单个资源本身正在执行其所有事务处理。