扫码关注官方微信

扫码下载APP
返回顶部
首页 > 资讯 > 数据库 >MySQL的在RC和RR模式下的锁
  • 947

0
分享到

MySQL的在RC和RR模式下的锁

2024-04-02 19:04:59 947人浏览 安东尼
摘要

InnoDB的锁机制：数据库使用所是为了支持更好的并发，提供数据的完整性和一致性。InnoDB是一个支持锁的存储引擎，锁的类型有：共享锁（S）、排它锁（X）、意向共享锁（IS）、意向排它锁（IX）。为了支持

InnoDB的锁机制：

数据库使用所是为了支持更好的并发，提供数据的完整性和一致性。InnoDB是一个支持锁的存储引擎，锁的类型有：共享锁（S）、排它锁（X）、意向共享锁（IS）、意向排它锁（IX）。为了支持更好的并发，InnoDB提供了非锁定读：不需要等待访问行上的锁释放，读取行的一个快照。该方法是通过InnoDB的一个特写：mvcC实现的。

InnoDB的锁分类：

  • Record Lock：行锁：单个行记录上的行锁

  • Gap Lock：间隙锁，锁定一个范围，但不包括记录本身

  • Next-Key Lock：Gap+Record Lock，锁定一个范围，并且锁定记录本身



当对无索引的字段进行更新时（RR级别），通过锁主键的方式，来锁住所有记录，RC级别不会锁所有记录。

构建表及初始化数据：

Mysql -uroot -p
USE test;
DROP TABLE IF EXISTS t_none;
CREATE TABLE `t_none` (
  `id` int(11) NOT NULL,
  `mem_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;
INSERT INTO t_none VALUES(1,1),(3,3),(5,5),(9,9),(11,11);

REPEATABLE-READ（RR）默认级别

Session A

Session B

root@localhost[zjkj]:10:53:18>prompt A>>

PROMPT set to 'A>>'

A>>select @@session.tx_isolation;

root@localhost[(none)]:11:02:58>prompt B>>

PROMPT set to 'B>>'

B>>select @@session.tx_isolation;

A>>begin;

Query OK, 0 rows affected (0.00 sec)

B>>begin;

Query OK, 0 rows affected (0.00 sec)

A>>select * from t_none;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      1 |

|  3 |      3 |

|  5 |      5 |

|  9 |      9 |

| 11 |     11 |

+----+--------+

5 rows in set (0.00 sec)

B>>select * from t_none;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      1 |

|  3 |      3 |

|  5 |      5 |

|  9 |      9 |

| 11 |     11 |

+----+--------+

5 rows in set (0.00 sec)


A>> select * from t_none where mem_id=3 for update;

+----+--------+

| id | mem_id |

+----+--------+

|  3 |      3 |

+----+--------+

1 row in set (0.01 sec)



B>>insert into t_none values(2,2);

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

B>>delete from t_none where id=9;

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

show engin inondb status部分输出：

------------

TRANSACTIONS

------------

Trx id counter 10661

Purge done for trx's n:o < 10659 undo n:o < 0 state: running but idle

History list length 351

Total number of lock structs in row lock hash table 2

LIST OF TRANSACTIONS FOR EACH SESSION:

---TRANSACTION 10588, not started

mysql thread id 4, OS thread handle 0x7f6f5085c700, query id 339 localhost root init

show engine innodb status

---TRANSACTION 10660, ACTIVE 17 sec inserting

mysql tables in use 1, locked 1

LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)

MySQL thread id 11, OS thread handle 0x7f6f508de700, query id 338 localhost root update

insert into t_none values(2,2)

------- TRX HAS BEEN WAITING 17 SEC FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 68 page no 3 n bits 72 index `PRIMARY` of table `test`.`t_none` trx id 10660 lock_mode X locks gap before rec insert intention waiting

结论：通过上面很容易的看到，没有通过索引for update时，当进行增删改都会锁住，MySQL内部会通过基于锁默认主键方式，对所有记录加X锁。

下面是RC级别的实验


Read Committed级别（RC）

Session A

Session B

A>>set @@session.tx_isolation="read-committed";

Query OK, 0 rows affected (0.00 sec)

B>>set @@session.tx_isolation="read-committed";

Query OK, 0 rows affected (0.00 sec)

A>>select @@session.tx_isolation;

+------------------------+

| @@session.tx_isolation |

+------------------------+

| READ-COMMITTED         |

+------------------------+

1 row in set (0.00 sec)

B>>select @@session.tx_isolation;

+------------------------+

| @@session.tx_isolation |

+------------------------+

| READ-COMMITTED         |

+------------------------+

1 row in set (0.01 sec)

A>>begin;

Query OK, 0 rows affected (0.00 sec)

B>>begin;

Query OK, 0 rows affected (0.00 sec)

A>>select * from t_none where mem_id=3 for update;

+----+--------+

| id | mem_id |

+----+--------+

|  3 |      3 |

+----+--------+

1 row in set (0.01 sec)



B>>insert into t_none values(2,2);

Query OK, 1 row affected (0.01 sec)


B>>select * from t_none;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      1 |

|  2 |      2 |

|  3 |      3 |

|  5 |      5 |

|  9 |      9 |

| 11 |     11 |

+----+--------+

6 rows in set (0.00 sec

A>>rollback;

Query OK, 0 rows affected (0.00 sec)

B>>rollback;

Query OK, 0 rows affected (0.00 sec)

结论：在RC级别下，事务B是可以进行增删改（除被锁定的记录本身）

  • 非唯一索引+RR/RC

  在RR级别下，InnoDB对于非唯一索引会加Gap Lock（也即锁定一个区间），而在RC级别下无。

构造初始化表及数据：

mysql -uroot -p
USE test;
DROP TABLE IF EXISTS t_idx;
CREATE TABLE `t_idx` (
  `id` int(11) NOT NULL,
  `mem_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
   KEY `idx_mem_id` (`mem_id`)
) ENGINE=InnoDB;
INSERT INTO t_idx VALUES(1,1),(3,3),(5,5),(9,9),(11,11);


