
准备工作
<img src"../../../img/1691584300916.jpg" alt"1691584300916" style"zoom: 50%;" / 如果对 MySQL 加锁机制比较熟悉的同学,应该一眼就能看出会发生死锁,但是具体加了什么锁而导致死锁,是需要我们具体分析的。 接下来,就跟聊聊上面两个事务执行 SQL 语句的过程中,加了什么锁,从而导致死锁的。 ...

<img src"../../../img/1691584300916.jpg" alt"1691584300916" style"zoom: 50%;" / 如果对 MySQL 加锁机制比较熟悉的同学,应该一眼就能看出会发生死锁,但是具体加了什么锁而导致死锁,是需要我们具体分析的。 接下来,就跟聊聊上面两个事务执行 SQL 语句的过程中,加了什么锁,从而导致死锁的。 ...

说个很早之前自己遇到过数据库死锁问题。 有个业务主要逻辑就是新增订单、修改订单、查询订单等操作。然后因为订单是不能重复的,所以当时在新增订单的时候做了幂等性校验,做法就是在新增订单记录之前,先通过 select ... for update 语句查询订单是否存在,如果不存在才插入订单记录。 而正是因为这样的操作,当业务量很大的时候,就可能会出现死锁。 接下...

面试官反问的大概意思是,MySQL 记录锁+间隙锁可以防止删除操作而导致的幻读吗? 答案是可以的。 接下来,通过几个小实验来证明这个结论吧,顺便再帮大家复习一下记录锁+间隙锁 接下来,来验证「 MySQL 记录锁+间隙锁可以防止删除操作而导致的幻读问题」的结论。 实验环境:MySQL 8.0 版本,可重复读隔离级。 ...

大概就是,在线上执行一条 update 语句修改数据库数据的时候,where 条件没有带上索引,导致业务直接崩了,被老板教训了一波 这次我们就来看看: 为什么会发生这种的事故? 又该如何避免这种事故的发生? 说个前提,接下来说的案例都是基于 InnoDB 存储引擎,且事务的隔离级别是可重复读。 InnoDB 存储引擎的默认事务隔离级别是「可重复读...

这次我以 MySQL 8.0.26 版本,在可重复读隔离级别之下,做了几个实验,让大家了解了唯一索引和非唯一索引的行级锁的加锁规则。 我这里总结下, MySQL 行级锁的加锁规则。 唯一索引等值查询: 当查询的记录是「存在」的,在索引树上定位到这一条记录后,将该记录的索引中的 nextkey lock 会退化成「记录锁」。 当查询的记录是「不存在」的,...

共享锁(也称为读锁)和独占锁(也称为写锁)是并发控制中常用的两种锁机制,用于管理多个线程或进程对共享资源的访问。这些锁有助于确保数据一致性、避免竞争条件和维护并发操作的正确性。 1. 共享锁(Shared Lock / Read Lock) 共享锁允许多个线程或进程同时获得锁,并且不会阻止其他线程获得相同的共享锁。它主要用于读操作,多个线程可以同时读取共享资源,不会相互干...

先直接说结论: <img src"../../../img/image20230808221729879.png" alt"image20230808221729879" style"zoom:80%;" / 要弄明白这个,我们得要深入 count 的原理,以下内容基于常用的 innodb 存储引擎来说明。 count() 是一个聚合函数,函数的...

「题目1 」的数据库表如下,id 是主键索引,name 是二级索引,其他字段都是非索引字段。 这四条模糊匹配的查询语句,第一条和第二条都会走索引扫描,而且都是选择扫描二级索引,因为是根据非主键索引扫描的,我贴个第二条查询语句的执行计划结果图: 而第三和第四条会发生索引失效,执行计划的结果 type ALL,代表了全表扫描。 ...

我们先来看看索引存储结构长什么样?因为只有知道索引的存储结构,才能更好的理解索引失效的问题。 索引的存储结构跟 MySQL 使用哪种存储引擎有关,因为存储引擎就是负责将数据持久化在磁盘中,而不同的存储引擎采用的索引数据结构也会不相同。 MySQL 默认的存储引擎是 InnoDB,它采用 B+Tree 作为索引的数据结构,至于为什么选择 B+ 树作为索引的数据结构 ,详...

建一张表: 插入一条数据: 利用 MySQL 伪列 rownum 设置伪列起始点为 1 运行下面的 sql,连续执行 20 次,就是 2 的 20 次方约等于 100w 的数据;执行 23 次就是 2 的 23 次方约等于 800w , 如此下去即可实现千万测试数据的插入。 如果不想翻倍翻倍的增加数据,而是想少量,少量的增加,有个技巧,就是在 SQL 的后面增加 wh...