面试题答案
一键面试1. MVCC在不同隔离级别下实现机制的差异
- Read Committed（读提交）：
- 版本可见性判断：事务在读取数据时，只能看到已经提交的事务所做的修改。它读取的每行数据的版本是当前事务开始之前，该行数据的最新已提交版本。也就是说，每次执行查询语句时，都会重新确定数据的版本。例如，若事务A在执行查询语句前，事务B对某数据进行了提交修改，那么事务A的查询就能看到事务B修改后的版本。
- undo log使用：undo log 记录数据修改前的版本，用于MVCC实现版本链追溯。在该隔离级别下，事务每次读取数据时，会从undo log中获取符合可见性规则的版本，保证读取到已提交的最新数据。
- Repeatable Read（可重复读）：
- 版本可见性判断：事务在开始时，会为整个事务生成一个一致性视图（snapshot）。在事务执行期间，无论执行多少次相同的查询，都基于这个一致性视图来读取数据。即使其他事务在此期间提交了对数据的修改，本事务也看不到这些新提交的修改，而是始终看到事务开始时的数据状态。例如，事务A开始时读取了某数据，在事务执行过程中，事务B修改并提交了该数据，事务A再次读取时，仍然是开始时读到的数据版本。
- undo log使用：同样依靠undo log 构建版本链。不过，可重复读隔离级别下，事务一旦生成一致性视图，后续读取都以该视图为依据从版本链获取数据，不受其他事务提交影响。
2. 对并发事务处理的不同影响
- Read Committed：
- 优点：能保证事务读取到最新已提交的数据，减少了数据的不可见性，避免了脏读问题。在一些对数据实时性要求较高的场景下，如银行账户余额查询等，可及时获取最新数据。
- 缺点：可能出现不可重复读问题。由于每次查询都获取最新已提交版本，在同一个事务内多次读取相同数据时，可能因为其他事务的提交修改而得到不同结果。同时，也可能出现幻读问题，当事务在执行范围查询时，其他事务在此范围内插入新数据并提交，本事务再次执行相同范围查询时会得到不同结果。
- Repeatable Read：
- 优点：避免了不可重复读和脏读问题。在需要事务内多次读取数据保持一致性的场景，如订单处理过程中多次读取订单信息进行计算等，能保证数据一致性。
- 缺点：由于事务执行期间始终读取开始时的一致性视图，可能导致数据的滞后性。例如，在长事务中，其他事务对数据的更新可能无法及时被本事务感知，在一些对数据实时性要求极高的场景可能不适用。同时，在MySQL InnoDB引擎中，虽然通过Next - Key Lock机制基本解决了幻读问题，但相比读提交隔离级别，并发性能会有所下降。
3. 高并发场景下隔离级别的选择与性能优化
- 选择合适的隔离级别：
- 读多写少场景：
- 如果对数据实时性要求不高，可选择Repeatable Read隔离级别。例如，电商系统中的商品浏览页面，用户频繁读取商品信息，而商品信息修改频率相对较低。使用可重复读隔离级别可保证用户在浏览商品过程中数据的一致性，避免不可重复读问题，且可通过MVCC减少锁竞争，提高并发性能。
- 若对数据实时性要求较高，Read Committed更合适。比如股票交易系统，用户需要获取最新的股票价格信息，读提交隔离级别能保证每次读取到最新已提交的价格数据。
- 读写均衡场景：需综合考虑数据一致性和并发性能。如果业务允许一定程度的不可重复读，但要避免脏读，Read Committed可作为选择。若业务对事务内数据一致性要求严格，如金融转账业务，必须保证在整个转账事务内读取的账户余额等数据一致，则应选择Repeatable Read。
- 写多读少场景：由于写操作可能导致锁竞争，可考虑适当降低隔离级别以提高并发性能。但如果数据一致性要求极高，如银行核心账务系统，即使写操作多，也应选择Repeatable Read，通过合理的锁优化等手段来提升性能。
- 读多写少场景：
- 利用MVCC特性优化性能：
- 减少锁竞争：MVCC允许事务在读取数据时不需要获取排他锁，从而降低锁竞争的概率。无论是读提交还是可重复读隔离级别，都利用MVCC实现了读写并发。例如，在高并发读场景下，多个事务可同时读取不同版本的数据，而不会因为写操作的排他锁而阻塞读操作。
- 合理设置事务大小：在Repeatable Read隔离级别下，长事务会一直持有一致性视图，可能导致数据版本长时间不能被清理，占用过多undo log空间。因此，应尽量将大事务拆分成小事务，减少事务的执行时间，及时释放资源，提高系统整体性能。
- 优化查询语句：在高并发场景下，复杂的查询语句可能会影响性能。应尽量避免全表扫描等操作，利用索引来快速定位数据。同时，在使用MVCC时，查询条件应能充分利用版本链的特性，减少不必要的版本回溯，提高查询效率。