mysql隔离级别面试,mysql事务隔离级别

mysql隔离级别面试,mysql事务隔离级别详细介绍

本文目录一览： 程序员面试宝典之Mysql数据库Innodb引擎的4个隔离级别

题目：请阐述Mysql Innodb引擎的4个隔离级别

难度：三星

面试频率：五星

这道题真的是一道数据库的高频题，数据库题除了索引的原理之外就是这道题的面试频率最高。

1.Read uncommitted（读未提交）：，最低的隔离级别，可以一个事务读到其他事务没有提交的数据，也称脏读，这个隔离级别很少人用

2.Read committed（读已提交）：相比于读未提交，这个隔离级别只能读到其他事物已经提交了的数据，这个隔离级别用得比较多。但是不是Mysql默认的隔离级别

3.Repeatable read（可重复读）： 在读已提交隔离级别中，2次读取同一个变量如果其他事务修改了它的值，会读到的不一样。而在这个隔离级别中，顾名思义，一个事务开始读了。多次读到的值可以保证是一样的

4.Serializable 序列化 在这个隔离级别下，所有的事务都将串行操作，是隔离级别最高的也是效率最低的，很少人用

面试官追问：Innodb引擎默认隔离级别是哪个

答：可重复读

面试官追问：可重复读的实现原理

答：使用了MVCC多版本控制（类似乐观锁），Innodb引擎会给每一行数据加一个版本号信息，当一个事务修改一个数据时会增加它的版本号+1，当一个事务开始的时候会缓存下此时的版本号，后面读取的时候只会读取这个版本号的数据，因此别的事务提交了修改数据的版本号大于它，因此不会被读到

面试官追问：事务的隔离级别如何设置：

答：在Mysql命令行下调用命令 set global.tx_isolation，但这样Mysql重启失效，修改my.cnf来永久设置

面试官追问：可重读读有什么问题

答：会出现幻读，幻读是指事务读取到一个值无法准确继续后续操作。例如读取一个值，没有则插入，但是等插入的时候其他事务已经插入了，这就会导致插入失败，解决办法：sql语句显示加锁 ：select xxxx for update,其他事务修改数据则会阻塞

「春招系列」MySQL面试核心25问（附答案）

