【MySQL】事务的快照生成时间点和薛定谔的猫相关？

InterestingFigure2024-06-29 20:56

概述

最近因为工作需要，对MySQL的事务处理进行了一系列测试验证，其中，对于MySQL的事务到底时什么时候生成了数据的快照，结果似乎跟薛定谔的猫理念很像，很有意思；过程我贴出来，有兴趣的朋友可以一起研究研究。

事务不依赖于虚拟表或者辅助表，而是主要依赖于 MySQL 的 InnoDB 存储引擎所提供的多版本并发控制 (MVCC) 机制和事务日志。

在事务开始时，MySQL 会记录当前事务的快照 (snapshot)，这意味着在事务期间，你看到的数据是事务开始时的版本，即使其他事务对数据进行了修改。

本文的所有步骤严格按照时间线前后关联，顺序变了，结果就会变化。

假如有如下表：
登录后复制

plain 复制代码 
# Session 2
 MySQL  localhost:3306 ssl  xiaml  SQL > select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|          7 | 5000.00 |
|          8 | 6000.00 |
|          9 | 1000.00 |
|         10 | 2000.00 |
+------------+---------+
5 rows in set (0.0005 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL >

测试1：事务中进行了数据观察

登录后复制

plain 复制代码 
# Session1
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql>  
-- 此时并不建立快照,此时对事务而言，数据与实际表完全一致。5行数据。但是别查询！！

登录后复制

plain 复制代码 
# Session 2
# 删除两条数据
 MySQL  localhost:3306 ssl  xiaml  SQL > DELETE FROM accounts WHERE account_id = 7 or account_id = 8;
Query OK, 2 row affected (0.0038 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL >
 MySQL  localhost:3306 ssl  xiaml  SQL > select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|          9 | 1000.00 |
|         10 | 2000.00 |
+------------+---------+
3 rows in set (0.0009 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL >

登录后复制

plain 复制代码 
# Session1
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql>  
-- 此时并不建立快照,此时对事务而言，数据与实际表完全一致。***********3行数据。**************
mysql> select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|          9 | 1000.00 |
|         10 | 2000.00 |
+------------+---------+
3 rows in set (0.00 sec)

mysql>
-- 此时快照已建立，也就是说START TRANSACTION;后的任何语句就是精确的快照点。

登录后复制

plain 复制代码 
# Session 2
# 再删除一条数据
 MySQL  localhost:3306 ssl  xiaml  SQL > DELETE FROM accounts WHERE account_id =9;
Query OK, 1 row affected (0.0038 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL >
 MySQL  localhost:3306 ssl  xiaml  SQL > select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|         10 | 2000.00 |
+------------+---------+
2 rows in set (0.0006 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL >

登录后复制

plain 复制代码 
# Session1
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql>  
-- 此时并不建立快照,此时对事务而言，数据与实际表完全一致。***********3行数据。**************
mysql> select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|          9 | 1000.00 |
|         10 | 2000.00 |
+------------+---------+
3 rows in set (0.00 sec)

mysql>
-- 此时快照已建立，也就是说START TRANSACTION;后的任何语句就是精确的快照点。
mysql> select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|          9 | 1000.00 |
|         10 | 2000.00 |
+------------+---------+
3 rows in set (0.00 sec)

mysql>
-- 因为快照已建立，因此，对于事务来说时间就凝固在那一刻了；其他会话的改变对凝固状态下的数据无影响。

很像薛定谔的猫的感觉，只要观测过，从那一刻就出现了分支。

测试1：事务中先不做数据观察

那我们再做个实验；事务开始后不做任何地数据的操作甚至查询都不做，只定义一个变量；然后在另一个会话删除数据然后观察删除是否在事务中产生分支？
登录后复制

plain 复制代码 
# Session1
MySQL  localhost:3306 ssl  xiaml  SQL > select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|          7 | 5000.00 |
|          8 | 6000.00 |
|          9 | 1000.00 |
|         10 | 2000.00 |
+------------+---------+
5 rows in set (0.0009 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL >

登录后复制

plain 复制代码 
# Sesson2
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> 
-- 此时并不建立快照,此时对事务而言，数据与实际表完全一致。5行数据。但是别查询！！
-- 在另一个会话中删除2条数据

登录后复制

plain 复制代码 
# Session1
# 删除两条数据
 MySQL  localhost:3306 ssl  xiaml  SQL > DELETE FROM accounts WHERE account_id =7 or account_id = 8;
Query OK, 2 rows affected (0.0044 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL > select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|          9 | 1000.00 |
|         10 | 2000.00 |
+------------+---------+
3 rows in set (0.0015 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL >

登录后复制

plain 复制代码 
# Session2
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)
mysql> 
-- 此时并不建立快照,此时对事务而言，数据与实际表完全一致。5行数据。但是别查询！！
-- 在另一个会话中删除2条数据
mysql> SET @name := 'xiamingliang';
Query OK, 0 rows affected (0.00 sec)

mysql>
-- 仅仅在事务中创建一个变量，不对数据进行任何形式的查询与变更动作！！
-- 在另一个会话中再删除1条数据

登录后复制

plain 复制代码 
# Session1
# 再删除一条数据
 MySQL  localhost:3306 ssl  xiaml  SQL > DELETE FROM accounts WHERE account_id = 9;
Query OK, 1 row affected (0.0028 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL > select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|         10 | 2000.00 |
+------------+---------+
2 rows in set (0.0005 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL >

登录后复制

plain 复制代码 
# Session2
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)
mysql> 
-- 此时并不建立快照,此时对事务而言，数据与实际表完全一致。5行数据。但是别查询！！
-- 在另一个会话中删除2条数据
mysql> SET @name := 'xiamingliang';
Query OK, 0 rows affected (0.00 sec)

mysql>
-- 仅仅在事务中创建一个变量，不对数据进行任何形式的查询与变更动作！！
-- 在另一个会话中再删除1条数据
mysql> select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|         10 | 2000.00 |
+------------+---------+
2 rows in set (0.00 sec)

mysql>
-- 在另一个会话中再删除1条数据

登录后复制

plain 复制代码 
# Session1
# 再删除一条数据
 MySQL  localhost:3306 ssl  xiaml  SQL > DELETE FROM accounts WHERE account_id = 10;
Query OK, 1 row affected (0.0037 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL > select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
+------------+---------+
1 row in set (0.0013 sec)
 MySQL  localhost:3306 ssl  xiaml  SQL >

登录后复制

plain 复制代码 
# Session2
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)
mysql> 
-- 此时并不建立快照,此时对事务而言，数据与实际表完全一致。5行数据。但是别查询！！
-- 在另一个会话中删除2条数据
mysql> SET @name := 'xiamingliang';
Query OK, 0 rows affected (0.00 sec)

mysql>
-- 仅仅在事务中创建一个变量，不对数据进行任何形式的查询与变更动作！！
-- 在另一个会话中再删除1条数据
mysql> select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|         10 | 2000.00 |
+------------+---------+
2 rows in set (0.00 sec)

mysql>
-- 在另一个会话中再删除1条数据；此时新的快照分支就形成了
mysql> select * from accounts;
+------------+---------+
| account_id | balance |
+------------+---------+
|          4 |  500.00 |
|         10 | 2000.00 |
+------------+---------+
2 rows in set (0.00 sec)

mysql>
-- 因为快照已建立，因此，对于事务来说时间就凝固在那一刻了；其他会话的改变对凝固状态下的数据无影响。

这再次印证了；只要在事务开始后以任何形式观察过数据，那么从这一刻开始新的分支就形成了；真的很像薛定谔的猫和平行宇宙的感觉。

相关推荐
ly768920 分钟前
PostgreSQL 执行计划深读：从 EXPLAIN 输出到代价模型驱动的 SQL 改写
数据库·sql·postgresql·explain·执行计划·代价模型
Python自动化直播40 分钟前
自动化笔记：素材管理、命名、轮换的几条土办法
linux·运维·数据库
xiaomuzuirenzhen42 分钟前
2027校招ERP实施顾问：大数据管理与应用专业如何用SQL、BI证明业务能力
大数据·数据库
eleven_4u1 小时前
MySQL深分页如何处理
mysql
底层玩家老张1 小时前
从副本集到分片：百亿级文档数据的KES架构边界
数据库·分布式架构·分片·架构选型·文档数据库
ss2731 小时前
AI时代首先数据库-PostgreSQL实战笔记 | 16 PostgreSQL子查询与嵌套查询（下）
数据库·笔记·postgresql
川石课堂软件测试1 小时前
涨薪技术|0到1学会性能测试第8课-Analysis分析图
服务器·数据库·python·sql·jmeter·mysql·容器
SelectDB技术团队1 小时前
云数仓成本结构拆解：五层计费模型与 Apache Doris 托管形态对照
大数据·数据库·elk·全文检索·snowflake
我命由我123452 小时前
SQL 检测脚本
java·数据库·sql·功能测试·单元测试·压力测试·可用性测试
Zenova EdgeOS2 小时前
工业网关数据全链路加密实战：从传输、静态数据到密钥轮
数据库·oracle·边缘计算·工业网关
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02如何新建文件夹？ 电脑新建文件夹的4种方法03「全语录+省流版」邵艾伦 × 孙宇晨：聊风口、聊个人IP、聊年轻人如何抓住 AI 时代的机会04GitHub 镜像站点05历年考研数学一、数学二、数学三真题试卷及答案PDF06几个好用的ip纯净度检测网站07苹果iPA游戏软件资源下载网站08蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接09Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）10昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战