REPEATABLE-READ（RR）默认级别（RR模式）

Session A

Session B

root@localhost[(none)]:06:01:59>use test;

root@localhost[zjkj]:10:53:18>prompt A>>

PROMPT set to 'A>>'

root@localhost[(none)]:06:01:59>use test;

root@localhost[(none)]:11:02:58>prompt B>>

PROMPT set to 'B>>'

A>>select @@session.tx_isolation;

+------------------------+

| @@session.tx_isolation |

+------------------------+

| REPEATABLE-READ        |

+------------------------+

1 row in set (0.00 sec)

B>>select @@session.tx_isolation;

+------------------------+

| @@session.tx_isolation |

+------------------------+

| REPEATABLE-READ        |

+------------------------+

1 row in set (0.02 sec)

A>>begin;

Query OK, 0 rows affected (0.00 sec)

B>>begin;

Query OK, 0 rows affected (0.00 sec)

A>>select * from t_idx;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      1 |

|  3 |      3 |

|  5 |      5 |

|  9 |      9 |

| 11 |     11 |

+----+--------+

5 rows in set (0.04 sec)

B>>select * from t_idx;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      1 |

|  3 |      3 |

|  5 |      5 |

|  9 |      9 |

| 11 |     11 |

+----+--------+

5 rows in set (0.00 sec)

A>>select * from t_idx where mem_id=3 for update;

+----+--------+

| id | mem_id |

+----+--------+

|  3 |      3 |

+----+--------+

1 row in set (0.05 sec)



B>>insert into t_idx values(2,2);

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

#问题？这里为什么会出现阻塞呢？

B>>insert into t_idx values(4,4);

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

#问题？这里为什么会出现阻塞呢？

B>>insert into t_idx values(3,3);

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

B>>insert into t_idx values(5,5);

ERROR 1062 (23000): Duplicate entry '5' for key 'PRIMARY'