篇幅所限本文只写了MySQL25题，像其他的Redis，SSM框架，算法，计网等技术栈的面试题后面会持续更新，个人整理的1000余道面试八股文会放在文末给大家白嫖，最近有面试需要刷题的同学可以直接翻到文末领取。
如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置， 频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE（optimize table）来重建表并优化填充页面。
Server层按顺序执行sql的步骤为：
简单概括：
可以分为服务层和存储引擎层两部分，其中：
服务层包括连接器、查询缓存、分析器、优化器、执行器等 ，涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。
存储引擎层负责数据的存储和提取 。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了默认的存储引擎。
Drop、Delete、Truncate都表示删除，但是三者有一些差别：
Delete 用来删除表的全部或者一部分数据行，执行Delete之后，用户需要提交(commmit)或者回滚(rollback)来执行删除或者撤销删除，会触发这个表上所有的delete触发器。
Truncate 删除表中的所有数据，这个操作不能回滚，也不会触发这个表上的触发器，TRUNCATE比Delete更快，占用的空间更小。
Drop 命令从数据库中删除表，所有的数据行，索引和权限也会被删除，所有的DML触发器也不会被触发，这个命令也不能回滚。
因此，在不再需要一张表的时候，用Drop；在想删除部分数据行时候，用Delete；在保留表而删除所有数据的时候用Truncate。
隔离级别脏读不可重复读幻影读 READ-UNCOMMITTED 未提交读 READ-COMMITTED 提交读 REPEATABLE-READ 重复读 SERIALIZABLE 可串行化读
MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ （可重读）
这里需要注意的是 ：与 SQL 标准不同的地方在于InnoDB 存储引擎在 REPEATABLE-READ（可重读）事务隔离级别 下使用的是 Next-Key Lock 锁 算法，因此可以避免幻读的产生，这与其他数据库系统(如 SQL Server)是不同的。所以 说InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读） 已经可以完全保证事务的隔离性要 求，即达到了 SQL标准的SERIALIZABLE(可串行化)隔离级别。
因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是READ-COMMITTED(读取提交内 容):，但是你要知道的是InnoDB 存储引擎默认使用 REPEATABLE-READ（可重读）并不会有任何性能损失 。
InnoDB 存储引擎在分布式事务 的情况下一般会用到SERIALIZABLE(可串行化)隔离级别。
主要原因：B+树只要遍历叶子节点就可以实现整棵树的遍历，而且在数据库中基于范围的查询是非常频繁的，而B树只能中序遍历所有节点，效率太低。
文件与数据库都是需要较大的存储，也就是说，它们都不可能全部存储在内存中，故需要存储到磁盘上。而所谓索引，则为了数据的快速定位与查找，那么索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数，因此B+树相比B树更为合适。数据库系统巧妙利用了局部性原理与磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入，而红黑树这种结构，高度明显要深的多，并且由于逻辑上很近的节点(父子)物理上可能很远，无法利用局部性。
最重要的是，B+树还有一个最大的好处：方便扫库。
B树必须用中序遍历的方法按序扫库，而B+树直接从叶子结点挨个扫一遍就完了，B+树支持range-query非常方便，而B树不支持，这是数据库选用B+树的最主要原因。
B+树查找效率更加稳定，B树有可能在中间节点找到数据，稳定性不够。
B+tree的磁盘读写代价更低：B+tree的内部结点并没有指向关键字具体信息的指针(红色部分)，因此其内部结点相对B 树更小。如果把所有同一内部结点的关键字存放在同一块盘中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多，相对来说IO读写次数也就降低了；
B+tree的查询效率更加稳定：由于内部结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引，所以，任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当；
视图是一种虚拟的表，通常是有一个表或者多个表的行或列的子集，具有和物理表相同的功能 游标是对查询出来的结果集作为一个单元来有效的处理。一般不使用游标，但是需要逐条处理数据的时候，游标显得十分重要。
而在 MySQL 中，恢复机制是通过回滚日志（undo log）实现的，所有事务进行的修改都会先记录到这个回滚日志中，然后在对数据库中的对应行进行写入。当事务已经被提交之后，就无法再次回滚了。
回滚日志作用：1)能够在发生错误或者用户执行 ROLLBACK 时提供回滚相关的信息 2) 在整个系统发生崩溃、数据库进程直接被杀死后，当用户再次启动数据库进程时，还能够立刻通过查询回滚日志将之前未完成的事务进行回滚，这也就需要回滚日志必须先于数据持久化到磁盘上，是我们需要先写日志后写数据库的主要原因。
InnoDB
MyISAM
总结
数据库并发会带来脏读、幻读、丢弃更改、不可重复读这四个常见问题，其中：
脏读 ：在第一个修改事务和读取事务进行的时候，读取事务读到的数据为100，这是修改之后的数据，但是之后该事务满足一致性等特性而做了回滚操作，那么读取事务得到的结果就是脏数据了。
幻读 ：一般是T1在某个范围内进行修改操作（增加或者删除），而T2读取该范围导致读到的数据是修改之间的了，强调范围。
丢弃修改 ：两个写事务T1 T2同时对A=0进行递增操作，结果T2覆盖T1，导致最终结果是1 而不是2，事务被覆盖
不可重复读 ：T2 读取一个数据，然后T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。
第一个事务首先读取var变量为50，接着准备更新为100的时，并未提交，第二个事务已经读取var为100，此时第一个事务做了回滚。最终第二个事务读取的var和数据库的var不一样。
T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。
T1 和 T2 两个事务都对一个数据进行修改，T1 先修改，T2 随后修改，T2 的修改覆盖了 T1 的修改。例如：事务1读取某表中的数据A=50，事务2也读取A=50，事务1修改A=A+50，事务2也修改A=A+50，最终结果A=100，事务1的修改被丢失。
T2 读取一个数据，T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。
悲观锁，先获取锁，再进行业务操作，一般就是利用类似 SELECT … FOR UPDATE 这样的语句，对数据加锁，避免其他事务意外修改数据。当数据库执行SELECT … FOR UPDATE时会获取被select中的数据行的行锁，select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。
乐观锁，先进行业务操作，只在最后实际更新数据时进行检查数据是否被更新过。Java 并发包中的 AtomicFieldUpdater 类似，也是利用 CAS 机制，并不会对数据加锁，而是通过对比数据的时间戳或者版本号，来实现乐观锁需要的版本判断。
分库与分表的目的在于，减小数据库的单库单表负担，提高查询性能，缩短查询时间。
通过分表 ，可以减少数据库的单表负担，将压力分散到不同的表上，同时因为不同的表上的数据量少了，起到提高查询性能，缩短查询时间的作用，此外，可以很大的缓解表锁的问题。分表策略可以归纳为垂直拆分和水平拆分:
水平分表 ：取模分表就属于随机分表，而时间维度分表则属于连续分表。如何设计好垂直拆分，我的建议：将不常用的字段单独拆分到另外一张扩展表. 将大文本的字段单独拆分到另外一张扩展表, 将不经常修改的字段放在同一张表中，将经常改变的字段放在另一张表中。对于海量用户场景，可以考虑取模分表，数据相对比较均匀，不容易出现热点和并发访问的瓶颈。
库内分表 ，仅仅是解决了单表数据过大的问题，但并没有把单表的数据分散到不同的物理机上，因此并不能减轻 MySQL 服务器的压力，仍然存在同一个物理机上的资源竞争和瓶颈，包括 CPU、内存、磁盘 IO、网络带宽等。
分库与分表带来的分布式困境与应对之策 数据迁移与扩容问题----一般做法是通过程序先读出数据，然后按照指定的分表策略再将数据写入到各个分表中。分页与排序问题----需要在不同的分表中将数据进行排序并返回，并将不同分表返回的结果集进行汇总和再次排序，最后再返回给用户。
不可重复读的重点是修改，幻读的重点在于新增或者删除。
视图是虚拟的表，与包含数据的表不一样，视图只包含使用时动态检索数据的查询；不包含任何列或数据。使用视图可以简化复杂的 sql 操作，隐藏具体的细节，保护数据；视图创建后，可以使用与表相同的方式利用它们。
视图不能被索引，也不能有关联的触发器或默认值，如果视图本身内有order by 则对视图再次order by将被覆盖。
创建视图：create view xxx as xxxx
对于某些视图比如未使用联结子查询分组聚集函数Distinct Union等，是可以对其更新的，对视图的更新将对基表进行更新；但是视图主要用于简化检索，保护数据，并不用于更新，而且大部分视图都不可以更新。
B+tree的磁盘读写代价更低，B+tree的查询效率更加稳定 数据库索引采用B+树而不是B树的主要原因：B+树只要遍历叶子节点就可以实现整棵树的遍历，而且在数据库中基于范围的查询是非常频繁的，而B树只能中序遍历所有节点，效率太低。
B+树的特点
在最频繁使用的、用以缩小查询范围的字段,需要排序的字段上建立索引。不宜：1）对于查询中很少涉及的列或者重复值比较多的列 2）对于一些特殊的数据类型，不宜建立索引，比如文本字段（text）等。
如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称 之为“覆盖索引”。
我们知道在InnoDB存储引 擎中，如果不是主键索引，叶子节点存储的是主键+列值。最终还是要“回表”，也就是要通过主键再查找一次,这样就 会比较慢。覆盖索引就是把要查询出的列和索引是对应的，不做回表操作！
举例 ：
学号姓名性别年龄系别专业 20020612李辉男20计算机软件开发 20060613张明男18计算机软件开发 20060614王小玉女19物理力学 20060615李淑华女17生物动物学 20060616赵静男21化学食品化学 20060617赵静女20生物植物学
主键为候选键的子集，候选键为超键的子集，而外键的确定是相对于主键的。

