mysql中的事务与隔离

最新推荐文章于 2022-01-11 10:43:08 发布
最新推荐文章于 2022-01-11 10:43:08 发布
阅读量186 收藏
点赞数
分类专栏： 数据库 文章标签： mysql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_42432352/article/details/106348340
版权

在 MySQL 中，事务其实是一个最小的不可分割的工作单元。事务能够 保证一个业务的完整性 。

比如银行转账：

-- a给b转100元
UPDATE user set money = money - 100 WHERE name = 'a';
UPDATE user set money = money + 100 WHERE name = 'b';

在实际项目中，假设只有一条 SQL 语句执行成功，而另外一条执行失败了，就会出现数据前后不一致。
因此，在执行多条有关联 SQL 语句时，事务可能会要求这些 SQL 语句要么同时执行成功，要么就都执行失败。

如何控制事务 - COMMIT / ROLLBACK

在 MySQL 中，事务的自动提交状态默认是开启的。

-- 查询事务的自动提交状态
SELECT @@AUTOCOMMIT;
+--------------+
| @@AUTOCOMMIT |
+--------------+
|            1 |
+--------------+

自动提交的作用：当我们执行一条 SQL 语句的时候，其产生的效果就会立即体现出来，且不能回滚。
什么是回滚？举个例子：

CREATE DATABASE bank;
USE bank;
CREATE TABLE user (
    id INT PRIMARY KEY,
    name VARCHAR(20),
    money INT
);

INSERT INTO user VALUES (1, 'a', 1000);

SELECT * FROM user;
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |  1000 |
+----+------+-------+

可以看到，在执行插入语句后数据立刻生效，原因是 MySQL 中的事务自动将它提交到了数据库中。那么所谓回滚的意思就是，撤销执行过的所有 SQL 语句，使其回滚到最后一次提交 数据时的状态。

在 MySQL 中使用 ROLLBACK 执行回滚：

-- 回滚到最后一次提交
ROLLBACK;
SELECT * FROM user;
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |  1000 |
+----+------+-------+

-- 由于所有执行过的 SQL 语句都已经被提交过了，所以数据并没有发生回滚。那如何让数据可以发生回滚？

-- 关闭自动提交
SET AUTOCOMMIT = 0;

-- 查询自动提交状态
SELECT @@AUTOCOMMIT;
+--------------+
| @@AUTOCOMMIT |
+--------------+
|            0 |
+--------------+

将自动提交关闭后，测试数据回滚：

INSERT INTO user VALUES (2, 'b', 1000);

-- 关闭 AUTOCOMMIT 后，数据的变化是在一张虚拟的临时数据表中展示，
-- 发生变化的数据并没有真正插入到数据表中。
SELECT * FROM user;
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |  1000 |
|  2 | b    |  1000 |
+----+------+-------+

-- 数据表中的真实数据其实还是：
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |  1000 |
+----+------+-------+

-- 由于数据还没有真正提交，可以使用回滚
ROLLBACK;

-- 再次查询
SELECT * FROM user;
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |  1000 |
+----+------+-------+

那如何将虚拟的数据真正提交到数据库中？使用 COMMIT :

INSERT INTO user VALUES (2, 'b', 1000);
-- 手动提交数据（持久性），
-- 将数据真正提交到数据库中，执行后不能再回滚提交过的数据。
COMMIT;

-- 提交后测试回滚
ROLLBACK;

-- 再次查询（回滚无效了）
SELECT * FROM user;
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |  1000 |
|  2 | b    |  1000 |
+----+------+-------+

总结

  1. 自动提交

    • 查看自动提交状态：SELECT @@AUTOCOMMIT ；

    • 设置自动提交状态：SET AUTOCOMMIT = 0 。

  2. 手动提交

    @@AUTOCOMMIT = 0 时，使用 COMMIT 命令提交事务。

  3. 事务回滚

    @@AUTOCOMMIT = 0 时，使用 ROLLBACK 命令回滚事务。

事务的实际应用，让我们再回到银行转账项目：

-- 转账
UPDATE user set money = money - 100 WHERE name = 'a';
-- 到账
UPDATE user set money = money + 100 WHERE name = 'b';
SELECT * FROM user;
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |   900 |
|  2 | b    |  1100 |
+----+------+-------+

这时假设在转账时发生了意外，就可以使用 ROLLBACK 回滚到最后一次提交的状态：

-- 假设转账发生了意外，需要回滚。
ROLLBACK;

