InnoDB存储引擎中的锁

文章目录

    • 概要
    • 一、需要解决的问题
    • 二、共享锁和独占锁
      • 1.1 锁定读
      • 1.2 表级别的共享锁、独占锁
    • 三、行锁
      • 3.1 数据准备
      • 3.2 几种常见的行级锁
      • 3.3 行锁升级为表锁

概要

关于MySQL涉及到的锁，大致可以总结如下：
请添加图片描述
MyISAM存储引擎在开发过程中几乎很少使用了，这里主要总结InnoDB存储引擎中的锁。

一、需要解决的问题

数据库中的记录，不可避免地出现并发访问的情况。并发事务，可能会带来以下问题：

  • 脏写
    当两个或多个事务更新同一行记录，会产生更新丢失现象。可以分为回滚覆盖和提交覆盖。
    1）回滚覆盖：一个事务回滚操作，把其他事务已提交的数据给覆盖了
    2）提交覆盖：一个事务提交操作，把其他事务已提交的数据给覆盖了

  • 脏读
    提交覆盖：一个事务提交操作，把其他事务已提交的数据给覆盖了

  • 不可重复读
    提交覆盖：一个事务提交操作，把其他事务已提交的数据给覆盖了

  • 幻读
    一个事务中多次按相同条件查询，结果不一致。后续查询的结果和面前查询结果不同，多了或少了几行记录。

并发事务访问相同记录的操作大致可以划分为3种：

  • 读-读情况：多个事务并发读取同一条记录
    读取操作不会读数据本身造成什么印象，所以这种情况不会存在什么问题

  • 写-写情况：多个事务对同一条记录进行并发修改
    这种情况下会发生脏写的问题，要解决这个问题，其中的一个方法通过锁的方式。如果事务之间涉及到相同的数据项时，会使用排他锁，或叫互斥锁，先进入的事务独占数据项以后，其他事务被阻塞，等待前面的事务释放锁

  • 读-写或写-读情况：一个事务进行读取操作，另一个进行改动操作。
    这种情况下可能发生脏读、不可重复读、幻读的问题。
    要解决这些问题，有两种可选方案：
    1）读操作利用多版本并发控制（MVCC），写操作进行加锁。
    关于MVCC，可以查看：undo log与mvcc，写操作针对的是最新版本的记录，读记录的历史版本和改动记录的最新版本本身并不冲突，也就是采用MVCC时，读-写操作并不冲突。
    2）读、写操作都采用加锁的方式
    实际开发中，有一些业务场景要求，每次都必须去读取记录的最新版本。比方在银行存款的事务中，需要先把账户余额读出来，操作完后，再写到数据库中。在将账户余额读取出来后，不允许其他事务再修改改账户余额，直到本次存款事务执行完成。这样在读取记录的时候也就需要对其进行加锁，也就意味着读操作和写操作也像写-写操作那样排队执行。

二、共享锁和独占锁

从操作上对锁进行划分，锁可以分为共享锁和排他锁。

  • 共享锁，英文名：Shared Locks，简称S锁。针对同一份数据，多个读操作可以同时进行而不会互相影响。
  • 排他锁，英文名：Exclusive Locks，简称X锁。当前写操作没有完成前，它会阻断其他写锁和读锁。

顾名思义，共享锁就是，两个或多个事务可以同时获得同一条纪录的S锁。排他锁就是，一个事务先获得了S锁或者是X锁，那么其他事务就不能再获取到该条记录的X锁。S锁与X锁之间有以下特性：

在这里插入图片描述

1.1 锁定读

数据准备

CREATE TABLE `account` (`id` int NOT NULL AUTO_INCREMENT COMMENT '主键id',`name` varchar(32) DEFAULT NULL COMMENT '姓名',`balance` int DEFAULT NULL COMMENT '余额',PRIMARY KEY (`id`)
) ENGINE=InnoDB;mysql> SELECT * FROM account;
+----+--------+---------+
| id | name   | balance |
+----+--------+---------+
|  1 | lilei  |      18 |
|  2 | hanmei |      11 |
|  3 | lucy   |     111 |
|  4 | lilei  |      18 |
+----+--------+---------+
  • 对读取的记录加S锁：SELECT ... LOCK IN SHARE MODE;
