Performance 长期存在的数据库事务相互交错，性能损失是多少？

有谁能给我提供一个解释，或者给我指出一个好的来源，当涉及其他事务时，在那里可以解释长寿命数据库事务的影响

考虑到不同的隔离级别，我很难理解事务对应用程序性能的真正影响，其中大多数查询是读取的，可能有两三个查询是写入的

我最想了解的情况是：

任何其他事务都不涉及读取的行或更新的行。 读取的行涉及另一个事务，但不涉及正在更新的行，并且该另一个事务是只读的。 读取的行涉及另一个事务，但不涉及正在更新的行，而另一个事务正在修改正在读取的某些数据。据我所知，这也会影响在修改之前还是之后读取数据。 读取的行和更新的行都涉及到另一个也修改数据的事务。

---

这些问题出现在使用微服务的应用程序的上下文中，其中所有应用程序层服务都使用@Transactional using JPA和PostgreSQL进行注释，为了转换数据，它们需要对事务中的其他微服务进行一些网络调用，以获取一些其他值

这在很大程度上取决于您的dbms是否支持MVCC。在这种情况下，除了必要的空间外，行的读取对其他事务没有影响，只要读取事务正在运行，dbms就必须提供保留前映像的空间。所以在这种情况下，除了磁盘空间之外，唯一的问题就是池中的连接被使用的时间，对吗？如果在一些select语句中有一行正在被几个打开的事务更新，该怎么办？我的理解是，这取决于所使用的隔离级别，因此确保每次写入都使用来自数据库的最新数据的唯一方法是使用可序列化隔离级别。根据所涉及的不同事务的执行顺序，任何其他事务都可能导致不同的结果。因此，在这种情况下，事务打开的时间越长，事务使用过时数据的可能性就越大。因此，使用MVCC而不是悲观锁定策略，虽然性能更高，但更容易出错，并且越早提交事务，减少不一致性越好。是否正确？同一行的第一次并发写入是同步的，这不取决于isolationlevel。第二：是的，但我不太容易出错，因为您总是基于一致的数据视图进行更改。重要的是，您是否可以通过在更改过程中检测或防止使用锁来正确处理并发更改。