mysql事务隔离级别

mysql事务隔离级别如下：
1.读取未提交（READ-UNCOMMITTED）：最低的隔离级别，允许读取尚未提交的数据变更，可能造成脏读、不可重复读、幻读。
2.读取已提交（READ-COMMITTED）：允许读取并发事务已经提交的数据，可以避免脏读，但是可能造成不可重复、幻读。
3.可重复读（REPEATABLE-READ）：对同一字段多次读取的结果都是一致的，除非本身事务修改，可以避免脏读和不可重复读，但是可能造成幻读。
4.可串行化（SERIALIZABLE）：最高的隔离级别，完全服从ACID的隔离级别，所以的事务依次执行，可以避免脏读、不可重复读、幻读。
事务的特性：
1.原子性：事务最小的执行单位，不允许分割。事务的原子性确保动作要么全部执行，要么全部不执行。
2.一致性：执行事务的前后，数据保持一致。例如转账的业务中，无论事务是否成功，转账者和收款人的总额应该是不变的。
3.隔离性：并发访问数据库时，一个用户的事务不应该被其他事务所影响，各并发事务之间数据库是独立的。
4.持久性：一个事务被提交后，它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有影响。

mysql有几种隔离级别

mysql有4种隔离级别，分别为：读未提交内容、读取提交内容、可重复读、可串行化。Mysql的四种隔离级别SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。【视频教程推荐：Mysql教程】读未提交内容（read-uncommitted）在该隔离级别中，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。该隔离级别会出现的问题是：脏读(Dirty Read)，即读取到了未提交的数据。读取提交内容（read-committed）这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。该隔离级别会出现的问题是：不可重复读(Nonrepeatable Read)，即不可重复读意味着我们在同一个事务中执行完全相同的select语句时可能看到不一样的结果。导致这种情况的原因可能有：1)、有一个交叉的事务有新的commit，导致了数据的改变;2)、一个数据库被多个实例操作时,同一事务的其他实例在该实例处理其间可能会有新的commit可重复读（repeatable-read）这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。可串行化（serializable）这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。在这个级别，可能导致大量的超时现象和锁竞争。