B>>insert into t_idx values(1,1);

ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'

#######下面插入全部可以######

B>>insert into t_idx values(6,6);

Query OK, 1 row affected (0.00 sec)

B>>insert into t_idx values(7,7);

B>>insert into t_idx values(8,8);

Query OK, 1 row affected (0.01 sec)

B>>insert into t_idx values(12,12);

Query OK, 1 row affected (0.00 sec)


B>>select * from t_idx;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      1 |

|  3 |      3 |

|  5 |      5 |

|  6 |      6 |

|  7 |      7 |

|  8 |      8 |

|  9 |      9 |

| 11 |     11 |

| 12 |     12 |

+----+--------+

9 rows in set (0.00 sec)

show engine inondb status部分输出：

------------

TRANSACTIONS

------------

Trx id counter 11044

Purge done for trx's n:o < 11041 undo n:o < 0 state: running but idle

History list length 372

Total number of lock structs in row lock hash table 5

LIST OF TRANSACTIONS FOR EACH SESSION:

---TRANSACTION 0, not started

MySQL thread id 3, OS thread handle 0x7fd0430df700, query id 47 localhost root init

show engine innodb status

---TRANSACTION 11039, ACTIVE 228 sec inserting

mysql tables in use 1, locked 1

LOCK WAIT 3 lock struct(s), heap size 1248, 3 row lock(s), undo log entries 4

MySQL thread id 1, OS thread handle 0x7fd064099700, query id 45 localhost root update

insert into t_idx values(4,4)

Trx read view will not see trx with id >= 11040, sees < 11038

------- TRX HAS BEEN WAITING 22 SEC FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 70 page no 4 n bits 80 index `idx_mem_id` of table `test`.`t_idx` trx id 11039 lock_mode X locks gap before rec insert intention waitin

结论：通过上面可以看到，通过非唯一索引字段进行更新时，在进行增删改时，有的记录会出现阻塞，为什么会出现阻塞呢？其实就是用到了MySQL的间隙锁。那MySQL这里为什么要用间隙锁呢？目的主要是防止幻读。 那为什么有的记录可以插入有的不可以，因为InnoDB对于行的查询时采用了Next-Key Lock的算法，锁定的是一个范围（GAP）如下：（∞,1]，(1,3]，(3,5]，(5,9]，(9,11]，(11, ∞)。InnoDB对辅助索引下一个键值也要加上Gap Lock，例如上面进行插入2、4、1、3、5时，就可以看出，其实锁住的区间是(1,5)。
Read Committed级别（RC）

Session A

Session B

A>>rollback;

Query OK, 0 rows affected (0.00 sec)

B>>rollback;

Query OK, 0 rows affected (0.00 sec)

A>>set @@session.tx_isolation="read-committed";

Query OK, 0 rows affected (0.00 sec)

B>>set @@session.tx_isolation="read-committed";

Query OK, 0 rows affected (0.00 sec)

A>>select @@session.tx_isolation;

+------------------------+

| @@session.tx_isolation |

+------------------------+

| READ-COMMITTED         |

+------------------------+

1 row in set (0.00 sec)

B>>select @@session.tx_isolation;

+------------------------+

| @@session.tx_isolation |

+------------------------+

| READ-COMMITTED         |

+------------------------+

1 row in set (0.01 sec)

A>>begin;

Query OK, 0 rows affected (0.00 sec)

B>>begin;

Query OK, 0 rows affected (0.00 sec)

A>>select * from t_idx where mem_id=3 for update;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      3 |

|  3 |      3 |

+----+--------+

2 rows in set (0.00 sec)



B>>insert into t_idx values(1,1);

ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'

B>>insert into t_idx values(2,2);

Query OK, 1 row affected (0.00 sec)

B>>insert into t_idx values(3,3);

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

B>>insert into t_idx values(4,4);

Query OK, 1 row affected (0.01 sec)

结论：在RC级别下，事务B是可以进行增删改（除被锁定的记录本身），没有出现间隙锁的现象。


  • 唯一索引+RR/RC

