幻读是没有办法通过业务改造来解决的。但是在业务层面上，幻读一般不会被认为是一个问题，原因有两点：一是你分不清是不是幻读。比如说你在事务 A 里面读到了一条数据，你判断不出来它是在事务 A 开始之前就插入的，还是在事务 A 开始之后，事务 B 才插入并且提交的。
二是事务提交往往意味着业务已经结束，所以读到一个已经提交的事务的数据，不会损害业务的正确性。也就是说，如果事务A在开始之后，事务B才插入数据并且提交，那么这个时候事务A完全可以认为事务B所在的整个业务已经结束了，所以读出来也没什么问题。
回答的关键词是改造业务
正常来说是不推荐使用可重复读的，因为在我们的业务环境下想不到有什么场景非得使用可重复读这个隔离级别。
之前在推动降低隔离级别的时候，其实重构过一些业务。这一类业务就是在一个事务里面发起了两个同样的查询，比如在UPDATE之后又立刻查询，这种查询还必须走主库，不然会有主从延迟的问题。
这种业务可以通过缓存第一次查询的数据来避免第二次查询。但是这种改造一般是避不开幻读的。不过在业务上幻读一般不是问题。一方面是业务层面上区分不出来是否是幻读。另外一方面，事务提交了往往代表业务已经结束，那么发生幻读了，业务依旧是正常的。比如说事务 A 读到了事务 B 新插入的数据，但是事务 B 本身已经提交了，那么事务 A 就认为事务 B 所在的业务已经完结了，那么读到了就读到了，并不会出什么问题。
兜底的手段是：指定隔离级别
万一不能改造业务，那么还有一个方法，就是直接在创建事务的时候指定隔离级别。我前面调整的都是数据库的默认隔离级别，实际上还可以在 Session 或者事务这两个维度上指定隔离级别。
