两个事务并发写，能保证数据唯一吗？

旧城等待， 2023-09-23 16:52 108阅读 0赞

![format_png][]

哟，又是我小白。最近有点高产了。

连我自己都害怕了。

![format_png 1][]

直接进入正题吧。

### 两个事务并发写，能保证数据唯一吗？ ###

我先来解释下标题讲的是个啥。

我们假设有这么一个用户注册的场景。用户并发请求注册新用户。

你有一张数据库表，也就是下面的user表。

![format_png 2][]

产品经理要求用户和用户之间，电话号码不能重复，为了保证这一点。我们想到了先查一下数据库，再判断一下，如果存在，就退出，否则插入一条数据。类似下面这样的伪代码。

select user where phone_no =2;  // 查询sql
    if (user 存在) {
    		return 
    } else {
      insert user;   // 插入sql
    }
    复制代码

但这是两条sql语句，先执行查询sql，判断后再决定要不要执行插入sql。每次用户注册的时候都会执行这么一段逻辑。

那如果，此时有多个用户在做操作，就会**并发**执行这段逻辑。

如果都并发执行，第一条sql语句执行完之后，都会发现没有用户存在。此时都执行了插入，这样就出现了两条一样的数据才对。

所以，有人就想了，这**两条sql语句逻辑应该是一个整体**，不应该拆开，于是就想到了事务，通过事务把这两个sql作为**一个整体**，要么一起执行，要么都回滚。

这正是数据库ACID里的A（Atomicity），原子性的完美体现啊。

![format_png 3][]

伪代码类似下面这样。

begin;
    select user where phone_no =2;  // 查询sql
    if (user 存在) {
    		return 
    } else {
      insert user;   // 插入sql
    }
    commit;
    复制代码

那么问题来了，**这段逻辑，并发执行，能保证数据唯一？**

**当然是不能。**

事务內的多条sql语句，确实是原子的，要么一起成功，要么一起失败，这没错，但跟这个场景没什么太大关系。事务是并发执行的，第一个事务执行查询用户，并**不会阻塞**另一个事务查询用户，所以都有可能查到用户不存在，此时两个事务逻辑都判断为用户不存在，然后插入数据库。事务内两条sql都执行成功了，于是就插入了两条一样的数据。

![format_png 4][]

### 怎么保证数据唯一？ ###

那么我们接下来聊聊，怎么保证上面这种场景下，插入的数据是唯一的。方法有很多种，但我们今天只讨论mysql内部的做法，不考虑其他外部中间件（比如redis分布式锁这些）。

#### 唯一索引 ####

通过下面的命令，可以为数据库user表的phone\_no字段加入唯一索引。

ALTER TABLE `user` ADD unique(`phone_no`);
    复制代码

我们执行一条写操作时，比如下面这句，

INSERT INTO `user` (`user_name`, `phone_no`) VALUES('小红', 2);
    复制代码

第一次会插入成功，第二次再执行插入，则会出现报错。

Duplicate entry '2' for key 'phone_no'
    复制代码

含义是phone\_no这个字段是唯一的，加两次phone\_no=2会导致重复。

于是乎回到我们文章开头的场景里，就完美解决了重复插入的问题了。

那么问题来了。

为什么唯一索引能保证数据唯一？

我们看看一句写操作，会经历什么。

![format_png 5][]

首先，mysql作为一个数据库，内部主要分为两层，一层是**server层**，一层是**存储引擎层**（一般是**innodb**）。

server层主要管的是数据库链接，权限校验，以及sql语句校验和优化之类的工作。请求打到存储引擎层，才是真正的查询和更新数据的操作。

大家都知道数据库是持久化存储，且最后都是把数据存到**磁盘**上的。

**那数据库读写是直接读写磁盘数据吗？**

不是，如果直接读写磁盘的话，那就太慢了，为了提升速度。

它在磁盘前面加了一层内存，叫**buffer pool**。它里面有很多细节，但最主要的就是个双向链表，里面放的是一个个数据页，每个数据页的大小默认是 16kb，数据页里面放的就是磁盘的数据。

![format_png 6][]

于是有了这层buffer pool内存，mysql的读和写操作都可以先操作这部分内存，如果想要读写的数据页不在buffer pool里，再跑到磁盘里去捞。由于**读写内存的速度比读写磁盘快得多**。

**所以引擎读写都快多了。**

但这还不够，**很多时候写操作，我的诉求就是把xx更新为xx，或插入xx，数据库光知道这一点就够了，我根本不需要知道数据页原来长什么样子。**

有点抽象？举个例子吧。

比方说我想要把id=1的这条数据的phone\_no字段更新为100，数据库知道这一点就够了，至于这条数据原来phone\_no究竟是等于20，还是30，这根本不重要，反正最后都会变成我想要的phone\_no=100。

也就是说，如果有那么**一块内存**，记录下我准备把数据改成什么样子，然后后续异步慢慢更新到磁盘数据上。那我甚至到不需要在一开始就把这块数据从磁盘读到buffer pool中，按照这个思路，**change buffer**就来了。

![format_png 7][]

于是乎，写加了**普通索引**的数据，它只要把想要写的内容写到change buffer上，就立马结束返回了。后面innodb引擎拿着这个change buffer，再异步读入磁盘数据到内存，将change buffer的数据修改到数据页中，再写回磁盘，这速度就上来了，秒啊。

但这个change buffer，放在**唯一索引**这里就不管用了，毕竟，它得保证数据真的只有一条，那就得去看下数据库里，是不是真的有这条数据。

所以，对于insert场景，普通索引把需求扔到change buffer就完事返回了，而唯一索引需要真的把数据从磁盘读到内存来，看下是不是有重复的，没重复的再插入数据。