MySQL的默认事务隔离级别是(mysql的隔离级别)

mysql的4种事务隔离级别，如下所示：
1、未提交读(ReadUncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据。
2、提交读(ReadCommitted)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别(不重复读)。
3、可重复读(RepeatedRead)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读，但是innoDB解决了幻读。
4、串行读()：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。
相关简介
MySQL是一个关系型数据库管理系统，由瑞典MySQLAB公司开发，属于Oracle旗下产品。MySQL是最流行的关系型数据库管理系统之一，在WEB应用方面，MySQL是最好的RDBMS(RelationalDatabaseManagementSystem，关系数据库管理系统)应用软件之一。
MySQL是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。
MySQL所使用的SQL语言是用于访问数据库的最常用标准化语言。MySQL软件采用了双授权政策，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择MySQL作为网站数据库。

mysql的隔离级别是如何实现的

隔离级别（推荐教程：mysql教程）数据库事务的隔离级别有4个，由低到高依次为Read uncommitted(读未提交)、Read committed（读提交）、Repeatable read（可重复读取）、Serializable（可串行化），这四个级别可以逐个解决脏读、不可重复读、幻象读这几类问题。隔离级别的实现：未提交读（RU：read-uncommitted）：在RU级别中，事务读到的所有数据都是最新的数据，可能是事务提交后的数据，也可能是事务执行中的数据（可能会被回滚）。当隔离级别为RU时：所有的读不加锁，读到的数据都是最新的数据，性能最好。所有的写加行级锁，写完释放。提交读（RC：read-committed）：使用MVCC技术，在每一行加入隐藏的字段（DB_TRX_ID：修改该行的最后一个事务的id，DB_ROLL_PTR：指向当前行的undo log日志，DB_ROW_ID：行标识，DELETE_BIT：删除标志），它实现了不加锁的读操作。当隔离级别为RC时：写操作：加行级锁。事务开始后，会在UNDO日志中写入修改记录，数据行中的隐藏列DATA_POLL_PTR存储指向该行的UNDO记录的指针。读操作：不加锁。在读取时，如果该行被其它事务锁定，则顺着隐藏列DATA_POLL_PTR指针，找到上一个有效的历史记录（有效的记录：该记录对当前事务可见，且DELETE_BIT=0）。可重复读（RR：repeatable-read）：使用MVCC技术来实现不加锁的读操作。当隔离级别为RR时：写操作：加行级锁。事务开始后，会在UNDO日志中写入修改记录，数据行中的隐藏列DATA_POLL_PTR存储指向该行的UNDO记录的指针。读操作：不加锁。在读取时，如果该行被其它事务锁定，则顺着隐藏列DATA_POLL_PTR指针，找到上一个有效的历史记录（有效的记录：该记录对当前事务可见，且DELETE_BIT=0）。从上面可以知道：实际上RC和RR级别的操作基本相同，而不同之处在于：行记录对于当前事务的可见性（可见性：即哪个版本的行记录对这个事务是可见的）。RC级别对数据的可见性是该数据的最新记录，RR基本对数据的可见性是事务开始时，该数据的记录。（1）行记录的可见性（read_view）的实现在innodb中，创建一个事务的时候，会将当前系统中的活跃事务列表创建一个副本（read_view），里面存储着的都是在当前事务开始时，还没commit的事务，这些事务里的值对当前事务不可见。read_view中有两个关键值 up_limit_id（当前未提交事务的最小版本号-1，在up_limit_id之前的事务都已经提交，在up_limit_id之后的事务可能提交，可能还没提交） 和 low_limit_id（当前系统尚未分配的下一个事务id，也就是目前已出现过的事务id的最大值+1。注意：low_limit_id不是最大的活跃事务的id。）注意：当前事务和正在commit的事务是不在read_view中的。（2）无论是RC级别还是RR级别，其判断行记录的可见性的逻辑是一样的。当该事务要读取undo中的行记录时，会将行记录的版本号（DB_TRX_ID）与read_view进行比较：1、如果DB_TRX_ID小于up_limit_id，表示该行记录在当前事务开始前就已经提交了，并且DELETE_BIT=0，则该行记录对当前事务是可见的。2、如果DB_TRX_ID大于low_limit_id，表示该行记录在所在的事务在本次事务创建后才启动的，所以该行记录的当前值不可见。3、如果up_limit_id< = DB_TRX_ID <= low_limit_id，判断DB_TRX_ID是否在活跃事务链中，如果在就是不可见，如果不在就是可见的。4、如果上面判断都是不可见的，则读取undo中该行记录的上一条行记录，继续进行判断。而对于RC级别的语句级快照和RR级别的事务级快照的之间的区别，其实是由read_view生成的时机来实现的。RC级别在执行语句时，会先关闭原来的read_view，重新生成新的read_view。而RR级别的read_view则只在事务开始时创建的。所以RU级别每次获取到的都是最新的数据，而RR级别获取到的是事务开始时的数据。（3）值得注意的是： 在上面的可见性判断中，虽然逻辑是一样的，但是实际意义上是有区别的：在第二步中，对于RC级别来说，low_limit_id是执行语句时已出现的最大事务id+1，可以认为在执行语句时，是不存在事务会比low_limit_id要大，所以大于low_limit_id的事务都是不可见的。而对于RR级别来说，low_limit_id是当前事务开始时已出现的最大事务+1（也可以认为是当前事务的id+1，因为在创建当前事务时，当前事务的id最大），大于low_limit_id的事务表示是在该事务开始后创建的，所以对RR级别是不可见。在第三步中，对于RC级别来说，只要DB_TRX_ID不在活跃链表中，则无论DB_TRX_ID是否大于事务id，RC都是可见的。而对于RR级别来说，因为low_limit_id就是当前事务id+1，可以认为小于low_limit_id的事务都是在当前事务创建前出现的，所以也只需要简单判断DB_TRX_ID是否在活跃链表中。串行化（serializable）：读写都会加锁

mysql默认隔离级别

repeatable。数据库默认隔离级别:mysql——>repeatable。oracle，sqlserver——>readcommited。MySQL是一个关系型数据库管理系统，由瑞典MySQLAB公司开发，目前属于Oracle旗下产品。MySQL是最流行的关系型数据库管理系统之一，在WEB应用方面，MySQL是最好的RDBMS(RelationalDatabaseManagementSystem，关系数据库管理系统)应用软件之一。关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。MySQL所使用的SQL语言是用于访问数据库的最常用标准化语言。MySQL软件采用了双授权政策，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择MySQL作为网站数据库。由于其社区版的性能卓越，搭配PHP和Apache可组成良好的开发环境。

【转】互联网项目中mysql应该选什么事务隔离级别

输出如下+---+| b |+---+| 3 |+---+1 row in set但是，你在此时在从(slave)上执行该语句，得出输出如下Empty set这样，你就出现了主从不一致性的问题！原因其实很简单，就是在master上执行的顺序为先删后插！而此时binlog为STATEMENT格式，它记录的顺序为先插后删！从(slave)同步的是binglog，因此从机执行的顺序和主机不一致！就会出现主从不一致！如何解决？解决方案有两种！(1)隔离级别设为可重复读(Repeatable Read),在该隔离级别下引入间隙锁。当Session 1执行delete语句时，会锁住间隙。那么，Ssession 2执行插入语句就会阻塞住！(2)将binglog的格式修改为row格式，此时是基于行的复制，自然就不会出现sql执行顺序不一样的问题！奈何这个格式在mysql5.1版本开始才引入。因此由于历史原因，mysql将默认的隔离级别设为可重复读(Repeatable Read)，保证主从复制不出问题！那么，当我们了解完mysql选可重复读(Repeatable Read)作为默认隔离级别的原因后，接下来我们将其和读已提交(Read Commited)进行对比，来说明为什么在互联网项目为什么将隔离级别设为读已提交(Read Commited)！对比ok，我们先明白一点！项目中是不用读未提交(Read UnCommitted)和串行化(Serializable)两个隔离级别，原因有二采用读未提交(Read UnCommitted),一个事务读到另一个事务未提交读数据，这个不用多说吧，从逻辑上都说不过去！采用串行化(Serializable)，每个次读操作都会加锁，快照读失效，一般是使用mysql自带分布式事务功能时才使用该隔离级别！(笔者从未用过mysql自带的这个功能，因为这是XA事务，是强一致性事务，性能不佳！互联网的分布式方案，多采用最终一致性的事务解决方案！)也就是说，我们该纠结都只有一个问题，究竟隔离级别是用读已经提交呢还是可重复读？接下来对这两种级别进行对比，讲讲我们为什么选读已提交(Read Commited)作为事务隔离级别！假设表结构如下 CREATE TABLE `test` (`id` int(11) NOT NULL,`color` varchar(20) NOT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB数据如下+----+-------+| id | color |+----+-------+| 1 | red || 2 | white || 5 | red || 7 | white |+----+-------+为了便于描述，下面将可重复读(Repeatable Read)，简称为RR；读已提交(Read Commited)，简称为RC；缘由一：在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多！此时执行语句select * from test where id <3 for update;在RR隔离级别下，存在间隙锁，可以锁住(2,5)这个间隙，防止其他事务插入数据！而在RC隔离级别下，不存在间隙锁，其他事务是可以插入数据！ps:在RC隔离级别下并不是不会出现死锁，只是出现几率比RR低而已！缘由二：在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行此时执行语句update test set color = ‘blue‘ where color = ‘white‘; 在RC隔离级别下，其先走聚簇索引，进行全部扫描。加锁如下：但在实际中，MySQL做了优化，在MySQL Server过滤条件，发现不满足后，会调用unlock_row方法，把不满足条件的记录放锁。实际加锁如下然而，在RR隔离级别下，走聚簇索引，进行全部扫描，最后会将整个表锁上，如下所示缘由三：在RC隔离级别下，半一致性读(semi-consistent)特性增加了update操作的并发性！在5.1.15的时候，innodb引入了一个概念叫做“semi-consistent”，减少了更新同一行记录时的冲突，减少锁等待。所谓半一致性读就是，一个update语句，如果读到一行已经加锁的记录，此时InnoDB返回记录最近提交的版本，由MySQL上层判断此版本是否满足update的where条件。若满足(需要更新)，则MySQL会重新发起一次读操作，此时会读取行的最新版本(并加锁)！具体表现如下:此时有两个Session，Session1和Session2！Session1执行update test set color = ‘blue‘ where color = ‘red‘; 先不Commit事务！与此同时Ssession2执行update test set color = ‘blue‘ where color = ‘white‘; session 2尝试加锁的时候，发现行上已经存在锁，InnoDB会开启semi-consistent read，返回最新的committed版本(1,red),(2，white),(5,red),(7,white)。MySQL会重新发起一次读操作，此时会读取行的最新版本(并加锁)!而在RR隔离级别下，Session2只能等待！两个疑问在RC级别下，不可重复读问题需要解决么？不用解决，这个问题是可以接受的！毕竟你数据都已经提交了，读出来本身就没有太大问题！Oracle的默认隔离级别就是RC，你们改过Oracle的默认隔离级别么？在RC级别下，主从复制用什么binlog格式？OK,在该隔离级别下，用的binlog为row格式，是基于行的复制！Innodb的创始人也是建议binlog使用该格式！总结本文_里八嗦了一篇文章只是为了说明一件事，互联网项目请用：读已提交(Read Commited)这个隔离级别！【转】互联网项目中mysql应该选什么事务隔离级别标签：主从简单重复div提交阅读就是imagebug

mysql怎么设置事物隔离级别

隔离级别事务的隔离级别分为：未提交读(read uncommitted)、已提交读(read committed)、可重复读(repeatable read)、串行化(serializable)。（视频教程推荐：mysql视频教程）未提交读A事务已执行，但未提交；B事务查询到A事务的更新后数据；A事务回滚；---出现脏数据已提交读A事务执行更新；B事务查询；A事务又执行更新；B事务再次查询时，前后两次数据不一致；---不可重复读可重复读A事务无论执行多少次，只要不提交，B事务查询值都不变；B事务仅查询B事务开始时那一瞬间的数据快照；串行化不允许读写并发操作，写执行时，读必须等待；（相关教程推荐：mysql教程）具体命令：//设置mysql的隔离级别：set session transaction isolation level 事务隔离级别//设置read uncommitted级别：set session transaction isolation level read uncommitted;//设置read committed级别：set session transaction isolation level read committed;//设置repeatable read级别：set session transaction isolation level repeatable read;//设置serializable级别：set session transaction isolation level serializable;

MySQL 事务的默认隔离级别是什么？可以解决幻读问题么？

我们设想一个场景，这个场景中我们需要插入多条相关联的数据到数据库，不幸的是，这个过程可能会遇到下面这些问题：
上面的任何一个问题都可能会导致数据的不一致性。为了保证数据的一致性，系统必须能够处理这些问题。事务就是我们抽象出来简化这些问题的首选机制。事务的概念起源于数据库，目前，已经成为一个比较广泛的概念。
何为事务？ 一言蔽之， 事务是逻辑上的一组操作，要么都执行，要么都不执行。
事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账 1000 元，这个转账会涉及到两个关键操作，这两个操作必须都成功或者都失败。
事务会把这两个操作就可以看成逻辑上的一个整体，这个整体包含的操作要么都成功，要么都要失败。这样就不会出现小明余额减少而小红的余额却并没有增加的情况。
大多数情况下，我们在谈论事务的时候，如果没有特指 分布式事务 ，往往指的就是 数据库事务 。
数据库事务在我们日常开发中接触的最多了。如果你的项目属于单体架构的话，你接触到的往往就是数据库事务了。
那数据库事务有什么作用呢？
简单来说，数据库事务可以保证多个对数据库的操作（也就是 SQL 语句）构成一个逻辑上的整体。构成这个逻辑上的整体的这些数据库操作遵循： 要么全部执行成功,要么全部不执行 。
另外，关系型数据库（例如： MySQL 、 SQL Server 、 Oracle 等）事务都有 ACID 特性：
ACID
这里要额外补充一点： 只有保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。也就是说 A、I、D 是手段，C 是目的！
在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务（多个用户对同一数据进行操作）。并发虽然是必须的，但可能会导致以下的问题。
不可重复读和幻读区别 ：不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改，幻读的重点在于新增或者删除比如多次查询同一条查询语句（DQL）时，记录发现记录增多或减少了。
SQL 标准定义了四个隔离级别：
隔离级别脏读不可重复读幻读 READ-UNCOMMITTED READ-COMMITTED REPEATABLE-READ SERIALIZABLE
MySQL 的隔离级别基于锁和 MVCC 机制共同实现的。
SERIALIZABLE 隔离级别，是通过锁来实现的。除了 SERIALIZABLE 隔离级别，其他的隔离级别都是基于 MVCC 实现。
不过， SERIALIZABLE 之外的其他隔离级别可能也需要用到锁机制，就比如 REPEATABLE-READ 在当前读情况下需要使用加锁读来保证不会出现幻读。
MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读） 。我们可以通过 SELECT @@tx_isolation; 命令来查看，MySQL 8.0 该命令改为 SELECT @@transaction_isolation;
从上面对 SQL 标准定义了四个隔离级别的介绍可以看出，标准的 SQL 隔离级别定义里，REPEATABLE-READ(可重复读)是不可以防止幻读的。
但是！InnoDB 实现的 REPEATABLE-READ 隔离级别其实是可以解决幻读问题发生的，主要有下面两种情况：
因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 READ-COMMITTED ，但是你要知道的是 InnoDB 存储引擎默认使用 REPEATABLE-READ 并不会有任何性能损失。
InnoDB 存储引擎在分布式事务的情况下一般会用到 SERIALIZABLE 隔离级别。