构造初始化表及数据：

mysql -uroot –p
use test;
DROP TABLE IF EXISTS t_pk;
CREATE TABLE `t_pk` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `mem_id` int(11) NOT NULL ,
  PRIMARY KEY (`id`),
  UNIQUE  `uq_mem_id` (`mem_id`)
) ENGINE=InnoDB;
INSERT INTO t_pk VALUES(1,1),(3,3),(5,5),(9,9),(11,11);
REPEATABLE READ（RR级别）

root@localhost[(none)]:10:04:34>use test;

root@localhost[test]:10:04:41>prompt A>>

PROMPT set to 'A>>'

root@localhost[(none)]:10:04:37>use test;

root@localhost[test]:10:04:52>prompt B>>

PROMPT set to 'B>>'

A>>select @@session.tx_isolation;

+------------------------+

| @@session.tx_isolation |

+------------------------+

| REPEATABLE-READ        |

+------------------------+

1 row in set (0.01 sec)

B>>select @@session.tx_isolation;

+------------------------+

| @@session.tx_isolation |

+------------------------+

| REPEATABLE-READ        |

+------------------------+

1 row in set (0.00 sec)

A>>begin;

Query OK, 0 rows affected (0.00 sec)

B>>begin;

Query OK, 0 rows affected (0.00 sec)

A>>select * from t_pk;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      1 |

|  3 |      3 |

|  5 |      5 |

|  9 |      9 |

| 11 |     11 |

+----+--------+

5 rows in set (0.00 sec)

B>>select * from t_pk;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      1 |

|  3 |      3 |

|  5 |      5 |

|  9 |      9 |

| 11 |     11 |

+----+--------+

5 rows in set (0.00 sec)

A>>select * from t_pk where mem_id=3 for update;

+----+--------+

| id | mem_id |

+----+--------+

|  3 |      3 |

+----+--------+

1 row in set (0.00 sec)



B>>insert into t_pk values(2,2);

Query OK, 1 row affected (0.00 sec)

B>>insert into t_pk values(4,4);

Query OK, 1 row affected (0.00 sec)

B>>insert into t_pk values(3,3);

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

B>>insert into t_pk values(5,5);

ERROR 1062 (23000): Duplicate entry '5' for key 'PRIMARY'

B>>insert into t_pk values(7,7);

Query OK, 1 row affected (0.00 sec)

结论：从这里可以看到，对于基于唯一索引的更新，MySQL只是锁定了记录本身。

同理，我们可以推导出主键也是一样的。实验的话我就略了，其实就是将上面的mem_id改成id即可。

基于主键的Record Lock，还是RR级别

A>>rollback;

Query OK, 0 rows affected (0.00 sec)

B>>rollback;

Query OK, 0 rows affected (0.00 sec)

A>>begin;