mysql> begin;mysql> SELECT * FROM account WHERE id = 1 LOCK IN SHARE MODE;
+----+-------+---------+
| id | name  | balance |
+----+-------+---------+
|  1 | lilei |       1 |
+----+-------+---------+

上面的查询操作，对account表中的id = 1的记录增加了共享锁，其他事务依然可以查到该账户的余额，但是不能对账户余额进行修改，在某种场景下能够满足业务的需求。

  • 对读取记录加X锁：SELECT ... FOR UPDATE; 
mysql> begin;
Query OK, 0 rows affected (0.01 sec)mysql> SELECT * FROM account where id = 1 FOR UPDATE;
+----+-------+---------+
| id | name  | balance |
+----+-------+---------+
|  1 | lilei |       1 |
+----+-------+---------+

此时id=1的记录，既不允许别的事务获取S锁，也不允许获取这些记录的X锁（或者直接修改这些记录）。如果别的事务想要获取这些记录的S锁或者X锁，就会阻塞，直到当前事务提交之后释放X锁。

这里需要注意，普通的SELECT * FROM account WHERE id = 1;语句是不加锁的。

1.2 表级别的共享锁、独占锁

手动获取InnoDB存储引擎提供的表的S锁或者X锁语法如下：

LOCK TABLES account READ：InnoDB存储引擎会对表account加表级别的S锁``。

LOCK TABLES S锁 WRITE：InnoDB存储引擎会对表S锁加表级别的X锁。

在对某表中的记录执行SELECT、INSERT、DELETE、UPDATE语句时，InnoDB存储引擎是不会为这个表添加表级别的S锁或者X锁的。
表级别的S锁、X锁有以下特点:

  • 如果一个事务给表加了S锁，那么：
    1）别的事务可以继续获得该表的S锁
    2）别的事务可以继续获得该表中的某些记录的S锁
    3）别的事务不可以继续获得该表的X锁
    4）别的事务不可以继续获得该表中的某些记录的X锁
  • 如果一个事务给表加了X锁（意味着该事务要独占这个表），那么：
    1）别的事务不可以继续获得该表的S锁
    2）别的事务不可以继续获得该表中的某些记录的S锁
    3）别的事务不可以继续获得该表的X锁
    4）别的事务不可以继续获得该表中的某些记录的X锁

在实际开发尽量减少出现表级别的S锁和X锁，粒度大，影响访问广，很少有场景使用到。

表级别的IS锁、IX锁

意向共享锁：英文名：Intention Shared Lock，简称IS锁。当事务准备在某条记录上加S锁时，需要先在表级别加一个IS锁。
意向独占锁：英文名：Intention Exclusive Lock，简称IX锁。当事务准备在某条记录上加X锁时，需要先在表级别加一个IX锁。

IS锁和IX锁的提出，只是为了后续在加表级别的S锁和X锁时判断表中是否有已经被加锁的记录，以避免用遍历的方式来查看表中有没有上锁的记录。

三、行锁

行锁，也称为记录锁，顾名思义，就是作用在表记录上的锁。InnoDB行锁是通过对索引数据页上的记录加锁实现的，主要实现算法有 3 种：Record Lock、Gap Lock 和 Next-key Lock。

  • Record Lock锁：锁定单个行记录的锁。（记录锁，RC、RR隔离级别都支持）
  • Gap Lock锁：间隙锁，锁定索引记录间隙，确保索引记录的间隙不变。（范围锁，RR隔离级别支持）
  • Next-key Lock 锁：记录锁和间隙锁组合，同时锁住数据，并且锁住数据前后范围。（Record Lock + Gap Lock，RR隔离级别支持）

在RR隔离级别，InnoDB对于记录加锁行为都是先采用Next-Key Lock，但是当SQL操作含有唯一索引时，Innodb会对Next-Key Lock进行优化，降级为Record Lock，仅锁住索引本身而非范围。