SELECT * FROM user;
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |  1000 |
|  2 | b    |  1000 |
+----+------+-------+

这时我们又回到了发生意外之前的状态，也就是说，事务给我们提供了一个可以反悔的机会。假设数据没有发生意外，这时可以手动将数据真正提交到数据表中：COMMIT 。

手动开启事务 - BEGIN / START TRANSACTION

事务的默认提交被开启 ( @@AUTOCOMMIT = 1 ) 后，此时就不能使用事务回滚了。但是我们还可以手动开启一个事务处理事件，使其可以发生回滚：

-- 使用 BEGIN 或者 START TRANSACTION 手动开启一个事务
-- START TRANSACTION;
BEGIN;
UPDATE user set money = money - 100 WHERE name = 'a';
UPDATE user set money = money + 100 WHERE name = 'b';

-- 由于手动开启的事务没有开启自动提交，
-- 此时发生变化的数据仍然是被保存在一张临时表中。
SELECT * FROM user;
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |   900 |
|  2 | b    |  1100 |
+----+------+-------+

-- 测试回滚
ROLLBACK;

SELECT * FROM user;
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |  1000 |
|  2 | b    |  1000 |
+----+------+-------+

仍然使用 COMMIT 提交数据，提交后无法再发生本次事务的回滚。

BEGIN;
UPDATE user set money = money - 100 WHERE name = 'a';
UPDATE user set money = money + 100 WHERE name = 'b';

SELECT * FROM user;
+----+------+-------+
| id | name | money |
+----+------+-------+
|  1 | a    |   900 |
|  2 | b    |  1100 |
+----+------+-------+

-- 提交数据
COMMIT;

-- 测试回滚（无效，因为表的数据已经被提交）
ROLLBACK;

set autocommit=0,和start transaction（begin）区别：
set autocommit=0,
当前session禁用自动提交事物，自此句执行以后，每个SQL语句或者语句块所在的事务都需要显示"commit"才能提交事务。

start transaction
指的是启动一个新事务。
在默认的情况下，MySQL从自动提交（autocommit）模式运行，这种模式会在每条语句执行完毕后把它作出的修改立刻提交给数据库并使之永久化。事实上，这相当于把每一条语句都隐含地当做一个事务来执行。如果你想明确地执行事务，需要禁用自动提交模式并告诉MySQL你想让它在何时提交或回滚有关的修改。

一、mysql事务四大特性ACID

事务就是一组原子性的SQL查询，或者说一个独立的工作单元。如果数据库引擎能够成功地对数据应用该组查询的全部语句，那么就执行该组查询。如果其中任何一条语句因为崩溃或其他原因无法执行，那么所有语句都不会执行。也就是说，事务内的语句，要么全部执行成功，要么全部执行失败。

原子性、一致性、隔离性、持久性

  • 原子性：即一个事务必须视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作。
  • 一致性：
    1. 事务的隔离执行必须保证数据库的一致性。
    2. 事务开始前，数据库处于一致性的状态；事务结束后，数据库必须仍处于一致性状态。
    3. 数据库的一致性状态由用户来负责。
    4. 如银行转帐，转帐前后两个帐户金额之和应保持不变。
  • 隔离性：
    1. 系统必须保证事务不受其它并发执行事务的影响。
    2. 对任何一对事务T1，T2，在T1看来，T2要么在T1开始之前已经结束，要么在T1完成之后再开始执行。
    3. 隔离性通过并发控制机制实现。
  • 持久性：
    1. 一个事务一旦提交之后，它对数据库的影响必须是永久的。
    2. 系统发生故障不能改变事务的持久性。
    3. 持久性通过恢复机制实现。

二、事务的隔离级别

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为可重复读(Repeatable Read)。

在这里插入图片描述
查看当前数据库的默认隔离级别：

-- MySQL 8.x, GLOBAL 表示系统级别，不加表示会话级别。
系统级别：
SELECT @@GLOBAL.TRANSACTION_ISOLATION;
会话级别：
SELECT @@TRANSACTION_ISOLATION;
+--------------------------------+
| @@GLOBAL.TRANSACTION_ISOLATION |
+--------------------------------+
| REPEATABLE-READ                | -- MySQL的默认隔离级别，可以重复读。
+--------------------------------+

-- MySQL 5.x
SELECT @@GLOBAL.TX_ISOLATION;
SELECT @@TX_ISOLATION;

