大事务的产生原因、危害及优化方案

什么情况下会产生大事务

以下操作可能会产生大事务：

1. 批处理操作：当需要一次性处理大量数据，例如数据导入、数据清理、ETL（抽取、转换、加载）过程或定期数据汇总时，通常会发生大事务。这些操作可能需要在单个事务中处理大量数据。

2. 在事务中执行了比较耗时的服务调用，如调用外部接口或者RPC服务。

3. 复杂的业务逻辑，以及一些非DB操作的计算。

4. 事务之间存在锁竞争，锁等待时间较长可能会导致事务的执行时间较长

5. 事务注解@Transactional使用不当，@Transactional是方法级别的事务控制，随着业务的迭代，方法可能会越来越复杂，此时如果还是把事务控制在方法级别上，可能会导致事务越来越长

大事务可能带来的问题

1. 锁竞争：在大事务中，多个事务可能会试图获取相同的行或表级锁，这可能导致锁竞争，降低性能并导致死锁。

2. 在大事务中，如果需要回滚，将会有更多的数据需要恢复，这可能会导致回滚成本较高。

3. 日志量增加：大事务会生成大量的日志，这可能会占用大量磁盘空间和增加恢复时间。

4. 性能问题：在大事务中，连接可能会被持续打开，这会占用数据库连接池的资源，可能导致连接池被占满。

5. 数据库主从同步延迟。

6. 死锁：事务中的DB操作越多出现死锁的可能性越大。

7. 接口超时：长时间的事务等待可能会导致接口超时。

大事务有哪些优化方案

分析了大事务可能产生的原因，及可能带来的危害，那么有什么方法可以针对大事务进行优化呢？

将不必要的查询可操作置于事务外

1.尽量不使用事务注解@Transactional，对使用编程式事务；

@Autowired

private TransactionTemplate transactionTemplate;

...

public void save(final User user) {

transactionTemplate.execute((status) => {

doSameThing...

return Boolean.TRUE;

})

}

该注解时方法级别的，难以精确控制事务的范围。最开始编写方法的时候使用可能没有问题，但是可能会随着项目的迭代方法里的逻辑越来越复杂。而且@Transactional也有可能因为使用不当使事务失效。

2.将查询(select)方法放到事务外，能放到事务外的查询尽量放到事务外部。

3.尽量在事务中避免远程调用

事务中避免一次性处理太多数据

可以化整为零，将大批次分解为小批次，将大事务分割成多个小事务。

考虑将部分操作转化为异步执行

同步操作必须等待返回，耗时较长，使用异步操作可减少等待时间