在seata全局事务中 对一条记录进行如下操作，1：新增，2：更新 ，如果发生异常全局回滚，如果先对

在 Seata 全局事务中对一条记录进行新增和更新操作，如果发生异常全局回滚，那么如果先对新增操作的分支事务进行回滚，可能会导致回滚失败。这种情况可能会影响到全局事务的状态和一致性，因此建议您采取以下措施：

尽可能避免在单个全局事务中同时进行新增和更新操作，以减少回滚失败的风险。如果确实需要进行这样的操作，可以考虑将其拆分成多个子事务来进行处理，以提高事务的可靠性和稳定性。

如果发生了回滚失败的情况，可以尝试进行手动干预，例如通过修改数据库记录或清除事务日志等方式来恢复事务状态。但是，这种方式可能会带来额外的风险和复杂性，因此需要谨慎处理。

在 Seata 1.4.2 版本中，已经引入了一些与回滚失败相关的修复和优化，您可以尝试升级到最新版本的 Seata，以获得更好的稳定性和可靠性

这是因为 Seata 在进行回滚操作时会使用镜像校验机制，即校验回滚前和回滚后的数据是否一致。如果回滚前的数据已经被修改，导致回滚后的数据和镜像不一致，那么回滚操作就会失败。在执行回滚操作前，确保数据的一致性。可以在回滚操作之前对数据进行校验，确保回滚前和回滚后的数据一致。如果数据不一致，可以尝试手动修复数据，或者调整回滚的策略。

使用合适的业务逻辑和代码结构，尽量避免在同一个全局事务中对同一条记录进行新增和更新操作。如果可能，可以将新增和更新操作分开，拆分成独立的事务操作。

升级 Seata 的版本。有时候，Seata 的新版本可能修复了一些已知的问题和bug，可能会提供更好的回滚机制和数据一致性保证。

在 Seata 全局事务中，对于一条记录进行新增和更新操作，并发生异常导致全局回滚时，如果先对新增的分支事务进行回滚且回滚失败（存在镜像校验），是否会导致一直回滚失败的情况，这取决于具体的配置和环境。

Seata 的 1.4.2 版本引入了镜像日志补偿机制来处理分布式事务的异常情况。当分支事务回滚失败时，Seata 会尝试使用镜像日志进行补偿，即通过读取镜像日志，执行与失败事务相反的操作来恢复数据状态。但是，补偿机制也有一定的限制和前提条件：

1. 镜像日志可用性：要求在对分支事务进行回滚时，必须能够正确地获取到镜像日志。如果因为网络问题或其他原因无法获取到镜像日志，那么回滚将失败。

2. 数据库设置与兼容性：确保数据库的配置和版本与 Seata 要求的兼容，并且开启了 Binlog，以便 Seata 可以正常读取和使用镜像日志进行补偿。

3. 分支事务对应的资源管理器兼容性：不同的资源管理器对于分布式事务的处理方式可能不同，需要确保所使用的资源管理器与 Seata 兼容，并正确实现了事务的回滚操作。

如果上述条件都满足，Seata 应该能够使用镜像日志进行补偿并成功回滚分支事务。但是如果出现连续多次回滚失败的情况，建议检查和排除以下可能原因：

• 镜像日志配置问题：确保 Seata 的配置文件中启用了镜像日志模式，并设置了正确的镜像日志相关参数。

• 数据库配置和兼容性问题：确认数据库的配置和版本符合 Seata 的要求，并且开启了 Binlog。

• 资源管理器的兼容性问题：确保所使用的资源管理器与 Seata 兼容，并正确实现了事务的回滚操作。

如果以上方法都无法解决问题，建议咨询 Seata 官方论坛或提交 GitHub Issue 寻求进一步的技术支持。

不会先对一回滚，会先回滚二，因为回滚是倒序的。https://github.com/seata/seata/issues/5666 此回答整理自钉群“Seata(分布式事务)”

查看回滚失败错误信息，查找问题修改