修改隔离级别：

-- 设置系统隔离级别，LEVEL 后面表示要设置的隔离级别 (READ UNCOMMITTED)。
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

-- 查询系统隔离级别，发现已经被修改。
SELECT @@GLOBAL.TRANSACTION_ISOLATION;
+--------------------------------+
| @@GLOBAL.TRANSACTION_ISOLATION |
+--------------------------------+
| READ-UNCOMMITTED               |
+--------------------------------+
读未提交 ----导致----》脏读

测试 READ UNCOMMITTED ( 读未提交 ) 的隔离性：

INSERT INTO user VALUES (3, '小明', 1000);
INSERT INTO user VALUES (4, '淘宝店', 1000);

SELECT * FROM user;
+----+-----------+-------+
| id | name      | money |
+----+-----------+-------+
|  1 | a         |   900 |
|  2 | b         |  1100 |
|  3 | 小明      |  1000 |
|  4 | 淘宝店    |  1000 |
+----+-----------+-------+

-- 开启一个事务操作数据
-- 假设小明在淘宝店买了一双800块钱的鞋子：
START TRANSACTION;
UPDATE user SET money = money - 800 WHERE name = '小明';
UPDATE user SET money = money + 800 WHERE name = '淘宝店';

-- 然后淘宝店在另一方查询结果，发现钱已到账。
SELECT * FROM user;
+----+-----------+-------+
| id | name      | money |
+----+-----------+-------+
|  1 | a         |   900 |
|  2 | b         |  1100 |
|  3 | 小明      |   200 |
|  4 | 淘宝店    |  1800 |
+----+-----------+-------+

由于小明的转账是在新开启的事务上进行操作的，而该操作的结果是可以被其他事务（另一方的淘宝店）看见的，因此淘宝店的查询结果是正确的，淘宝店确认到账。但就在这时，如果小明在它所处的事务上又执行了 ROLLBACK 命令，会发生什么？

-- 小明所处的事务
ROLLBACK;

-- 此时无论对方是谁，如果再去查询结果就会发现：
SELECT * FROM user;
+----+-----------+-------+
| id | name      | money |
+----+-----------+-------+
|  1 | a         |   900 |
|  2 | b         |  1100 |
|  3 | 小明      |  1000 |
|  4 | 淘宝店    |  1000 |
+----+-----------+-------+

这就是所谓的脏读，一个事务读取到另外一个事务还未提交的数据。这在实际开发中是不允许出现的。

读已提交 ----导致----》 不可重复读

消除了脏读

把隔离级别设置为 READ COMMITTED ：

SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT @@GLOBAL.TRANSACTION_ISOLATION;
+--------------------------------+
| @@GLOBAL.TRANSACTION_ISOLATION |
+--------------------------------+
| READ-COMMITTED                 |
+--------------------------------+

这样，再有新的事务连接进来时，它们就只能查询到已经提交过的事务数据了。但是对于当前事务来说，它们看到的还是未提交的数据(相当于本地缓存)，例如：

-- 正在操作数据事务（当前事务）
START TRANSACTION;
UPDATE user SET money = money - 800 WHERE name = '小明';
UPDATE user SET money = money + 800 WHERE name = '淘宝店';

-- 虽然隔离级别被设置为了 READ COMMITTED，但在当前事务中，
-- 它看到的仍然是数据表中临时改变数据，而不是真正提交过的数据。
SELECT * FROM user;
+----+-----------+-------+
| id | name      | money |
+----+-----------+-------+
|  1 | a         |   900 |
|  2 | b         |  1100 |
|  3 | 小明      |   200 |
|  4 | 淘宝店    |  1800 |
+----+-----------+-------+


-- 假设此时在远程开启了一个新事务，连接到数据库。
$ mysql -u root -p12345612

-- 此时远程连接查询到的数据只能是已经提交过的
SELECT * FROM user;
+----+-----------+-------+
| id | name      | money |
+----+-----------+-------+
|  1 | a         |   900 |
|  2 | b         |  1100 |
|  3 | 小明      |  1000 |
|  4 | 淘宝店    |  1000 |
+----+-----------+-------+

但是这样还有问题，那就是假设一个事务在操作数据时，其他事务干扰了这个事务的数据。例如：

-- 小张在查询数据的时候发现：
SELECT * FROM user;
+----+-----------+-------+
| id | name      | money |
+----+-----------+-------+
|  1 | a         |   900 |
|  2 | b         |  1100 |
|  3 | 小明      |   200 |
|  4 | 淘宝店    |  1800 |
+----+-----------+-------+