锁的种类很多（容易晕），划分角度不同，就有不同的叫法；在这里统一总结下，开发过程中常用sql语句涉及到的锁：

  1. select ... from 语句：InnoDB引擎采用MVCC机制实现非阻塞读，所以对于普通的select语句，InnoDB不加锁;
  2. select ... from lock in share mode语句：追加了共享锁，InnoDB会使用Next-Key Lock锁进行处理，如果扫描发现唯一索引，可以降级为Record Lock锁。
  3. select ... from for update语句：追加了排他锁，InnoDB会使用Next-Key Lock锁进行处理，如果扫描发现唯一索引，可以降级为Record Lock锁。
    4）update ... where 语句：InnoDB会使用Next-Key Lock锁进行处理，如果扫描发现唯一索引，可以降级为Record Lock锁。
    5）delete ... where 语句：InnoDB会使用Next-Key Lock锁进行处理，如果扫描发现唯一索引，可以降级为RecordLock锁。
    6）insert语句：一般情况下，新插入一条记录的操作并不加锁。有时候会有插入意向锁

下面以account表操作为例，举例子分析下 InnoDB 对不同索引的加锁行为；

3.1 数据准备

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.27    |
+-----------+
1 row in set (0.00 sec)mysql> select @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ         |
+-------------------------+
1 row in set (0.00 sec)CREATE TABLE `account` (`id` int NOT NULL AUTO_INCREMENT COMMENT '主键id',`code` varchar(32) DEFAULT NULL COMMENT '账号编码',`name` varchar(32) DEFAULT NULL COMMENT '姓名',`balance` int DEFAULT NULL COMMENT '余额',PRIMARY KEY (`id`),UNIQUE KEY `idx_code` (`code`) USING BTREE COMMENT '账号编码唯一索引',KEY `idx_name` (`name`) USING BTREE COMMENT '名称普通索引'
) ENGINE=InnoDB;mysql> select * from account;
+----+------+--------+---------+
| id | code | name   | balance |
+----+------+--------+---------+
|  1 | aa   | tom    |       1 |
|  3 | dd   | hanmei |      11 |
|  8 | ff   | lucy   |     222 |
| 15 | jj   | jack   |      18 |
| 20 | ll   | ocean  |     400 |
+----+------+--------+---------+

加锁跟索引有关，这里把account表相关的索引结构简化展示如下：

聚簇索引：
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/c025464d55684a348cacc5566460d69e.png

这里只展示了索引中的用户记录信息，同时强调聚簇索引中的记录是按照主键大小排序的。

code列唯一索引：
在这里插入图片描述
name列普通索引：
在这里插入图片描述

3.2 几种常见的行级锁

Record Locks

mysql> begin;
Query OK, 0 rows affected (0.00 sec)mysql> update account set balance = 222 where id = 8;
Query OK, 1 row affected (0.00 sec)

通过另外的客户端查看锁情况
执行select * from performance_schema.data_locks\G;
在这里插入图片描述
说明在表层面获取到了IX锁,在数据id=8这条记录加上了LOCK_REC_NOT_GAP锁，也是X锁。
在这里插入图片描述

Gap Locks

在普通索引上执行更新

mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> update account set balance= 333 where name='lucy';

查看锁情况

mysql> select * from performance_schema.data_locks\G;
*************************** 1. row ***************************-- 边幅原因 这里省略表锁，跟上面一样
*************************** 2. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:226:6:7:139645358804944
ENGINE_TRANSACTION_ID: 65451THREAD_ID: 563249EVENT_ID: 77OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: idx_name
OBJECT_INSTANCE_BEGIN: 139645358804944LOCK_TYPE: RECORDLOCK_MODE: XLOCK_STATUS: GRANTEDLOCK_DATA: 'lucy', 8
*************************** 3. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:226:4:12:139645358805288
ENGINE_TRANSACTION_ID: 65451THREAD_ID: 563249EVENT_ID: 77OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139645358805288LOCK_TYPE: RECORDLOCK_MODE: X,REC_NOT_GAPLOCK_STATUS: GRANTEDLOCK_DATA: 8
*************************** 4. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:226:6:4:139645358805632
ENGINE_TRANSACTION_ID: 65451THREAD_ID: 563249EVENT_ID: 77OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: idx_name
OBJECT_INSTANCE_BEGIN: 139645358805632LOCK_TYPE: RECORDLOCK_MODE: X,GAPLOCK_STATUS: GRANTEDLOCK_DATA: 'ocean', 20
4 rows in set (0.01 sec)

再执行以下sql时，发现执行阻塞

mysql> insert into account (id,code,name,balance) values(5,'ee','kk',20); -- 阻塞mysql> insert into account (id,code,name,balance) values(10,'gg','my',20); -- 阻塞mysql> insert into account (id,code,name,balance) values(10,'gg','pp',20); -- 不会被阻塞
Query OK, 1 row affected (0.00 sec)

