最近在数据库上经常遇到死锁问题. 表现的问题有
1. 有一个查询为:
1) 一个复杂的 select 查处一组大数据
2) 使用事务 update 这组数据的状态
为了让锁定的时间变短, 我将这整个大事务切分成了多个小事务, 也就是每次查询并更新 1W 数据变为了每次查询并更新 100 数据, 但是需要查询更新 100 次, 总数据量还是 1W
这样就造成了一个问题, 因为这个 select 是个复杂查询, 这里 100 次 select 使得整个操作时间急剧上升.
所以我认为最好的做法是, 先把 1W 数据用 select 查询出来, 然后 update 操作分组, 例如每次 update 1000, 如果这次事务 update 失败, 则将 update 失败的这些数据从 select 结果集中去掉
2. 有一个大量的结果集更新, 例如 5W 条, 原来我的做法是切分为 10 个小事务, 每次更新 5000 条, 顺序更新
实际上这里没有必要用事务, 因为我对他们没有一致性和原子性要求. 使用事务的好处是效率提高, 因为 MySQL 默认是 autocommit = true, 相当于没条语句是一个事务. 但是使用事务的缺点是 update 的锁的持有时间会加长, 容易造成死锁.
最后的解决方案是使用多线程同时执行, 并且不适用事务, 但是使用 preparedStatement (batch).
最后看看我的测试数据, 一共测试了 10W 的数据
1. 使用 batch 一次性执行完毕, 共耗费 55s
2. 使用多线程并发执行, 每个线程 batch 数量为 5000, 线程池大小是 CPU核数 * 2, 共耗费 11s
3. 不适用 batch, 但是用多线程执行, 每个线程负责 5000 数据插入, 共耗费 24s
4. 使用事务, 但是不用 batch, 使用多线程执行, 每个线程负责 5000 数据, 共耗费 14s
5. 使用事务, 同时使用 batch, 使用多线程, 每个线程 5000 数据, 共耗费 8s
可见使用事务, 同时 batch 效率最高, 但是使用事务会加长锁的持有时间, 这点需要注意
MySQL Batch 与 Transaction