-- 在小张求表的 money 平均值之前，小王做了一个操作：
START TRANSACTION;
INSERT INTO user VALUES (5, 'c', 100);
COMMIT;

-- 此时表的真实数据是：
SELECT * FROM user;
+----+-----------+-------+
| id | name      | money |
+----+-----------+-------+
|  1 | a         |   900 |
|  2 | b         |  1100 |
|  3 | 小明      |  1000 |
|  4 | 淘宝店    |  1000 |
|  5 | c         |   100 |
+----+-----------+-------+

-- 这时小张再求平均值的时候，就会出现计算不相符合的情况：
SELECT AVG(money) FROM user;
+------------+
| AVG(money) |
+------------+
|  820.0000  |
+------------+

虽然 READ COMMITTED 让我们只能读取到其他事务已经提交的数据，但还是会出现问题，就是在读取同一个表的数据时，可能会发生前后不一致的情况。这被称为不可重复读现象 ( READ COMMITTED ) 。

可重复读 ----导致----》幻读

将隔离级别设置为 REPEATABLE READ ( 可被重复读 ) :
（消除了上面的不可重复读）

SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT @@GLOBAL.TRANSACTION_ISOLATION;
+--------------------------------+
| @@GLOBAL.TRANSACTION_ISOLATION |
+--------------------------------+
| REPEATABLE-READ                |
+--------------------------------+

测试 REPEATABLE READ ，假设在两个不同的连接上分别执行 START TRANSACTION :

-- 小张 - 成都
START TRANSACTION;
INSERT INTO user VALUES (6, 'd', 1000);

-- 小王 - 北京
START TRANSACTION;

-- 小张 - 成都
COMMIT;

当前事务开启后，没提交之前，查询不到，提交后可以被查询到。但是，在提交之前其他事务被开启了，那么在这条事务线上，就不会查询到当前有操作事务的连接。相当于开辟出一条单独的线程。

无论小张是否执行过 COMMIT ，在小王这边，都不会查询到小张的事务记录，而是只会查询到自己所处事务的记录：

SELECT * FROM user;
+----+-----------+-------+
| id | name      | money |
+----+-----------+-------+
|  1 | a         |   900 |
|  2 | b         |  1100 |
|  3 | 小明      |  1000 |
|  4 | 淘宝店    |  1000 |
|  5 | c         |   100 |
+----+-----------+-------+

这是因为小王在此之前开启了一个新的事务 ( START TRANSACTION ) ，那么在他的这条新事务的线上，跟其他事务是没有联系的，也就是说，此时如果其他事务正在操作数据，它是不知道的。

然而事实是，在真实的数据表中，小张已经插入了一条数据。但是小王此时并不知道，也插入了同一条数据，会发生什么呢？

INSERT INTO user VALUES (6, 'd', 1000);
-- ERROR 1062 (23000): Duplicate entry '6' for key 'PRIMARY'

报错了，操作被告知已存在主键为 6 的字段。这种现象也被称为幻读，一个事务提交的数据，不能被其他事务读取到。
事务a和事务b 同时操作一张表，事务a提交的数据，也不能被事务b读到，就可以造成幻读，虽然消除了不可重复读。

就是说，在别人事务a提交前，自己开启了一个事务b，那么不管别人提交还是没提交，自己去查表都是看不到别人事务a所做的改变，这样就消除了不可重复读,但是数据库实际上还是变了，就有可能会报错，导致幻读。

串行化（消除了上面的幻读）

顾名思义，就是所有事务的写入操作全都是串行化的。什么意思？把隔离级别修改成 SERIALIZABLE :

SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT @@GLOBAL.TRANSACTION_ISOLATION;
+--------------------------------+
| @@GLOBAL.TRANSACTION_ISOLATION |
+--------------------------------+
| SERIALIZABLE                   |
+--------------------------------+

还是拿小张和小王来举例：

-- 小张 - 成都
START TRANSACTION;

-- 小王 - 北京
START TRANSACTION;

-- 开启事务之前先查询表，准备操作数据。
SELECT * FROM user;
+----+-----------+-------+
| id | name      | money |
+----+-----------+-------+
|  1 | a         |   900 |
|  2 | b         |  1100 |
|  3 | 小明      |  1000 |
|  4 | 淘宝店    |  1000 |
|  5 | c         |   100 |
|  6 | d         |  1000 |
+----+-----------+-------+