这唯一索引，在性能上就输了一截了。

所以回到**唯一索引为什么能保证数据唯一**的问题上，一句话概括就是，**唯一索引会绕过change buffer，确保把磁盘数据读到内存后再判断数据是否存在，不存在才能插入数据，否则报错，以此来保证数据是唯一的。**

#### 总结 ####

*  加唯一索引可以保证数据并发写入时数据唯一，而且最省事省心。
 *  数据库通过引入一层buffer pool内存来提升读写速度，普通索引可以利用change buffer提高数据插入的性能。
 *  唯一索引会绕过change buffer，确保把磁盘数据读到内存后再判断数据是否存在，不存在才能插入数据，否则报错，以此来保证数据是唯一的。

给大家留个问题呗，前面也提到了，**innodb中，利用了change buffer，为普通索引做了加速**。**有没有哪些场景下，change buffer不仅不能给普通索引加速，还起到反作用的呢？**

#### 最后 ####

大家也别笑，文章开头提到的通过开事务来保证数据唯一性的错误操作，其实很容易犯，而且我曾经也遇到过不止一次这样的事情。

做这个操作的人，还会信誓旦旦，言之凿凿的说出他的理解，在我解释了几遍发现无果之后，我选择低头假装思考，然后说："你说的有点道理，我再回去好好想想"，然后默默的为数据表加上唯一索引......

我相信对方肯定已经理解了。那一刻，我感觉我写的不是代码，我写的是人情世故。

![format_png 8][]

**如果文章对你有帮助，欢迎.....**

算了。

[format_png]: https://img-blog.csdnimg.cn/img_convert/b14f2ec8ad8f95409204c3a3619e5456.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/2ad70a9053c1fc57b6b179e48386c6d9.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/e4bf6a2dafa66e360f5ba4efc87c75f0.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/8eb44e125fb6b240656e7875edb08ef5.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/2ba45d95fcf9fc2d91a88fe813498b80.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/6c12ccc3dfce0a16eda207b3b2f03478.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/0e68cbf2c905df6cb35d41d0cdc3ca67.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/63e90a200e9bc5c3594a3c762ceda36c.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/eaf0bb57d1eae8beab5ef0cf01d79bd0.webp?x-oss-process=image/format,png

发表评论取消回复

表情：

评论列表（有 0 条评论，108人围观）

还没有评论，来说两句吧...

相关阅读

相关能写个示例代码吗

当然可以。以下是 Python 中打印 "Hello, World!" 的示例代码: print("Hello, World!") 运行结果将会输出 "Hello,

你的名字/ 2024年03月25日 08:32/ 0 赞/ 89 阅读

相关 volatile的作用是什么？能保证原子性吗？能保证有序性吗？

（1）volatile保证了不同线程之间对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。Volatile关键字会强制将修改的值立

骑猪看日落/ 2023年10月14日 12:15/ 0 赞/ 39 阅读

相关两个事务并发写，能保证数据唯一吗？

![format_png][] 哟，又是我小白。最近有点高产了。连我自己都害怕了。 ![format_png 1][] 直接进入正题吧。两个事务并发写，能保证数

╰+攻爆jí腚メ/ 2023年10月03日 21:40/ 0 赞/ 54 阅读

相关能写个外卖平台的前端页面吗

<p>当然，我可以为您写一个外卖平台的前端页面的示例。请注意，这仅是一个简单的示例，您可以根据您的需求进行修改和完善。</p> <p>如果您使用的是 HTML、

素颜马尾好姑娘i/ 2023年09月25日 16:24/ 0 赞/ 11 阅读

相关 redis的事务能保证ACID属性吗

前言说到事务，我们想到的都是关系型数据库能实现的。在Redis中，其实也有实现事务的方法。但为什么我们都说Redis不支持事务呢？那就要说到我们对事务的要求-ACID了

- 日理万妓/ 2023年09月24日 20:13/ 0 赞/ 121 阅读

相关两个事务并发写，能保证数据唯一吗？

![format_png][] 哟，又是我小白。最近有点高产了。连我自己都害怕了。 ![format_png 1][] 直接进入正题吧。两个事务并发写，能保证数

旧城等待，/ 2023年09月23日 16:52/ 0 赞/ 109 阅读

相关 Linux定时计划保证实例唯一

23 23 (flock -xn /tmp/test.lock -c /bin/bash /etc/openvas/openvas.sh >>/var/log/o

谁践踏了优雅/ 2022年07月13日 14:40/ 0 赞/ 108 阅读

相关 HashSet如何保证元素唯一

hashset基于hashmap去实现，但是hashset如何保证集合内元素是唯一的呢，以下文章接下来去记录一下这个过程。 1.HashSet原理我们使用Set集合都

本是古典何须时尚/ 2022年04月23日 15:54/ 0 赞/ 252 阅读

相关 Flink两阶段提交协议 + Kakfa事务保证端到端唯一 /TwoPhaseCommitSinkFunction / Kafka的幂等性和事务

begin transaction之后：数据先写入broker的内存中（临时目录下的临时文件） precommit开始时：flush到磁盘，关闭该临时文件 commit开始

ゝ一世哀愁。/ 2021年09月25日 04:36/ 0 赞/ 2089 阅读

相关 @Transactional和synchronized能连用吗？能保持事务的一致性吗？

最近开发中遇到幻读现象，大致情况如下，在一秒中多次点击请求一个保存接口，再保存的时候会判断数据库是否已经存在同名的数据，由于请求过于频繁，或者并发过大，第一次请求的数据还...

你的名字/ 2020年11月20日 17:50/ 0 赞/ 727 阅读