锐客网

  1. 首页 > 睿知 > it技术 > >

mysql怎么保证事务 注册文化工作室要多少钱

事务IT技术

mysql 怎样保证事务不丢【mysql怎么保证事务 注册文化工作室要多少钱】 redo logbin log 是现在 mysql 常用的一种配置，在 innerdb 没有成为 mysql 的默认引擎之前 ， mysql 已经又了 binlog 这种日志格式，它在 server 层 。innerdb 有自己的 redo log 支持崩溃恢复，后面成为 mysql 的引擎过后，整个事务的过程变成一种两阶段提交的方式：
现在设想两种情况：
A.如果已经写了 redo log，redo log 处于 prepare 阶段 ， 写 binlog 之前崩溃了
答：此时 binlog 还没写，redo log 也没提交，所以崩溃恢复的时候，整个事务会回滚 。这时 binlog 还没写，如果是主从复制的架构，binlog 的数据也不会传递到备库里 。
B.如果是已经写了 binlog，但是 redo log 还没提交
答：mysql 目前的崩溃规则如下：
追问 B：处于 prepare 阶段的 redo log 加上完整的 binlog，重启就能恢复，mysql 为什么要这样设计
答：这个问题与数据与备份的一致性有关 。如果写 binlog 后 mysql 崩溃，但是因为已经写入了，binlog 会被从库消费使用（或者使用 binlog 恢复库），所以主库上也要提交这个事务 ， 保证主从一致性 。
汗颜！工作10年去面试 ， 被“MySQL怎么保证事物一致性”难倒了阿牛去一家中意的公司面试，本以为凭借以往丰富的经验，肯定手到擒来，结果第一个问题，我就“出门右拐”了 。
问题就是：MySQL是怎么保证事务一致性的？
回到家阿牛翻阅资料 ， 终于搞懂了，在这里分享给大家 。
定义
在搞清楚问题答案之前，先搞清楚以下几个名词以及大致的用处
redo log：
通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样 ， 它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)、Innodb特有的，他在存储引擎层 。循环写的，空间固定会用完 。作用是crash-safe能力
binlog：
是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ” 是 MySQL 的 Server 层实现的 ， 所有引擎都可以使用 。是可以追加写入的,“追加写”是指 binlog 文件写到一定大小后会切换到下一个 ， 并不会覆盖以前的日志 。作用是数据归档
undo log：
有两个作用：提供回滚和多个行版本控制(MVCC) 。
在数据修改的时候 ， 不仅记录了redo，还记录了相对应的undo ， 如果因为某些原因导致事务失败或回滚了 ， 可以借助该undo进行回滚 。
SQL执行的过程
了解了以上名词之后，让我们看一下“一条更新SQL语句执行的过程是什么？”
如图1有几个关键步骤：
1、先查找记录所在的Innodb页在不在内存里；如果不在内存里则将记录所在的页加载在内存里；根据SQL语句在内存中将记录更新
2、将更新前的记录写入undolog
3、根据记录的更新值将变更写入redolog（buffer）中，并将状态变更为prepare
4、将变更记录到逻辑日志
5、redolog日志中的状态修改为commit，返回结束
至此：一条更新语句的过程结束
上面的步骤中有些同学可能会有一些疑问：为什么更新一条记录要把一整页数据加载到内存里答：因为Innodb引擎中，最小的存储单位是页为什么一定要加载到内存里？答：因为所有的计算操作都是在内存里，操作完成后最终才写回磁盘为什么要写入redolog，直接写入磁盘，然后写入binlog就好了?。看穑赫饨谙旅婊崽岬剑?请往后看
为了加深理解，准备了下面2张图辅助理解
以图3为例，让我们看看在每个步骤出现异常的时候，到底怎么保证事物一致性的吧！1、步骤123，所有的操作最多还只是内存里，如果出现宕机、断电等异常，记录不会有任何变动 ， 事物是一致的2、步骤4刚执行完，断电了 ， 因为redolog还处在prepare状态，这时候事物也是一致的3、步骤5记录binlog的过程中断电了，这时候要保证主从一致性，事物也是不生效的，最终也是一致的4、步骤6、7如果中间任何一个时刻断电了，这时候情况就不一样了，事物是生效的，因为redolog、binlog的数据都是完整的，服务器重启后可以按照xid来去查看binlog、redolog中是否都存在，都存在该事物就是生效的 。上面就是怎么保证事务一致性的根本原因
为什么要使用redolog？
回答这个问题之前，我们先看看redolog用图形表示的
图4是redolog的形象一点的表现，并不是说redolog 长这个样子，只是为了更形象；一般情况下redolog一组4个文件，每个文件1个G，其中write pos是指redolog当前写到什么位置了，check point是指上次刷脏结束的位置 ， 当write log和check point重合时 ， 所有的进程停止，开始新一轮的刷脏操作 。刷完后redolog清空开始下一轮的写入，往返重复 。
可能这样表示有点抽象，让我们看下图5
从上图中可以看的更形象一点，在sql执行的时候，会有磁盘IO将数据页加载到内存，然后在内存中将数据修改 ， 修改后的数据页在内存中叫做脏页（叫脏页因为和磁盘中的数据不一致?。? ，又因为在内存中容易丢失，所以将数据页的变更记录如redolog中，随着记录插入、更新等操作的增多，redolog空间慢慢的满了，这时候就开始刷脏操作了 ， page cleaner thread线程会将所有的脏页数据刷新到磁盘，使得变更最终被持久化到磁盘 。
讲到这里一定还会有人不太理解，刷脏之前断电了咋办？
这就是redolog的另一个重要的作用，crash-safe能力，实现的逻辑是这样的，断电后内存的数据都没了，重启后读取redolog文件 ， 因为redolog文件记录的是在Innodb页x的m处做了y的修改 ， 所以根据redolog将涉及到的Innodb页重新加载到内存，根据redolog的记录将内存中的数据重新修改，这样就能恢复断电前的数据了 。
完
下期预告：还是MySQL，敬请期待
本文首发自：程序员阿牛
一文详解-MySQL 事务和锁当多个用户访问同一份数据时，一个用户在更改数据的过程中，可能有其他用户同时发起更改请求，为保证数据库记录的更新从一个一致性状态变为另外一个一致性状态，使用事务处理是非常必要的，事务具有以下四个特性：
MySQL 提供了多种事务型存储引擎，如 InnoDB 和 BDB 等，而 MyISAM 不支持事务 。为了支持事务，InnoDB 存储引擎引入了与事务处理相关的 REDO 日志和 UNDO 日志，同时事务依赖于 MySQL 提供的锁机制
事务执行时需要将执行的事务日志写入日志文件 ， 对应的文件为 REDO 日志 。当每条 SQL 进行数据更新操作时，首先将 REDO 日志写进日志缓冲区 。当客户端执行 COMMIT 命令提交时 ， 日志缓冲区的内容将被刷新到磁盘，日志缓冲区的刷新方式或者时间间隔可以通过参数 innodb_flush_log_at_trx_commit 控制
REDO 日志对应磁盘上的 ib_logifleN 文件，该文件默认为 5MB ， 建议设置为 512MB，以便容纳较大的事务 。MySQL 崩溃恢复时会重新执行 REDO 日志的记录，恢复最新数据，保证已提交事务的持久性
与 REDO 日志相反，UNDO 日志主要用于事务异常时的数据回滚，具体内容就是记录数据被修改前的信息到 UNDO 缓冲区 ， 然后在合适的时间将内容刷新到磁盘
假如由于系统错误或者 rollback 操作而导致事务回滚，可以根据 undo 日志回滚到没修改前的状态，保证未提交事务的原子性
与 REDO 日志不同的是，磁盘上不存在单独的 UNDO 日志文件，所有的 UNDO 日志均存在表空间对应的 .ibd 数据文件中，即使 MySQL 服务启动了独立表空间
在 MySQL 中，可以使用 BEGIN 开始事务，使用 COMMIT 结束事务，中间可以使用 ROLLBACK 回滚事务 。MySQL 通过 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等语句支持本地事务
MySQL 定义了四种隔离级别，指定事务中哪些数据改变其他事务可见、哪些数据该表其他事务不可见 。低级别的隔离级别可以支持更高的并发处理，同时占用的系统资源更少
InnoDB 系统级事务隔离级别可以使用以下语句设置：
查看系统级事务隔离级别：
InnoDB 会话级事务隔离级别可以使用以下语句设置：
查看会话级事务隔离级别：
在该隔离级别，所有事务都可以看到其他未提交事务的执行结果 。读取未提交的数据称为脏读（Dirty Read），即是：首先开启 A 和 B 两个事务，在 B 事务更新但未提交之前，A 事务读取到了更新后的数据，但由于 B 事务回滚，导致 A 事务出现了脏读现象
所有事务只能看见已经提交事务所做的改变 ， 此级别可以解决脏读 ， 但也会导致不可重复读（Nonrepeatable Read）：首先开启 A 和 B 两个事务 ， A事务读取了 B 事务的数据 ， 在 B 事务更新并提交后，A 事务又读取到了更新后的数据，此时就出现了同一 A 事务中的查询出现了不同的查询结果
MySQL 默认的事务隔离级别，能确保同一事务的多个实例在并发读取数据时看到同样的数据行，理论上会导致一个问题，幻读（Phontom Read） 。例如，第一个事务对一个表中的数据做了修改，这种修改会涉及表中的全部数据行，同时第二个事务也修改这个表中的数据，这次的修改是向表中插入一行新数据，此时就会发生操作第一个事务的用户发现表中还有没有修改的数据行
InnoDB 通过多版本并发控制机制（MVCC）解决了该问题：InnoDB 通过为每个数据行增加两个隐含值的方式来实现，这两个隐含值记录了行的创建时间、过期时间以及每一行存储时间发生时的系统版本号，每个查询根据事务的版本号来查询结果
通过强制事务排序，使其不可能相互冲突，从而解决幻读问题 。简而言之，就是在每个读的数据行上加上共享锁实现，这个级别会导致大量的超时现象和锁竞争，一般不推荐使用
为了解决数据库并发控制问题，如走到同一时刻客户端对同一张表做更新或者查询操作 ， 需要对并发操作进行控制，因此产生了锁
共享锁的粒度是行或者元组（多个行），一个事务获取了共享锁以后，可以对锁定范围内的数据执行读操作
排他锁的粒度与共享锁相同，一个事务获取排他锁以后，可以对锁定范围内的数据执行写操作
有两个事务 A 和 B，如果事务 A 获取了一个元组的共享锁，事务 B 还可以立即获取这个元组的共享锁，但不能获取这个元组的排他锁 ， 必须等到事务 A 释放共享锁之后 。如果事务 A 获取了一个元组的排他锁，事务 B 不能立即获取这个元组的共享锁，也不能立即获取这个元组的排他锁，必须等到 A 释放排他锁之后
意向锁是一种表锁 ， 锁定的粒度是整张表 ， 分为意向共享锁和意向排他锁 。意向共享锁表示一个事务有意对数据上共享锁或者排他锁 。有意表示事务想执行操作但还没真正执行
锁的粒度主要分为表锁和行锁
表锁的开销最?。?同时允许的并发量也是最小 。MyISAM 存储引擎使用该锁机制 。当要写入数据时 ， 整个表记录被锁，此时其他读/写动作一律等待 。一些特定的动作，如 ALTER TABLE 执行时使用的也是表锁
行锁可以支持最大的并发 ， InnoDB 存储引擎使用该锁机制 。如果要支持并发读/写 ， 建议采用 InnoDB 存储引擎
mysql的事务四个特性以及事务的四个隔离级别分别是原子性、一致性、隔离性、持久性 。
原子性是指事务包含的所有操作要么全部成功mysql怎么保证事务 ， 要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响 。
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态 。举例来说 ， 假设用户A和用户B两者的钱加起来一共是1000，那么不管A和B之间如何转账、转几次账，事务结束后两个用户的钱相加起来应该还得是1000，这就是事务的一致性 。
隔离性是当多个用户并发访问数据库时，比如同时操作同一张表时，数据库为每一个用户开启的事务，不能被其mysql怎么保证事务他事务的操作所干扰，多个并发事务之间要相互隔离 。关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到 。
持久性是指一个事务一旦被提交了 ， 那么对数据库中的数据的改变就是永久性的 ， 即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作 。例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务已经正确提交，即使这时候数据库出现了问题 ， 也必须要将我们的事务完全执行完成 。否则的话就会造成我们虽然看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误 。这是不允许的 。
在数据库操作中，在并发的情况下可能出现如下问题：
正是为了解决以上情况 ， 数据库提供了几种隔离级别 。
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted(未授权读取、读未提交)、Read committed（授权读取、读提交）、Repeatable read（可重复读?。erializable（序列化），这四个级别可以逐个解决脏读、不可重复读、幻象读这几类问题 。
虽然数据库的隔离级别可以解决大多数问题，但是灵活度较差，为此又提出了悲观锁和乐观锁的概念 。
悲观锁，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度 。因此，在整个数据处理过程中，将数据处于锁定状态 。悲观锁的实现 ， 往往依靠数据库提供的锁机制 。也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统的数据访问层中实现了加锁机制 ， 也无法保证外部系统不会修改数据 。
商品t_items表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单（此时该商品无法再次下单） ， 那么我们对某个商品下单时必须确保该商品status为1 。假设商品的id为1 。
如果不采用锁 ， 那么操作方法如下：
但是上面这种场景在高并发访问的情况下很可能会出现问题 。例如当第一步操作中，查询出来的商品status为1 。但是当我们执行第三步Update操作的时候，有可能出现其他人先一步对商品下单把t_items中的status修改为2了，但是我们并不知道数据已经被修改了，这样就可能造成同一个商品被下单2次，使得数据不一致 。所以说这种方式是不安全的 。
在上面的场景中，商品信息从查询出来到修改 ， 中间有一个处理订单的过程，使用悲观锁的原理就是，当我们在查询出t_items信息后就把当前的数据锁定，直到我们修改完毕后再解锁 。那么在这个过程中，因为t_items被锁定了 ， 就不会出现有第三者来对其进行修改了 。需要注意的是，要使用悲观锁，我们必须关闭mysql数据库的自动提交属性 ， 因为MySQL默认使用autocommit模式，也就是说 ， 当你执行一个更新操作后，MySQL会立刻将结果进行提交 。我们可以使用命令设置MySQL为非autocommit模式：set autocommit=0;
设置完autocommit后，我们就可以执行我们的正常业务了 。具体如下：
上面的begin/commit为事务的开始和结束，因为在前一步我们关闭了mysql的autocommit，所以需要手动控制事务的提交 。
上面的第一步我们执行了一次查询操作：select status from t_items where id=1 for update;与普通查询不一样的是，我们使用了select…for update的方式，这样就通过数据库实现了悲观锁 。此时在t_items表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行 。这样我们可以保证当前的数据不会被其它事务修改 。需要注意的是，在事务中，只有SELECT ... FOR UPDATE或LOCK IN SHARE MODE操作同一个数据时才会等待其它事务结束后才执行，一般SELECT ...则不受此影响 。拿上面的实例来说，当我执行select status from t_items where id=1 for update;后 。我在另外的事务中如果再次执行select status from t_items where id=1 for update;则第二个事务会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果我是在第二个事务中执行select status from t_items where id=1;则能正常查询出数据，不会受第一个事务的影响 。
使用select…for update会把数据给锁?。还颐切枰⒁庖恍┧募侗穑琈ySQL InnoDB默认Row-Level Lock，所以只有「明确」地指定主键或者索引，MySQL 才会执行Row lock (只锁住被选取的数据)，否则MySQL 将会执行Table Lock (将整个数据表单给锁住) 。举例如下：
1、select * from t_items where id=1 for update;
这条语句明确指定主键（id=1），并且有此数据（id=1的数据存在），则采用row lock 。只锁定当前这条数据 。
2、select * from t_items where id=3 for update;
这条语句明确指定主键，但是却查无此数据 ， 此时不会产生lock（没有元数据 ， 又去lock谁呢？） 。
3、select * from t_items where name='手机' for update;
这条语句没有指定数据的主键，那么此时产生table lock，即在当前事务提交前整张数据表的所有字段将无法被查询 。
4、select * from t_items where id0 for update;或者select * from t_items where id1 for update;（注：在SQL中表示不等于）
上述两条语句的主键都不明确，也会产生table lock 。
5、select * from t_items where status=1 for update;（假设为status字段添加了索引）
这条语句明确指定了索引，并且有此数据，则产生row lock 。
6、select * from t_items where status=3 for update;（假设为status字段添加了索引）
这条语句明确指定索引，但是根据索引查无此数据，也就不会产生lock 。
乐观锁（ Optimistic Locking ） 相对悲观锁而言 ， 乐观锁假设认为数据一般情况下不会造成冲突 ， 所以只会在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回用户错误的信息，让用户决定如何去做 。实现乐观锁一般来说有以下2种方式：
mysql怎么保证事务的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于注册文化工作室要多少钱、mysql怎么保证事务的信息别忘了在本站进行查找喔 。

    推荐阅读


    上一篇：网维科技服务器表现如何？ 网维科技服务器怎么样

    下一篇：如何构建企业级云服务器配置？ 怎么搭建企业云服务器配置