加锁分析：
在这里插入图片描述
name字段是普通索引，对满足name='lucy'条件的记录和主键会都加上X锁。同时在字符'jack'-'lucy'之间，'lucy'-'ocean'之间加上了LOCK_GAP锁，所以字符kk和my在插入时会发生阻塞，而字符pp不属于锁的范围，所以能不被阻塞地添加到表中。

gap锁的提出仅仅是为了防止插入幻影记录而提出的，如果对一条记录加了gap锁（不论是共享gap锁还是独占gap锁），并不会限制其他事务对这条记录加Record Locks或者继续加gap锁。

对于最后一条记录，GAP锁是如何处理的呢？也就是说给哪条记录加gap锁才能阻止其他事务插入name值在(‘tom’, +∞)这个区间的新记录呢?

mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> update account set balance= 333 where name='tom';  -- 更新普通索引中的最后一条记录-- 开启另外一个事务
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into account (id,code,name,balance) values(30,'pp','zz',20); -- 想添加到tom后面，发生阻塞
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Innodb数据页中有两条伪记录：

  • Infimum记录，表示该页面中最小的记录。
  • Supremum记录，表示该页面中最大的记录。

此时，GAP锁如下：

在这里插入图片描述

Next-Key Lock

有时候既想锁住某条记录，又想阻止其他事务在该记录前面的间隙插入新记录，这时候就用到了Next-Key Locks的锁，官方的类型名称为：LOCK_ORDINARY，也可以简称为next-key锁。

在这里插入图片描述
next-key锁的本质就是一个Record Locks和一个gap锁的合体，它既能保护该条记录，又能阻止别的事务将新记录插入被保护记录前面的间隙。

Insert Intention Locks

一个事务在插入一条记录时需要判断插入位置是不是被别的事务加了gap锁（next-key锁也包含gap锁），如果有的话，插入操作需要等待，直到持有gap锁的事务释放锁。InnoDB规定事务在等待的时候也需要在内存中生成一个锁结构，表明有事务想在某个间隙中插入新记录，但是现在在等待。这种类型的锁命名为Insert Intention Locks，官方的类型名称LOCK_INSERT_INTENTION，也称为插入意向锁。

mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> update account set balance = 55 where id >3 and id <=8;-- 开启另外事务
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into account (id,code,name,balance) values(6,'pp','zz',20);

查看锁情况

mysql> select * from performance_schema.data_locks\G;
*************************** 1. row ***************************-- 省略表锁
*************************** 2. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347952208:226:4:12:139645358792496
ENGINE_TRANSACTION_ID: 65493THREAD_ID: 563275EVENT_ID: 90OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139645358792496LOCK_TYPE: RECORDLOCK_MODE: X,GAP,INSERT_INTENTIONLOCK_STATUS: WAITINGLOCK_DATA: 8
*************************** 3. row ***************************- 省略表锁
*************************** 4. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:226:4:12:139645358804944
ENGINE_TRANSACTION_ID: 65492THREAD_ID: 563249EVENT_ID: 116OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139645358804944LOCK_TYPE: RECORDLOCK_MODE: XLOCK_STATUS: GRANTEDLOCK_DATA: 8
4 rows in set (0.00 sec)

从上面看出id=8的记录添加了插入意向锁，并且锁的状态为等待。

3.3 行锁升级为表锁

InnoDB引擎锁机制是基于索引实现的记录锁定，当没有索引时，会导致全表锁定

mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> update account set balance = 2 where balance = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

开启另外一个事务

mysql> update account set balance = 5 where id = 3; -- 阻塞

通过查看锁情况，发生每条记录都被加上了X锁