Query OK, 0 rows affected (0.00 sec

B>>begin;

Query OK, 0 rows affected (0.00 sec)

A>>select * from t_pk where id=3 for update;

+----+--------+

| id | mem_id |

+----+--------+

|  3 |      3 |

+----+--------+

1 row in set (0.00 sec)



B>>insert into t_pk values(2,2);

Query OK, 1 row affected (0.00 sec)

B>>insert into t_pk values(4,4);

Query OK, 1 row affected (0.00 sec)

结论：说明上面的推导正确。
Read-Committed级别（RC）

A>>rollback;

Query OK, 0 rows affected (0.00 sec)

B>>rollback;

Query OK, 0 rows affected (0.00 sec)

A>>set @@session.tx_isolation="read-committed";

Query OK, 0 rows affected (0.01 sec)

B>>set @@session.tx_isolation="read-committed";

Query OK, 0 rows affected (0.00 sec)

A>>select @@session.tx_isolation;

+------------------------+

| @@session.tx_isolation |

+------------------------+

| READ-COMMITTED         |

+------------------------+

1 row in set (0.00 sec)

B>>select @@session.tx_isolation;

+------------------------+

| @@session.tx_isolation |

+------------------------+

| READ-COMMITTED         |

+------------------------+

1 row in set (0.00 sec)

A>>begin;

Query OK, 0 rows affected (0.00 sec)

B>>begin;

Query OK, 0 rows affected (0.00 sec)

A>>select * from t_pk;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      1 |

|  3 |      3 |

|  5 |      5 |

|  9 |      9 |

| 11 |     11 |

+----+--------+

5 rows in set (0.00 sec)

B>>select * from t_pk;

+----+--------+

| id | mem_id |

+----+--------+

|  1 |      1 |

|  3 |      3 |

|  5 |      5 |

|  9 |      9 |

| 11 |     11 |

+----+--------+

5 rows in set (0.00 sec)

A>>select * from t_pk where mem_id=3 for update;

+----+--------+

| id | mem_id |

+----+--------+

|  3 |      3 |

+----+--------+

1 row in set (0.00 sec)



B>>insert into t_pk values(2,2);

Query OK, 1 row affected (0.00 sec)

B>>insert into t_pk values(4,4),(6,6),(10,10);

Query OK, 3 rows affected (0.00 sec)

Records: 3  Duplicates: 0  Warnings: 0

结论:说明RC级别下，没有间隙锁存在。

  • 主键+RR/RC

这跟唯一索引+RR/RC是一样的，请参看上面的唯一索引+RR/RC。






您可能感兴趣的文档:

--结束END--

本文标题: MySQL的在RC和RR模式下的锁

本文链接: https://lsjlt.com/news/41846.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

猜你喜欢
  • MySQL的在RC和RR模式下的锁
    InnoDB的锁机制：数据库使用所是为了支持更好的并发，提供数据的完整性和一致性。InnoDB是一个支持锁的存储引擎，锁的类型有：共享锁（S）、排它锁（X）、意向共享锁（IS）、意向排它锁（IX）。为了支持...
    99+
    2024-04-02
  • MySQL的RR模式下死锁
    本篇内容主要讲解“MySQL的RR模式下死锁”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“MySQL的RR模式下死锁”吧!一、问题提出如下构造方式，问为什么RC...
    99+
    2024-04-02
  • RR与RC隔离级别下MySQL不同的加锁解锁方式有哪些
    小编给大家分享一下RR与RC隔离级别下MySQL不同的加锁解锁方式有哪些，希望大家阅读完这篇文章之后都有所收获，下面让我们一起去探讨吧！|  RC与RR隔离级别下MySQL不同的加锁解锁方式MyS...
    99+
    2024-04-02
  • 如何解决MySQL的RR模式下死锁一列
    如何解决MySQL的RR模式下死锁一列，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。环境：版本5.7.29 RR隔离级别一、案例模拟CRE...
    99+
    2024-04-02
  • MySQL在RR隔离级别下的unique失效和死锁模拟
    今天在测试MySQL事务隔离级别的时候，发现了一个有趣的问题，也参考了杨一之前总结的一篇。http://blog.itpub.net/22664653/viewspace-1612574/ &nb...
    99+
    2024-04-02
  • MVCC 在RC 和 RR 隔离等级下的工作机制
    一.数据行隐藏列 innodb为每行记录都实现了三个隐藏字段 6字节的事务ID（DB_TRX_ID） 7字节的回滚指针（DB_ROLL_PTR） 隐藏的ID 事务1修改行值过程: X锁锁定该行 ...
    99+
    2024-04-02
  • RR与RC隔离级别下索引和锁的测试脚本示例代码
    基本概念 当前读与快照读 在MVCC中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。 快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁...
    99+
    2024-04-02
  • mysql中一个RR模式下UPDATE锁范围扩大案例分析
    本篇内容介绍了“mysql中一个RR模式下UPDATE锁范围扩大案例分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细...
    99+
    2024-04-02
  • RC级别下MySQL死锁问题的解决
    目录背景死锁分析死锁解决背景 在工作中碰到一次死锁问题，业务背景是在mq接收商品主数据时会更新商品其他数据，由于商品主数据和商品其他信息是一对多的关系，所以采用先删后增的方式，结果异...
    99+
    2024-04-02
  • 如何理解MYSQL RC模式insert update可能死锁的情况
    本篇文章给大家分享的是有关如何理解MYSQL RC模式insert update可能死锁的情况，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。 ...
    99+
    2024-04-02
  • MySQL中隔离级别RC与RR的区别及说明
    目录mysql隔离级别RC与RR的区别MySQL8 RC和RR隔离级别的实战一、创建测试数据二、RR隔离级别三、RC隔离级别MySQL隔离级别RC与RR的区别 RR 支持 gap lock(next-key lock)，...
    99+
    2022-08-17
    MySQL隔离级别 隔离级别RC 隔离级别RR RC与RR的区别
  • RR模式下insert..selcet sending data状态是怎样的
    RR模式下insert..selcet sending data状态是怎样的，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。例如：其中的se...
    99+
    2024-04-02
  • Innodb中RR隔离级别下insert...select 对select表加锁模型和死锁案列分析
    这篇文章主要介绍“Innodb中RR隔离级别下insert...select 对select表加锁模型和死锁案列分析”，在日常操作中，相信很多人在Innodb中RR隔离级别下insert...se...
    99+
    2024-04-02
  • mysql表级锁的模式有几种
    本篇内容介绍了“mysql表级锁的模式有几种”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！1、表共享读锁，添加共享读锁的表不会阻塞其他ses...
    99+
    2023-06-20
  • 使用java怎么在锁模式下实现插队
    本篇文章给大家分享的是有关使用java怎么在锁模式下实现插队，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。Java的特点有哪些Java的特点有哪些1.Java语言作为静态面向对...
    99+
    2023-06-14
  • MYSQL中锁的模式与类型有哪些
    本篇内容主要讲解“MYSQL中锁的模式与类型有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“MYSQL中锁的模式与类型有哪些”吧!在日常开发工作中，我们几乎...
    99+
    2024-04-02
  • Mysql的锁（S锁和X锁的区别）
    共享锁和排它锁 Mysql的锁系统：shared lock 和 exclusive lock (共享锁和排它锁，也叫读锁和写锁，即read lock和write lock) 读锁是共享的，或者说是相互不...
    99+
    2024-04-02
  • RMAN 下NOARCHIVELOG和ARCHIVE模式的恢复
    恢复处于NOARCHIVELOG模式的数据库 当数据库处于NOARCHIVELOG模式时，如果出现介质故障 ，则最后一次备份之后对数据库所做的任何操作都将丢失。通过RMAN执行恢复时，只需要执行restore命令将数据库文件修复到正确的位置...
    99+
    2020-03-25
    RMAN 下NOARCHIVELOG和ARCHIVE模式的恢复
  • 【Gap锁】Mysql的Gap锁在中文列下间隙怎样确定？
    通过本文记录一次Gaplock的验证，网上大多gaplock是基于明确是数字型列来测试gaplock的，这里不再重复，随便贴个相关地址：https://www.cnblogs.com/crazylqy/p/7821481.html  我的疑...
    99+
    2020-04-01
    【Gap锁】Mysql的Gap锁在中文列下间隙怎样确定？
  • MySQL之InnoDB下的锁问题
    目录背景知识获取InnoDB行锁争用情况InnoDB的行锁模式及加锁方法下面是使用 lock in share mode加共享锁的例子下面是使用for update加排他锁的例子InnoDB行锁的实现方式在不通...
    99+
    2023-08-11
    MySQL InnoDB MySQL InnoDB下锁
软考高级职称资格查询
热门wiki
近期文章
推荐阅读
热门问答
热门标签
编程网，编程工程师的家园，是目前国内优秀的开源技术社区之一，形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容，为IT开发者提供了一个发现、使用、并交流开源技术的平台。

  • 官方手机版

  • 微信公众号

  • 商务合作