记一次模拟断电，事务回滚。

最新推荐文章于 2025-05-22 19:13:02 发布
原创 最新推荐文章于 2025-05-22 19:13:02 发布 · 828 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql

本文探讨了在代码中断点后程序中断导致事务不回滚的问题，分析了事务不会回滚的常见原因，包括调用自身类方法和使用非InnoDB数据库。并通过模拟断电测试，验证事务的正常回滚机制。

在代码中部下断点后中断程序，事务是不会回滚的，这样会污染数据。暂时不理解事务不会回滚的原因。

模拟断电应该用线程休眠，然后直接中断程序，这样可以看到事务确实有正常回滚。

 

 

不会回滚的原因一般基本就是

1.调用了自身类方法这样是不会回滚的。这个很容易知道，毕竟AOP。

2.数据库不是inndb。

一次无效 Cursor Dump 的排雷记：用 Service Connection 护住 ABAP SQL Cursor
2007 年 ~ 2025 年，深耕 SAP 技术 18 年
12-13 28
文章摘要： ABAP开发中处理海量数据时，分包读取常遇到Cursor失效问题。本文分析了传统OPEN CURSOR和现代SELECT PACKAGE SIZE两种方法在遇到提交时的脆弱性，指出COMMIT WORK会关闭所有数据库连接和Cursor。解决方案是使用service connection分离读取和提交链路：通过R/3*前缀的专用连接进行数据读取，用COMMIT CONNECTION default提交业务处理，避免影响读取Cursor。文章提供了可直接复用的代码模板，并强调必须避免在循环内使用C
事务是如何回滚的
王鹏的专栏
08-19 2168
先举个栗子： 大家应该都用过office Word，之前一直盛传如果电脑突然断电了，文档会丢失，这个是很早的时候的问题了，现在已经解决了，我们看一下是如何解决的，当我们在编辑文档的时候，每隔一段时间，word会自动把当前的编辑记录记下来， 我们可以把每一次的开始编辑作为一次事务的 Begin，每一次的保存作为事务的 Commit，不保存退出作为事务的 Rollback。 之后如果正常保存后，就清除这些log，如果突然断电了，再次打开的时候软件发现有日志，就提示用户是rollback还是commit。 这
mysql事务未提交断开连接,连接丢失/断开连接的事务的MySQL回滚
weixin_42372731的博客
01-20 727
I need to make MySQL server to rollback transaction immediately after its client disconnected, because each client works concurrently. The problem can be reproduced like these (using an innodb table t...
MySQL 事务提交一半断电，会怎么样？
cda2024的博客
12-06 1067
在数据库管理中，事务是一组逻辑操作单元，这些操作要么全部成功执行，要么全部不执行。原子性（Atomicity）：事务是一个不可分割的工作单位，事务中的操作要么全部完成，要么全部不完成。一致性（Consistency）：事务必须使数据库从一个一致性状态转换到另一个一致性状态。隔离性（Isolation）：事务的执行不受其他事务的干扰，每个事务都独立运行。持久性（Durability）：一旦事务提交，其对数据库的改变是永久性的，即使系统发生故障也不会丢失。
数据库故障排查指南，未提交的事务导致数据回滚
百态老人的博客
05-22 731
两阶段提交（2PC）协议是分布式事务处理的核心机制之一，尽管其设计简单且能保证事务的一致性，但在实际应用中仍面临性能瓶颈和可用性挑战。通过引入移动代理、超时机制、副本协议以及优化锁资源管理等策略，可以显著提升2PC协议的效率和可靠性。
事务回滚的多维视角：非线性规划的综合应用剖析
事务回滚是保证数据库事务一致性和系统稳定性的关键技术，本文全面探讨了事务回滚的概念、理论框架、实践应用、高级话题以及相关技术的深入探讨。文中首先介绍了事务的一致性原理和ACID特性，随后详细阐述了回滚机制...
ESP32 OTA过程中的电源风险预警：中断、断电与回滚机制的3重防护
# 1. ESP32 OTA升级的核心机制与电源依赖 ESP32的OTA（Over-the-Air）升级机制依赖于Bootloader、分区表...该代码用于获取当前运行的固件分区，是判断是否需回滚或更新的前提。 整个OTA过程对电源稳定性高度敏感，尤
非线性规划对比分析：事务回滚策略的选择与应用
本文概述了非线性规划的基本理论，并详细分析了事务回滚策略的分类和原理，包括线性和非线性回滚策略，以及它们在非线性规划中的作用。通过对比分析，文章探讨了不同回滚策略的性能、复杂度和应用场景，提出了
事务回滚却吞掉异常？Transaction异常传播行为深度解析（避坑必读｜80%开发者踩过）
# 事务回滚与异常处理的深层陷阱：从原理到实战 在现代 Java 应用开发中，Spring 的 `@Transactional` 注解几乎成了“数据安全”的代名词。你有没有遇到过这样的场景？——本地测试一切正常，日志里也报了错，但...
stop slave后，正在执行的事务是完成了还是回滚了rollback
翔云
08-15 403
目录1.关于stop slave后，事务执行结果2.观察事务回滚2.1.设置从库的事务隔离级别2.2.启动SQL thread2.3.停止复制，查看事务执行情况 1.关于stop slave后，事务执行结果 如果从库上SQL线程正在应用relay log，或者说正在执行一个事务，此时如果stop slave，那么这个事务执行结果会是什么，完成还是未完成？ 由于事务的原子性，可以这么说，事务要么执行完成，要么回滚。 先说结论，事务执行结果有两种： 执行完成 未执行完成（事务回滚） 那什么情况执行完成，什么
数据库的事务
qq_58000413的博客
10-04 577
所有事务中都是为了保证数据的一致性，所以一致性是最终的追求，事务中的一致性是通过原子性、隔离性、持久性来保证的。最终是为了保证数据的一致性，当经过N多次操作之后，数据的状态从一个一致性到另外一个一致性状态，也就是数据不可发生不一致。各个事务之间相关不会产生影响，严格的隔离性会呆滞效率降低，在某些情况下为了提高执行效率会降低隔离性的级别。这些操作要么都做，要么都不做，是一个不可分割的工作单位，是数据库环境中的逻辑单位。一般情况下，锁的粒度越小，效率越高，粒度越大，效率越低。3.用户关闭会话之后，会自动提交。
断点事务没有提交，java应用结束异常，导致锁未释放(Lock wait timeout exceeded try restarting transaction)
Edifierbug的博客
12-28 810
笔者在本地开发的过程中，断点的时候，不小心退出应用导致事务失败，在对某张表的的update到做，导致行锁一只没有释放，runing 的状态，如图,可以看打查询运行的这个running 状态记录是那张表，何时开始的，得到详细信息之后，直接kill这个 事务，方框标记的线程id。，kill id ,结束当前事务，数据恢复正餐。 ...
超牛牪犇Java之事务
程序猿的奇幻漂流
07-03 358
一.一些特性原子性：指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。使用事务(用事务的sql语句(事务开始和事务提交) 包裹住 你要执行语句)1.把事务打开 2.写你要执行语句3.把事务进行提交4.把事务回滚(rollback;) 遇到断电 事务没有提交 那么事务会自动回滚//开启事务 BEGIN; //提交事务 这时只有两条语句有成功了才会成功 //如果有一条没成功 就会回...
Java JDBC基本操作
Eaeyson的博客
11-05 736
Java JDBC基本操作
①①MySQL事务transaction（手动事务、事务操作、事务操作原理、回滚点、自动事务处理、事务的四大特性：ACID、锁机制 ）
SUNZHUANGZHUANG的博客
02-24 322
mysql.exe -h localhost -P 3306 -u root -p use mydb; —— 进入数据库 查看：show index from 表名\G desc：查看表结构 select * from 表名：查询所有数据 提交事务：commit; 同步数据表，表示操作成功 回滚事务：rollback; 直接清空日志表，表示操作失败 事务transaction 事务...
结束事务的其他情景
m0_46160024的博客
10-13 770
结束事务的其他情景
事务提交了就不能回滚了吗？
最新发布
12-15
### 事务提交后能否回滚？—— 深入解析 **直接回答：一旦事务被正式提交（COMMIT），就绝对不能再回滚了！** 让我通过代码和原理来详细解释： #### 1. 提交即不可逆的验证实验 ```sql -- 创建测试表 DROP TABLE IF EXISTS test_rollback; CREATE TABLE test_rollback ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50), value INT DEFAULT 0, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB; INSERT INTO test_rollback (name, value) VALUES ('初始记录', 100); -- 查看初始状态 SELECT 'before_transaction' as stage, * FROM test_rollback; ``` ##### 场景A：未提交时可以回滚 ✅ ```sql START TRANSACTION; UPDATE test_rollback SET value = 200 WHERE name = '初始记录'; INSERT INTO test_rollback (name, value) VALUES ('新记录', 50); -- 此时可以查看变化（仅本会话可见） SELECT 'after_update_before_commit' as stage, * FROM test_rollback; -- 执行回滚 - 成功恢复原状！ ROLLBACK; -- 验证：回到最初状态 SELECT 'after_rollback' as stage, * FROM test_rollback; -- 只有最初的那条记录，value还是100 ``` ##### 场景B：已提交后无法回滚 ❌ ```sql START TRANSACTION; UPDATE test_rollback SET value = 300 WHERE name = '初始记录'; INSERT INTO test_rollback (name, value) VALUES ('提交的记录', 80); -- 关键步骤：提交事务！ COMMIT; -- 尝试回滚 - 这里会出错或无效！ -- ROLLBACK; -- 即使执行也不会有任何效果 -- 查询结果：修改永久生效！ SELECT 'after_commit' as stage, * FROM test_rollback; -- 显示两条记录，value为300和80，永远改变了！ ``` #### 2. 为什么提交后不能回滚？ ```sql -- 原理：InnoDB的事务日志机制 -- 当执行 COMMIT 时会发生什么？ -- 1. REDO LOG 写入磁盘 -- 2. 数据页标记为已修改 -- 3. 释放行锁 -- 4. 事务状态变为"已提交" -- 验证REDO日志的影响 SHOW ENGINE INNODB STATUS\G -- 查看 "LOG" 部分，会显示： -- Log sequence number: ... （持续增长） ``` #### 3. 提交后的"补救"方案 虽然不能直接回滚，但可以通过其他方式修复： ##### 方案1：反向操作（推荐） ```sql -- 如果错误地执行了： START TRANSACTION; UPDATE test_rollback SET value = 999 WHERE name = '初始记录'; COMMIT; -- 补救方法：执行相反的更新 START TRANSACTION; UPDATE test_rollback SET value = 300 WHERE name = '初始记录'; -- 恢复正确值 INSERT INTO operation_log VALUES ( NULL, 'manual_correction', '修正错误的更新操作', NOW() ); COMMIT; ``` ##### 方案2：使用binlog进行时间点恢复 ```bash # MySQL必须开启binlog # my.cnf配置： # log-bin=mysql-bin # binlog-format=ROW # 查看binlog内容 mysqlbinlog --start-datetime="2025-12-14 07:00:00" \ --stop-datetime="2025-12-14 07:10:00" \ mysql-bin.000001 > recovery.sql # 编辑recovery.sql，删除错误的COMMIT之后的操作 # 然后重新导入 mysql -u root -p mydb < recovery.sql ``` ##### 方案3：基于备份的恢复 ```sql -- 定期备份策略 mysqldump -u root -p --single-transaction mydb > backup_$(date +%Y%m%d).sql -- 如果发生重大错误，从备份恢复 mysql -u root -p mydb < backup_20251213.sql ``` #### 4. 防御性编程：提交前的确认机制 ```sql DELIMITER // CREATE PROCEDURE safe_update_with_confirmation( IN target_name VARCHAR(50), IN new_value INT ) BEGIN DECLARE current_value INT; DECLARE confirm_input VARCHAR(10); -- 开始事务 START TRANSACTION; -- 查询当前值 SELECT value INTO current_value FROM test_rollback WHERE name = target_name FOR UPDATE; SELECT CONCAT('即将修改: ', target_name) as info; SELECT CONCAT('原值: ', current_value) as info; SELECT CONCAT('新值: ', new_value) as info; -- 实际应用中这里应该返回给前端让用户确认 -- 模拟用户输入确认 SET confirm_input = 'yes'; -- 应该来自用户输入 IF confirm_input != 'yes' THEN ROLLBACK; SELECT '操作已取消' as result; ELSE UPDATE test_rollback SET value = new_value WHERE name = target_name; COMMIT; SELECT '更新成功' as result; END IF; END// DELIMITER ; -- 使用示例 CALL safe_update_with_confirmation('初始记录', 500); ``` #### 5. 生产环境的最佳实践 ```sql -- 1. 设置长事务监控 SET SESSION innodb_lock_wait_timeout = 30; SET SESSION wait_timeout = 28800; -- 2. 提交前二次确认 SET SQL_SAFE_UPDATES = 1; -- 防止无WHERE条件的UPDATE -- 3. 使用保存点进行细粒度控制 START TRANSACTION; SAVEPOINT sp1; UPDATE test_rollback SET value = 1000 WHERE name = '初始记录'; SAVEPOINT sp2; INSERT INTO test_rollback VALUES (NULL, '临时记录', 999, NULL); -- 如果只想回滚到sp2 -- ROLLBACK TO sp2; -- 可以撤销INSERT，保留UPDATE -- 但一旦COMMIT，所有SAVEPOINT都失效！ COMMIT; ``` #### 6. 重要警告：不要依赖自动回滚 ```sql -- 错误观念： -- "反正可以回滚，先试试看" -- 真实情况： START TRANSACTION; UPDATE huge_table SET status = 'processed' WHERE create_date < '2024-01-01'; -- 处理百万行数据... COMMIT; -- 提交后发现错了！ -- 结果：无法挽回，只能手动修复或从备份恢复 ``` ### 核心结论： 1. **COMMIT = 不归路** - 一旦提交，修改永久生效 - REDO LOG确保即使断电也能恢复 2. **预防胜于治疗** ```sql -- 好习惯： -- 1. 小批量操作 -- 2. 提交前查询验证 -- 3. 关键操作加确认 -- 4. 定期备份 ``` 3. **补救措施有限** - 只能通过反向SQL、binlog或备份恢复 - 都需要额外的时间和资源
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值