用存储过程处理复杂的业务时,可能涉及到对多张表格的操作,在任一个步骤出了问题,就需要对前面的操作回滚.举例实现: DROP PROCEDURE IF EXISTS pro_test; CREATE PROCEDURE pro_test ( para_a ), para_b ) ) BEGIN ; -- 定义返回结果并赋初值0 ; -- 在执行过程中出任何异常设置result_code为1 ; -- 如果表中没有下一条数据则置为2 START TRANSACTION; -- 开始事务 /* * 这

一.起因 begin或者START TRANSACTION开始一个事务 rollback事务回滚 commit 事务确认 人们对事务的解释如下:事务由作为一个单独单元的一个或多个SQL语句组成,如果其中一个语句不能完成,整个单元就会回滚(撤销),所有影响到的数据将返回到事务开始以前的状态.因而,只有事务中的所有语句都成功地执行才能说这个事务被成功地执行.  这句话本身没有什么问题,问题是我给理解错了,我测试中问题描述为如下: mysql事务中有两条insert语句,其中第二条语句是错误的,在运行

参考:http://wubx.net/?s=mysqlbinlog mysql官方的mysqlbinlog没有回滚的功能,淘宝大牛对官方代码进行了修改使之能够将binlog中的DML操作变成互逆的语句,比如delete变为insert,update的set和where的互换.不过注意前提是binlog的格式必须是binlog_format=ROW 另外注意导入回滚数据较多时,需要调整超时时间和最大package的大小: binlog_format=ROW max_allowed_packet=1

add by zhj: 看来我对MySQL的理解还有待深入,水还是挺深的啊,MySQL给记录加锁时,可以通过innodb_lock_wait_timeout参数设置超时时间, 如果加锁等待超过这个时间,就会回滚,但回滚的话有两种方式:第一种:回滚当前加锁的这条语句:第二种:回滚整个事务.这两种方式是通过参数 innodb_rollback_on_timeout来控制的.如果是OFF,表示加锁超时回滚时,只回滚加锁超时的那条SQL语句:如果是ON,表示回滚整个事务.默认 是OFF.在<MySQL

应用场景:   银行取钱,从ATM机取钱,分为以下几个步骤       1 登陆ATM机,输入密码:    2 连接数据库,验证密码:    3 验证成功,获得用户信息,比如存款余额等:    4 用户输入需要取款的金额,按下确认键:    5 从后台数据库中减掉用户账户上的对应金额:    6 ATM吐出钱:    7 用户把钱拿走.    对于上面的取钱这个事情,如果有一步出现错误的话,那么就会取消整个取钱的动作,但是如果在第5步,系统后台已经把钱减了,但是ATM机没有取出来,那么就应用到m

主要内容: ***数据定义语言DDL重点 ***数据操纵语言DML重点 数据查询语言DQL重点 ---事务控制语言TCL ---数据库控制语言DCL ---主键(primary key) ---数据冗余(另外建表,把某个外建与另一个表的主键建立关系联系起来) ---事务 ***数据定义语言DDL重点 定义:DDL(Data Definition Language):负责数据结构定义与创建数据库对象的语言. 负责数据结构定义与创建数据库对象的语言. 常用的有create alter drop  

提交 为了演示效果,需要打开两个终端窗口,使用同一个数据库,操作同一张表 step1:连接 终端1:查询商品分类信息 select * from goods_cates; step2:增加数据 终端2:开启事务,插入数据 begin; insert into goods_cates(name) values('小霸王游戏机'); 终端2:查询数据,此时有新增的数据 select * from goods_cates; step3:查询 终端1:查询数据,发现并没有新增的数据 select * f

最近碰到“TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION”. 重新温习下受益良多,其中死锁的判定规则,其实我们早在5年前解决秒杀场景的第一个版本就已经涉及,并且思路很相似,如果有时间的话,我会补充上一批文章说下如果关闭死锁检测对单行更新能提升多少性能. 下面这一段代码展示的是: “ If the LATEST DETECTED DEADLOCK s

事务回滚后,自增ID仍然增加,回滚后,自增ID仍然增加.比如当前ID是7,插入一条数据后,又回滚了.然后你再插入一条数据,此时插入成功,这时候你的ID不是8,而是9.因为虽然你之前插入回滚,但是ID还是自增了. 如果你认为自增ID不应该被事务化,那么其他事务不得不等待着,检查自增ID是被使用还是被回滚,这就导致阻塞. 比如下面的例子,A表使用自增ID. User ------------ begin transaction insert into A ... insert into B ...

从MySQL binlog解析出你要的SQL.根据不同选项,你可以得到原始SQL.回滚SQL.去除主键的INSERT SQL等. 用途=========== * 数据快速回滚(闪回)* 主从切换后新master丢数据的修复* 从binlog生成标准SQL,带来的衍生功能 项目状态===正常维护.应用于部分公司线上环境. * 已测试环境    * Python 2.7, 3.4+    * MySQL 5.6, 5.7 安装============== ```shell> git clone ht

1   引言Mysql的触发器和存储过程一样,都是嵌入到mysql的一段程序.触发器是mysql5新增的功能,目前线上凤巢系统.北斗系统以及哥伦布系统使用的数据库均是mysql5.0.45版本,很多程序比如fc-star管理端,sfrd(das),dorado都会用到触发器程序,实现对于数据库增.删.改引起事件的关联操作.本文介绍了触发器的类型和基本使用方法,讲述了触发器使用中容易产生的误区,从mysql源码中得到触发器执行顺序的结论,本文最后是实战遭遇的触发器经典案例.没有特殊说明时,本文的实

使用MySQL时.假设发现事务无法回滚,但Hibernate.Spring.JDBC等配置又没有明显问题时.不要苦恼,先看看MySQL创建的表有没有问题.即表的类型. InnoDB和MyISAM是在使用MySQL最经常使用的两个表类型,各有优缺点,视详细应用而定. 主要的区别为:MyISAM类型不支持事务处理等高级处理,而InnoDB类型支持. MyISAM类型的表强调的是性能,其运行数度比InnoDB类型更快,可是不提供事务支持,而InnoDB提供事务支持已经外部键等高级数据库功能. MyIA

MySQL数据库-MySQL事务操作(回滚) 事务用于将某些操作的多个SQL作为原子性操作,一旦有某一个出现错误,即可回滚到原来的状态,从而保证数据库数据完整性. 举例:有这样一张表 从表里可以看出张三的资金里有850元,李四的资金有632元 假如张三向李四划款20元,那么张三的资金应该减20,李四的资金应该加20 WHERE yhm = '张三'; WHERE yhm = '李四'; 可以看到张三的资金以减20,李四的资金以加20 但是如果在李四资金加的时候SQL语句出错,那么就会导致张三减少

今天做数据迁移, 发现事务有时候可以回滚, 有时候不可以回滚, 最后一点点调试发现中间有段修改表结构的语句, 最终导致回滚失败. 1.MySQL最常用的两个表类型: InnoDB和MyISAM.MyISAM类型的表强调的是性能,其执行数度比InnoDB类型更快,但是不提供事务支持,而InnoDB提供事务支持.存储过程.视图.行级锁定等等高级数据库功能,若回滚失败,先检查表类型. SHOW ENGINES 语句可以查看当前的数据库支持的存储类 SHOW CREATE TABLE 表名;可以查看表的

论坛扣币项目中,用户支付论坛币的时候如果突然断网.电脑死机.停电.等其它自然灾害时,导致本次交易没有成功(即用户的币已经扣掉了,但是服务器数据库中没有消费记录等其它情况),这种情况应该怎么样进行处理呢?在这个时候,我们可以用Mysql事务回滚来进行处理,那代码怎么写呢? 那下面我就来说一说这个mysql事务回滚应该怎么处理.首先MYSQL中只有INNODB和BDB类型的数据表才能支持事务处理!其他的类型是不支持的!那如果,我们的数据表已经存在,并且不是上面所说的两种类型的话,应该怎么办呢?1.我

在事务中,每个正确的原子操作都会被顺序执行,直到遇到错误的原子操作,此时事务会将之前的操作进行回滚.回滚的意思是如果之前是插入操作,那么会执行删 除插入的记录,如果之前是update操作,也会执行update操作将之前的记录还原 因此,正确的原子操作是真正被执行过的.是物理执行. 在当前事务中确实能看到插入的记录.最后只不过删除了.但是AUTO_INCREMENT不会应删除而改变值. 1.为什么auto_increament没有回滚? 因为innodb的auto_increament的计数器记录

mysql 事务表是有回滚的说法.当发生mysql层面的错误才会执行回滚

前言:      继上一篇MySQL[Delete误操作]回滚之后,现在介绍下Update回滚,操作数据库时候难免会因为“大意”而误操作,需要快速恢复的话通过备份来恢复是不太可能的,因为需要还原和binlog差来恢复,等不了,很费时.这里说明因为Update 操作的恢复方法:主要还是通过binlog来进行恢复,前提是binlog_format必须是Row格式,否则只能通过备份来恢复数据了.和上一篇的条件一样.方法:     条件:开启Binlog,Format为Row.     步骤:1.通过M

1.mysqlbinlog把事务从binlog中导出 2.从导出的binlog中找到要回滚的事务,去掉第一个DML语句前和最后一个DML语句后与DML无关的binlog信息 3.在目录中新建一个table.cnf,把表结构以@1=columns这样的顺序一行写一列 4.update回滚支持选择条件列和回滚的数据列,把回滚时不需要的条件(列)写到not_used.set和not_used.where中 例如: 文件 table.cnf @=id @=column_a @=column_b @=ti

MySQL自己的 mysqlbinlog | mysql 回滚不好用,自己写个简单脚本试试: 想法是用mysqlbinlog把需要回滚的事务区域从mysql-bin.file中找到,然后通过脚本再插入DB. ## INSERT 需要将新增数据删除 对应DELETE ## DELETE 需要将删除数据恢复 对应INSERT ## UPDATE 需要将修改数据恢复 对应UPDATE ## 手动读取BINLOG,并找到对应位置和对应事务 ## 手动删除除事务外的其他说明语句 INSERT回滚最简单,其