mysql> select * from performance_schema.data_locks\G;
*************************** 1. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347952208:1287:139645358795600
ENGINE_TRANSACTION_ID: 65496THREAD_ID: 563275EVENT_ID: 94OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: NULL
OBJECT_INSTANCE_BEGIN: 139645358795600LOCK_TYPE: TABLELOCK_MODE: IXLOCK_STATUS: GRANTEDLOCK_DATA: NULL
*************************** 2. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347952208:226:4:13:139645358792496
ENGINE_TRANSACTION_ID: 65496THREAD_ID: 563275EVENT_ID: 94OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139645358792496LOCK_TYPE: RECORDLOCK_MODE: X,REC_NOT_GAPLOCK_STATUS: WAITINGLOCK_DATA: 3
*************************** 3. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:1287:139645358807936
ENGINE_TRANSACTION_ID: 65495THREAD_ID: 563249EVENT_ID: 120OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: NULL
OBJECT_INSTANCE_BEGIN: 139645358807936LOCK_TYPE: TABLELOCK_MODE: IXLOCK_STATUS: GRANTEDLOCK_DATA: NULL
*************************** 4. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:226:4:1:139645358804944
ENGINE_TRANSACTION_ID: 65495THREAD_ID: 563249EVENT_ID: 120OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139645358804944LOCK_TYPE: RECORDLOCK_MODE: XLOCK_STATUS: GRANTEDLOCK_DATA: supremum pseudo-record
*************************** 5. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:226:4:7:139645358804944
ENGINE_TRANSACTION_ID: 65495THREAD_ID: 563249EVENT_ID: 120OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139645358804944LOCK_TYPE: RECORDLOCK_MODE: XLOCK_STATUS: GRANTEDLOCK_DATA: 1
*************************** 6. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:226:4:8:139645358804944
ENGINE_TRANSACTION_ID: 65495THREAD_ID: 563249EVENT_ID: 120OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139645358804944LOCK_TYPE: RECORDLOCK_MODE: XLOCK_STATUS: GRANTEDLOCK_DATA: 15
*************************** 7. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:226:4:10:139645358804944
ENGINE_TRANSACTION_ID: 65495THREAD_ID: 563249EVENT_ID: 120OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139645358804944LOCK_TYPE: RECORDLOCK_MODE: XLOCK_STATUS: GRANTEDLOCK_DATA: 20
*************************** 8. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:226:4:12:139645358804944
ENGINE_TRANSACTION_ID: 65495THREAD_ID: 563249EVENT_ID: 120OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139645358804944LOCK_TYPE: RECORDLOCK_MODE: XLOCK_STATUS: GRANTEDLOCK_DATA: 8
*************************** 9. row ***************************ENGINE: INNODBENGINE_LOCK_ID: 139645347953824:226:4:13:139645358804944
ENGINE_TRANSACTION_ID: 65495THREAD_ID: 563249EVENT_ID: 120OBJECT_SCHEMA: freshOBJECT_NAME: accountPARTITION_NAME: NULLSUBPARTITION_NAME: NULLINDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139645358804944LOCK_TYPE: RECORDLOCK_MODE: XLOCK_STATUS: GRANTEDLOCK_DATA: 3
9 rows in set (0.00 sec)

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/231422.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

机器学习：DBSCAN算法(效果比K-means好)

机器学习：DBSCAN算法(效果比K-means好)

基本概念 核心对象&#xff1a;以点为圆心半径为r的圆&#xff0c;如果圈里面的样本点大于给定的阈值(minPts)&#xff0c;那么这个点就叫做核心点 直接密度可达&#xff1a;点p在q为圆心的圆内 密度可达&#xff1a; p1与p2直接密度可达&#xff0c;p2与p3直接密度可达&…
阅读更多...
numpy知识库：numpy数据类型转换技巧

numpy知识库：numpy数据类型转换技巧

需求背景 基于numpy和opencv生成一个随机噪声灰度图像&#xff0c;像素值是范围[0, 256)内的整数&#xff0c;图像形状为(512, 512)&#xff0c;并显示图像&#xff0c;源码如下 import numpy as np import cv2img np.random.randint(0, 256, size[512, 512]) cv2.imshow(&q…
阅读更多...
enote笔记法之附录1——“语法词”（即“关联词”）（ver0.24）

enote笔记法之附录1——“语法词”（即“关联词”）（ver0.24）

enote笔记法之附录1——“语法词”&#xff08;即“关联词”&#xff09;&#xff08;ver0.24&#xff09; 最上面的是截屏的完整版&#xff0c;分割线下面的是纯文字版本&#xff1a; 作者姓名&#xff08;本人的真实姓名&#xff09;&#xff1a;胡佳吉 居住地&#xff1…
阅读更多...
Spring-AOP与声明式事务

Spring-AOP与声明式事务

