潍坊市建设监理协会网站,电子商务网站建设与管理 教案,网站开发阶段流程,网站开发使用的工具类1、了解事务吗#xff0c;MySQL中事务的隔离级别有哪些#xff1f; 读未提交#xff1a;一个事务还没提交时#xff0c;它做的变更就能被别的事务看到。读已提交#xff1a;一个事务提交之后#xff0c;它做的变更才能被其他事务看到。可重复读#xff1a;一个事务执行过… 1、了解事务吗MySQL中事务的隔离级别有哪些 读未提交一个事务还没提交时它做的变更就能被别的事务看到。读已提交一个事务提交之后它做的变更才能被其他事务看到。可重复读一个事务执行过程中看到的数据总是和这个事务启动时看到的数据是一致的。串行化对于同一条记录写会加写锁读也会加读锁当出现读写锁冲突时后访问的事务必须等前一个事务执行完成才能继续执行。 针对不同的隔离级别并行事务下可能出现的问题会不一样。 读未提交可能会发生脏读、不可重复读和幻读现象。读提交可能会发生脏读和不可重复度。可重复读可能会发生幻读现象。串行化这些现象都不会发生。 2、MySQL中默认的隔离级别是什么你们在生产环境中一般使用什么隔离级别为什么 MySQL中默认的隔离级别是可重复读。 主要有一些历史的原因主从复制是基于bin log进行复制的在bin log中存在三种格式 statement记录修改SQL语句row记录每行实际数据的变更mixedstatement和row模式的混合 在MySQL5.0之前binlog只支持statement这种格式而在读提交这个隔离级别下主从复制存在bug因此才使用可重复读作为默认的隔离级别。 一般公司中使用的隔离级别是读提交。 主要是为了提高并发和降低死锁的概率。为了解决幻读的问题可重复读比读提交多了间隙锁gap lock和临键锁next-key lock。在读提交中修改数据仅使用行锁锁定的范围更小在高并发的情况下相对性能更好一点。并且在读提交的隔离级别相下发生死锁的几率会比可重复读的隔离级别下低很多。 3、MySQL中是如何实现事务的 MySQL 主要是通过锁、Redo Log 、Undo Log、MVCC 来实现事务。 MySQL 利用锁行锁、间隙锁等等机制使用数据并发修改的控制满足事务的隔离性。 redo logInnoDB在执行事务的过程中将事务的修改操作都会记录在redo log中用于保证事务的持久性。在redo log中主要记录事务对数据的修改行、列以及修改前后的值在事务提交时会将redo log写入磁盘保证数据持久性。undo log回滚日志它会记录事务的反向操作简单地说就是保存数据的历史版本用于事务的回滚。MVCCInnoDB实现了多版本并发控制MVCC用于支持事务的隔离性。在每个版本中通过事务idrow trx_id表示该版本的生命周期在事务执行过程中根据当前事务的隔离级别来确定可见的数据版本保证事务之间的隔离。锁InnoDB通过共享锁和排它锁保证数据的一致性和隔离性。共享锁用于读操作多个事务可以同时持有排他锁用于写操作在同一时间只有一个事务持有。在事务执行过程中根据需要自动加锁和解锁保证数据的一致性和隔离性。 在InnoDB中一旦事务被提交就会将修改操作写入磁盘并且释放所有的锁。如果事务发生异常或者被回滚将回滚修改的数据并释放所有的锁。 4、MySQL中长事务可能会导致哪些问题 1、长时间持有锁 长事务会持有数据库锁很长时间可能导致其他事务无法访问被锁锁定的数据严重时会导致锁竞争或死锁。这会导致其他事务的操作被阻塞降低系统的并发性能、以及数据库的吞吐量。 2、增加死锁风险 长事务在执行过程中可能涉及多个数据的锁定高并发下可能互相等待形成死锁。这也就导致事务无法完成需要回滚死锁的检查和处理不仅消耗额外的资源还难以预测。回滚过程需要撤销大量数据修改可能会导致撤销日志的写入和磁盘I/O操作急剧增加。 3、数据一致性的问题 在事务执行期间如果其他事务修改了相同数据长事务的提交可能会导致数据冲突或丢失。 4、内存使用过高 长事务会占用更多的内存需要保留大量的撤销日志和未提交的数据。MySQL消耗大大增加可能导致操作系统内存回收机制频繁触发影响整体性能。 5、导致主从延迟 在主从复制的环境中长事务可能会导致主从复制的延迟服务器需要等待主服务器上的长事务完成才能进行数据同步。 6、导致InnoDB表空间碎片 长事务在批量数据修改的过程中InnoDB会在更新时发生页拆分或页合并导致磁盘空间碎片化降低磁盘I/O性能还会增加不必要的存储开销增加维护成本。 在项目开发过程中应尽量避免长事务合理设计事务、控制事务执行时间和分批提交等方式减少长事务带来的负面影响。 5、MySQL事务的二阶段提交了解吗 二阶段提交2PC是分布式事务中一种协调协议用于确保多个资源在事务提交时保持一致性。MySQL在存储引擎和Binlog之间使用二阶段提交来保证事务的一致性。 二阶段提交的流程 1、准备阶段 MySQL将事务的修改写入redo log将redo log标记为prepare状态此时数据实际修改还未提交事务处于“可恢复”状态可以通过redo log恢复未完成的事务如果发生异常可以回滚 2、提交阶段 MySQL将事务写入binlog记录事务的持久性变更用于主从复制确保binlog写入成功更新redo log的状态为committed事务正式提交数据对其他事务可见 二阶段提交的作用 保证一致性确保InnoDB的事务日志和binlog之间的一致性。如果binlog写入失败可以通过回滚撤销未完成的事务主从复制的一致性binlog用于主从复制。如果没有二阶段提交可能会导致主库和从库数据不一致。崩溃恢复如果在事务提交中途崩溃redo log的prepared 状态可以帮助事务在恢复时判断是提交还是回滚。