-- 发现没有 7 号王小花，于是插入一条数据：
INSERT INTO user VALUES (7, '王小花', 1000);

此时会发生什么呢？由于现在的隔离级别是 SERIALIZABLE ( 串行化 ) ，串行化的意思就是：假设把所有的事务都放在一个串行的队列中，那么所有的事务都会按照固定顺序执行，执行完一个事务后再继续执行下一个事务的写入操作 ( 这意味着队列中同时只能执行一个事务的写入操作 ) 。

根据这个解释，小王在执行事务（此处插入数据）时，就会出现等待状态（什么也不显示，什么也干不了），直到小张执行 ‘COMMIT’ 结束它所处的事务，或者出现等待超时。
串行化的问题是 性能特差 mysql默认的隔离级别是 REPEATABLE—READ

GankOoo
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
MYSQL事务隔离与锁
06-22
本套课程主要是对mysql的事务隔离级别以及锁相关知识进行深入讲解其中包括：mysql四大特性的深入理解、四种隔离级别的实现原理、一致性读的实现原理、全局锁、表锁、行锁，间隙锁的介绍与分析，对于难点和重点会使用...
Mysql事务隔离级别原理实例解析
09-08
MySQL事务隔离级别是数据库管理系统中确保事务之间正确交互的重要机制，它主要涉及到四个级别：读未提交（READ UNCOMMITTED）、读已提交（READ COMMITTED）、可重复读（REPEATABLE READ）和串行化（SERIALIZABLE）。...
mysql中autocommit，start transaction和begin/commit的异同
yxg520s的博客
01-11 2803
相同点：这三个关键字都与mysql的事务相关，直接操纵事务的语句， 不同点： （1）他们的作用范围不一样。 AUTOCOMMIT是数据库innodb引擎级别的属性，对于start transaction和begin/end而言是全局的，一旦使用SET AUTOCOMMIT=0 禁止自动提交，则在这个数据库内部的所有事务都不会自动提交，除非你手动的为每一个事务执行了commit或者rollback语句；而start transaction和begin/commit只能控制某一个事务。 （2）优先级不同..
MYSQL关于 autocommit 设置
LGD200008的博客
01-14 1万+
查看 MySQL 客户端的事务提交方式命令：select @@autocommit; 修改 MySQL 客户端的事务提交方式为手动提交命令：set @@autocommit = 0; （注：0 表示手动提交，即使用 MySQL 客户端执行 SQL 命令后必须使用commit命令执行事务，否则所执行的 SQL 命令无效，如果想撤销事务则使用 rollback 命令。1 表示自动提交，即在 MyS
mysql中 SET autocommit=0 与 START TRANSACTION 的区别
aben_sky的专栏
07-15 8285
在MySQL中, SET autocommit=0;指事务非自动提交，自此句命令执行以后，每个SQL语句或者语句块所在的事务都需要显式调用commit才能提交事务。 ...
set autocommit = 0与 set autocommit =1 的区别
weixin_44133711的博客
08-25 2704
set autocommit = 0 时 第一种情况： start TRANSACTION; update users set `password` = 9 where id = 1; ROLLBACK; select * from users; 第二种： update users set `password` = 9 where id = 1; ROLLBACK; select * from users; 上面两种事物都是可以执行成功的 set autocommit = 1 时 第一种： start T
set autocommit=0 和 start transaction区别
面朝大海，春暖花开
05-01 694
set autocommit=0 和 start transaction区别 相同之处 set autocommit=0 是显示设置手动提交事务 start transaction 是隐式的设置手动提交事务 不同之处 start transaction To disable autocommit mode implicitly for a single series of statements, use the START TRANSACTION statement: 对于 start transa
MySQL set autocommit = 0或1分别什么啊,哪个是自动提交啊
waiwai021的博客
07-29 2万+
MySQL set autocommit = 0或1分别什么啊,哪个是自动提交啊 autocoomit是事务，根据mysql的文档如果等于1是立即提交。但在transction中只有遇到commit或rollback才提交
MySQL数据库事务隔离级别详解
12-16
MySQL数据库的事务隔离级别是数据库管理系统中用于控制事务处理中并发操作的重要机制。在多用户同时访问数据库的情况下，事务隔离级别能够确保数据的一致性和完整性，避免并发操作带来的各种问题，如脏读、不可重复...
MySQL数据库事务隔离级别
02-26
数据库隔离级别有四种，应用《高性能mysql》一书中的说明：然后说说修改事务隔离级别的方法：1.全局修改，修改mysql.ini配置文件，在最后加上#可选参数有：READ-UNCOMMITTED,READ-COMMITTED,REPEATABLE-READ,...
set autocommit=0为何不起作用及对于事务隔离性的理解
qiurongfeng的博客
04-22 4490
set autocommit=0为何不起作用及对于事务隔离性的理解set autocommit小实验思考tipsset autocommit 和 START TRANSACTION为什么不推荐set autocommit=0如何避免长事务对业务的影响？ set autocommit 指事务非自动提交，此句执行以后，每个SQL语句或者语句块所在的事务都需要显示"commit"才能提交事务。 小实验 ...
mysql中set autocommit=0与start transaction区别
caomiao2006的专栏
07-31 4705
set autocommit=0, 当前session禁用自动提交事物，自此句执行以后，每个SQL语句或者语句块所在的事务都需要显示"commit"才能提交事务。 start transaction 指的是启动一个新事务。        在默认的情况下，MySQL从自动提交（autocommit）模式运行，这种模式会在每条语句执行完毕后把它作出的修改立刻提交给数据库并使之永久化。事实
如何解决set autocommit=0出不来效果的问题？
baidu_36681154的博客
10-31 4018
第一步 设set  set autocommit=0；如图所示   第二步   增 第三步  打开第二窗口查，看结果 第四步  第四步在第一个窗口加入commit,在第二窗口查看结果 ...
mysql中的set autocommit =0
热门推荐
无心云
08-30 4万+
<br />今天掉到这个坑里了，mysql如果开了set autocommit=0，那么所有的语句一定是在一个事务里，在这种情况下，如果使用连接池，并且在查询之前没有rollback或者set autocommit=1，那么你就杯具了。因为根据mysql的默认事务级别，一致性读，你永远也取不到这个事务被开户前的数据。另外一点set autocommit= 0，会自动提交前一个事务，因此正确的作法是rollback, set autocommit =0，完成之后再set autocommit = 1;<br
彻底理解数据库事务
weixin_41469381的博客
04-01 119
转载自：HollisChuang's Blog»彻底理解数据库事务 https://www.hollischuang.com/archives/898 事务 事务(Transaction)，一般是指要做的或所做的事情。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。在计算机术语中，事务通常就是指数据库事务。 概念 一个数据库事务通常包含对数...
什么是数据库事务？
weixin_34060741的博客
02-14 183
什么是数据库事务？事务（transaction）是由一系列操作序列构成的程序执行单元，这些操作要么都做，要么都不做，是一个不可分割的工作单位。数据库事务的四个基本性质（ACID）1. 原子性（Atomicity）事务的原子性是指事务中包含的所有操作要么全做，要么全不做（all or none）。2. 一致性（Consistency）在事务开始以前，数据库处于一致性的状...
mysql中事务隔离
最新发布
06-25
在MySQL中，事务隔离是数据库事务处理中的一个关键概念，它用于控制并发访问数据库时的一致性。事务隔离级别定义了不同用户在同一时间对数据的操作如何互相影响。MySQL提供了几种不同的事务隔离级别： 1. **读未提交（READ UNCOMMITTED）**：这是最低的隔离级别，事务可以读取其他事务未提交的数据，可能导致脏读（读取到的是未提交更新的数据）和幻读（查询结果因其他事务的插入或删除而改变）。 2. **读已提交（READ COMMITTED）**：在此级别，事务只能看到已经提交的变更。这防止了脏读，但仍然可能面临不可重复读（由于其他事务的更新，相同的查询返回不同的结果）。 3. **可重复读（REPEATABLE READ）**：在此模式下，事务在其整个生命周期内不会看到其他事务对其已锁定行的更改，这保证了事务的隔离性和一致性，但是可能出现幻读（如果另一个事务在该事务范围内插入了新行）。 4. **串行化（SERIALIZABLE）**：这是最高的隔离级别，保证了每个事务好像在单独使用数据库一样执行，完全避免了并发冲突，但性能开销最大。 选择哪个隔离级别取决于应用的具体需求。例如，如果对数据一致性要求很高，会选择可重复读或串行化，但如果希望提高并发性能，可能会接受较低级别的隔离，但可能需要更复杂的并发控制策略。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值