为什么要用AOP ①现有代码缺陷 针对带日志功能的实现类&#xff0c;我们发现有如下缺陷&#xff1a; 对核心业务功能有干扰&#xff0c;导致程序员在开发核心业务功能时分散了精力 附加功能分散在各个业务功能方法中&#xff0c;不利于统一维护 ②解决思路 解决这两个问题&…
阅读更多...
市场调研：2023年SLG游戏行业需求及发展前景预测

市场调研：2023年SLG游戏行业需求及发展前景预测

SLG游戏(SLG游戏)一般指策略游戏&#xff0c;策略游戏是一种以取得各种形式胜利为主题的游戏。这类游戏提供给玩家一个可以动脑筋思考问题来处理较复杂事情的环境&#xff0c;允许玩家自由控制、管理和使用游戏中的人、或事物&#xff0c;通过这种自由的手段以及玩家们开动脑筋…
阅读更多...
Linux命令中的符号

Linux命令中的符号

目录 1 管道符 | 1.1 | grep [要检索的东西] 1.2 echo | tee 2 重定向 2.1 输出重定向覆盖 > 2.2 输出重定向添加 >> 2.3 文件输入重定向 < 2.4 多行文本输入重定向 << 2.5 常用搭配 2.5.1 终端不显示 > /dev/null 1 管道符 | 我们…
阅读更多...
Maven 进阶学习指南---setting详解

Maven 进阶学习指南---setting详解

前言 当我们在开发项目时&#xff0c;有时需要用到外部依赖组件&#xff0c;例如当我们需要 Json 序列化的时候需要用到 FastJson 组件&#xff0c;我们可以通过下载对应 jar 包加载到项目中。但当一个大的项目同时需要依赖各种各样的外部服务&#xff0c;就存在着配置繁琐、依…
阅读更多...
不会PS！超简单的制作产品册方法

不会PS！超简单的制作产品册方法

​产品册是展示产品的重要工具&#xff0c;对于很多企业来说&#xff0c;制作一本精美的产品册是必不可少的。但是&#xff0c;对于一些不会PS的人来说&#xff0c;制作产品册可能会觉得非常困难。其实&#xff0c;制作产品册并不需要PS等专业工具&#xff0c;只需要一些简单的…
阅读更多...
【C++】异常处理 ① ( 异常概念引入 | 抛出异常语法 | 捕获异常语法 | 异常捕获流程 | 异常处理代码示例 )

【C++】异常处理 ① ( 异常概念引入 | 抛出异常语法 | 捕获异常语法 | 异常捕获流程 | 异常处理代码示例 )

文章目录 一、异常处理1、异常概念引入2、抛出异常语法3、捕获异常语法4、异常捕获流程 二、异常处理代码示例1、错误代码示例 - 抛出异常 / 不捕获异常2、正确代码示例 - 抛出异常 / 捕获异常3、正确代码示例 - 抛出异常 / 捕获异常不处理继续抛出异常 一、异常处理 1、异常概…
阅读更多...
【C++】POCO学习总结（八）：通知Notifications和事件Events

【C++】POCO学习总结（八）：通知Notifications和事件Events

【C】郭老二博文之&#xff1a;C目录 1、Notifications和Events的区别 1&#xff09;通知Notifications&#xff1a;如果观察者不知道或不关心事件的来源&#xff0c;则使用通知Notifications。 Poco::NotificationCenter或Poco::NotificationQueue位于源source和目标target之…
阅读更多...
4G工业路由器智慧楼宇门禁无人值守、实时监控

4G工业路由器智慧楼宇门禁无人值守、实时监控

门禁是我们日常生活中常见的基础设施&#xff0c;就像是现代社会智慧城市中的“门神”&#xff0c;在楼宇管理领域中普遍采用的安防卫士。4G工业路由器的物联网应用则为楼宇门禁管理带来了更加便捷和高效的解决方案。 在传统的楼宇门禁系统中&#xff0c;人员需要手动刷卡、输…
阅读更多...
MySQL根据binlog恢复数据

MySQL根据binlog恢复数据

简介 本文介绍了使用mysqlbinlog导出数据&#xff0c;根据binlog恢复数据&#xff0c;和导出数据时报需要super权限的解决方法。 环境 MySQL: 5.7.40 说明 MySQL的binlog是数据库服务器在运行过程中产生的日志文件&#xff0c;记录了数据库增删改的操作&#xff0c;可用于恢复和…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023