mysql进阶篇笔记

SQL进阶

存储引擎

存储引擎是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引擎是基于表的，而不是基于库的，所以存储引擎也被称为表类型

体系结构：连接层、服务层、引擎层、存储层

1. 在创建表时，指定存储引擎

create table 表名(
	字段1 字段1类型,
	字段2 字段2类型,
	...
	字段n 字段n类型
)ENGINE = INNODB;

2. 查看当前数据库支持的存储引擎

show engines;

3. 指定存储引擎

-- 创建表 my_mysisam,并指定myisam存储引擎
create table my_myisam(
	id int,
	name char(10)
)engine = MyISAM;

存储引擎特点

• InnoDB

  • 介绍

    InnoDB是一种兼顾高可靠性和高性能的通用存储引擎，在MYSQL5.5之后，InnoDB是默认的存储引擎

  • 特点

    • DML操作遵循ACID模型，支持事务
    • 行级锁，提高并发访问性能
    • 支持外键FORENGN KEY约束，保证数据的完整性和正确性

  • 文件

    • xxx.ibd: xxx代表的是表名，innoDB引擎每张表都会对应这样一个表文件空间，存储该表的表结构（frm、sdi）、数据和索引。
    • 参数：innodb_file_per_table

• 逻辑存储结构
  

• MySAM

  • 介绍
    • MySAM是MYSQL早期的默认存储引擎
  • 特点
    • 不支持事务，不支持外键
    • 支持表锁，不支持行锁
    • 访问速度快
  • 文件
    • xxx.sdi：存储表结构信息
    • xxx.MYD：存储数据
    • xxx.MYI：存储索引

• Memory

  • 介绍
    • Memory引擎的表数据时存储在内存中的，由于受到硬件问题、或断电问题的影响，只能将这些表作为临时表或缓存使用
  • 特点
    • 内存存放
    • hash索引（默认）
  • 文件
    • xxx.sdi：存储表结构信息

存储引擎的选择

​ 在选择存储引擎时，应该根据应用系统的特点选择合适的存储引擎。对于复杂的应用系统，还可以根据实际情况选择多张存储引擎进行组合

• InnoDB:是MYSQL的默认存储引擎，支持事务、外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询之外，还包含很多的更新、删除操作，那么InnoDB存储引擎是比较合适的选择

• MyISAM：如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并对事务的完整性、并发性要求不是很高，那么选择这个存储引擎是非常合适的。

• MeMory：将所有数据保存在内存中，访问速度快，通常用于临时表及缓存。MeMory的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，而且无法保证数据的安全性。

存储引擎应用

InnoDB：存储业务系统中对于事务、数据完整性要求较高的核心数据

MyISAM：存储业务系统的非核心事务

索引

​ 索引是帮助MYSQL高效获取数据的数据结构（有序）。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

优势	劣势
提高数据检索的效率，降低数据库的IO成本	索引列也是要占用空间的
通过索引列对数据进行排序，降低数据排序的成本，降低CPU消耗	索引大大提高了查询效率，同时也降低更新表的速度，如对表进行INSERT、UPDATE、DELETE时，效率降低

索引结构

​ MYSQL的索引是在存储引擎层实现的，不同的存储引擎有不同的结构，主要包含以下几种：

索引结构	描述
B+Tree索引	最常见的索引类型，大部分引擎都支持B+树索引
Hash索引	底层数据结构是用哈希表实现的，只有精确匹配索引列的查询才有效，不支持范围查询
R-Tree索引	空间索引是MyISAM引擎的一个特殊索引类型，主要用于地理空间数据类型，通常使用较少
Full-text索引	是一种通过建立倒排索引，快速匹配文档的方式

注：我们平常所说的索引，如果没有特别指明，都是指B+树结构组织的索引。

• B-Tree（多路平衡查找树）

以一颗最大度数（max-degree）为5的b-tree为例（每个节点最多存储4个key，5个指针）：

• B+Tree

以一颗最大度数为4的b+tree为例：

相对于 B-Tree的区别：

1. 所有的数据都会出现在叶子节点
2. 叶子节点形成一个单向链表

​ MySQL索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的B+Tree，提高区间访问的性能。

• Hash

  哈希索引就是采用一定的hash算法，将键值换算成新的hash值，映射到对应的槽位上，然后存储在hash表中

  如果两个或多个键值，映射到一个相同的槽位上，他们就产生了hash冲突，可以通过链表解决

  • 特点
    • hash索引只能用于对等比较（=，in），不支持范围查询（between，<，>，…）
    • 无法利用索引完成排序操作
    • 查询效率高，通常只需要一次检索就可以了，效率通过高于B+Tree索引
  • 存储引擎支持
    • 在MySQL中，支持hash索引的是Memory引擎，而InnoDB中具有自适应hash功能，hash索引是存储引擎根据B+Tree索引在指定条件下自动构建的

思考

为什么InnoDB存储引擎选择使用B+Tree索引结构

1. 相对于二叉树，层次更少，搜索效率高
2. 对于B-Tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针跟着减少，要保存大量的数据，只能增加树的高度，导致性能降低
3. 相对hash索引，B+Tree支持范围匹配及排序操作

索引

索引是高效获取数据的数据结构

分类

分类	含义	特点	关键字
主键索引	针对于表中主键创建的索引	默认自动创建，只能有一个	PRIMARY
唯一索引	避免同一个表中某数据列中的值重复	可以有多个	UNIQUE
常规索引	快速定位特定数据	可以有多个	-
全文索引	查找的是文本中的关键词，而不是比较索引的值	可以有多个	FULLTEXT

在InnoDB引擎中，根据索引的存储形式，又可以分为以下两种：

分类	含义	特点
聚集索引	将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据	必须有，而且只有一个
二级索引	将数据与索引分开存储，索引结构的叶子节点关联的是对应的主键	可以存在多个

聚集索引选取规则

• 如果存在主键，主键索引就是聚集索引
• 如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引
• 如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引

思考

-- 1.以下SQL语句，哪个执行效率高？ 为什么？
select * from user where id = 10;
select * from user where name = 'Arm'；
-- 备注：id为主键，name字段创建的有索引
/* 第一个高 */

InnoDB主键索引的B+Tree高度为多高呢？

索引的语法

• 创建索引

create [unique|fulltext] index index_name on table_name(index_col_name,...);

• 查看索引

show index from table_name;

• 删除索引

drop index index_name on table_name;

• 案例

-- 1. name字段为姓名字段，该字段值会重复，为该字段创建索引,索引名称为idx_uesr_name,在tb_user表中
create index idx_user_name on tb_user(name);
-- 2. phone手机号字段的值，是非空，且唯一的，为该字段创建唯一索引
create unique index idx_user_phone on tb_user(phone);
-- 3.为profession、age、status创建联合索引
create index idx_user_pro_age_sta on tb_user(profession,age,status);
-- 4.为email建立合适的索引来提升查询效率
create index idx_user_email on tb_user(email);

SQL性能分析

• SQL的执行频率

  MYSQL客户端连接成功后，通过 show [session | global] status 命令可以提供服务器状态信息。通过如下指令，可以查看当前数据库的INSERT 、UPDATE、DELETE、SELECT的访问频次：

  show global status like 'Com____'；
  

• 慢查询日志

  慢查询日志记录了所有执行时间超过指定参数（long_query_time,单位：秒，默认10秒）的所有SQL语句的日志。

  MYSQL的慢查询日志默认没有全部开启，需要在MYSQL的配置文件（/etc/my.cnf）中配置如下信息：

  # 开启MYSQL慢查询日志开关
  slow_query_log = 1
  # 设置慢日志的时间为2秒，SQL语句执行超过两秒，就会视为慢查询，记录慢查询日志
  long_query_time = 2
  

• profile详情

show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。通过have_profiling参数，能够看到当前MYSQL是否支持profile操作：

select @@have_profiling;

默认profiling是关闭的，可以通过set语句在session/global级别开启profiling：

set profiling = 1；

执行一系列的业务SQL的操作，然后通过如下指令查看指令的执行耗时：

-- 查看每一条SQL的耗时基本情况
show profiles;
# 查看指定query_id的SQL语句各个阶段的耗时情况
show profile for query query_id;
# 查看指定query_id的SQL语句CPU的使用情况
show profile cpu for query_id;

• explain执行计划

  explain 或者desc命令获取MYSQL如何执行select语句的信息，包括在select语句执行过程中表如何连接和连接的顺序

  # 直接在select语句之前加上关键字explain /desc
  explain select 字段列表 from 表名 where 条件;
  

  explain执行计划各字段的含义

  • id：select查询到的序列号，表示查询中执行select字句或者表的操作顺序（id相同，执行顺序从上到下，id不同，值越大，越先执行）
  • type：表示连接类型，性能有好到差的连接类型为null、system、const、eq_ref、ref、range、index、all
  • possible_key：显示可能应用在这张表的索引，一个或多个
  • key：实际用到的索引，如果为null，则没有使用索引
  • key_len：表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下，长度越短越好。
  • filtered：表示返回结果的行数占需读取行数的百分比，filtered的值越大越好

索引使用

• 最左前缀法则
  如果索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列。如果跳过了某一列，索引将部分失效。

• 范围查询
  联合索引中，出现范围查询（<,>),范围查询右侧的列索引失效

• 索引列运算

  不要在索引列上进行运算操作，否则索引将失效

• 字符串不加引号
  字符串类型字段使用时，不加引号，索引将失效

• 模糊查询

  如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效

• or连接条件

  用or分割开的条件，如果or前的条件中的列有索引，后面的列中没有索引，那么涉及到的索引都不会被用到

• 数据分布影响
  如果MYSQL评估使用索引比全表更慢，则不使用索引

• SQL提示

  SQL提示，是优化数据库的一个重要手段，简单来说，就是在SQL语句中加入一些人为的提示来达到优化操作的目的

  # use index 建议数据库使用哪个索引
  explain select * from tb_user use index(idx_user_pro) where 条件;
  # ignore index 告诉数据库不用哪个索引
  explain select * from tb_user ignore index(idx_user_pro) where 条件;
  # force index 强制使用哪个索引
  explain select * from tb_user force index(idx_user_pro) where 条件;
  

• 覆盖索引
  尽量使用覆盖索引（查询使用了索引，并且需要返回的列，在该索引中以及全部能够找到）减少select *

• 前缀索引

  当字段类型为字符串时，有时候需要索引很长的字符串，这会让索引变的很大，查询时，浪费大量的磁盘IO，影响查询效率。此时可以只将字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率

  create index idx_xxxx on table_name(column(n));
  

索引设计原则

1. 针对于数据量较大，且查询比较频繁的表建立索引
2. 对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引
3. 尽量选择区分度高的列作为索引，尽量选择建立唯一索引，区分度高，使用索引的效率就越高
4. 如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引
5. 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提升查询效率
6. 要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率
7. 如果索引列不能存储null值，请在创建表时使用not null约束他。当优化器知道每列是否包含null值时，他可以更好的确定哪个索引最有效的用于查询

SQL优化

插入数据

• insert 优化

  • 批量插入

  insert into tb_test values (1,'tom'),(2,'cat')；
  

  • 手动提交事务

  start transaction;
  insert into tb_test values (1,'tom'),(2,cat)；
  insert into tb_test values (3,'cer'),(4,'pig')；
  commit;
  

  • 主键顺序插入

  主键乱序插入：8，1，9，50，44
  主键顺序插入：1，2，3，4，5，6
  

• 大批量插入数据

  如果需要一次性插入大批量数据，使用insert语句插入性能较低，此时可以使用MYSQL数据库的load指令进行插入，操作如下：

  # 客户端连接服务端时，加上参数 --local-infile
  mysql --local-infile -u root -p
  # 设置全局参数local_infile = 1;
  # 执行load指令将准备好的数据，加载到表结构中
  load data local infile '/root/sql.log' into table 'tb_user' files terminated by ',' lines terminated by '\n'
  

主键优化

• 数据组织方式

  在InoDB存储引擎中，表数据都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表

• 页分裂

  页可以为空，也可以填充一半，页可以填充100%。每个页包含了2-N行数据（如果一行数据多大，会行溢出），根据主键排列

• 页合并

  当删除一行记录时，实际上记录并没有被物理删除，只是记录被标记（flaged）为删除并且它的空间变得允许被其他记录声明使用。

  当页中删除的记录达到MERGE_THRESHOLD（默认为页的50%），InnoDB会开始寻找最靠近的页（前或后）看看是否可以将两个页合并以优化空间使用

• 主键设计原则

  • 满足业务需求的情况下，尽量降低主键的长度
  • 插入数据时，尽量选择顺序插入，选择使用AUTO_INCREMENT自增主键
  • 尽量不要使用UUID做主键或者是其他自然主键，如身份证号
  • 业务操作时，避免对主键的修改

order by优化

1. 根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则
2. 尽量使用覆盖索引
3. 多字段排序，一个升序一个降序，此时需要注意联合索引在创建时的规则
4. 如果不可避免的出现filesort，大数据量排序时，可以适当增大排序缓冲区 sort_buffer_size(默认)

using index:直接通过索引返回数据，性能高
using filesort：需要将返回的结果在排序缓冲区排序

group by优化

1. 在分组操作时，可以通过索引来提高效率
2. 分组操作时，索引的使用也是满足最左前缀法则的

limit优化

​ 覆盖索引+子查询

count优化

​ 性能：count（字段）< count（主键 id）<count (1) ≈count（*）

update优化

尽量根据主键/索引字段进行数据更新

视图

视图是一种虚拟存在的表。视图中的数据并不在数据库中实际存在，行和列数据来自定义视图的查询中使用的表，并且在使用视图时动态生成的。通俗的讲，视图只保存了查询的SQL逻辑，不保存查询结果。所以我们在创建视图的时候，主要的工作就落在创建这条SQL查询语句上

• 创建

create [or replace] view 视图名称[（列名列表）] as select语句 [with [cascaded | local] check option];
-- 例子
create or replace view stu_1 as select id,name from emo where id <10;

• 查询

-- 查看创建视图语句:show create view 视图名称;
-- 查看视图数据：select * from 视图名称...;

• 修改视图

方式1：create [or replace] view 视图名称[(列名列表)] as select语句 [with[cascaded | local]check option]；
方式2：alter view 视图名称[(列明列表)] as select语句 [with[cascaded | local]check option]；

• 删除视图

drop view 视图名称;

• 视图的检查选项

  当使用with check option子句创建视图时，MYSQL会通过视图检查正在更改的每个行，例如 插入，更新，删除，以使其规范视图的定义。MYSQL允许基于另一个视图创建视图，他还好检查依赖视图中的规则以保持一致性。为了确定检查的范围，MYSQL提供了两个选项：CASCADED 和LOCAL，默认值为CASCADED

• 视图的更新及作用

  要使视图可更新，视图的行与基础表中的行之间必须存在一对一的关系。如果视图包含以下任何一项，则该视图不可更新：

  • 聚合函数或窗口函数（sum()、min()、max()、count()等）
  • DISTINST
  • GROUP BY
  • HAVING
  • UNIQUE 或者 UNION ALL

视图的作用

1. 简单

   视图不仅可以简化用户对数据的理解，也可以简化他们的操作。那些被经常使用的查询可以被定义为视图，从而使得用户不必为以后的操作每次指定全部的条件

2. 安全

   数据库可以授权，但不能授权到数据库特定行和特定列上。通过视图用户只能查询和修改他们所能见到的数据

3. 数据独立

   视图可帮助用户屏蔽真实表结构变化带来的影响。

视图案例

-- 1. 为了保证数据库表的安全性，开发人员在操作tb_user表时，只能看到用户的基本字段，屏蔽手机号和邮箱两个字段
create view tb_user_view as select id,name,profession,age,gender,status,createtime from tb_user；
select * from tb_user_view

-- 2.查询每个学生所选修的课程（三表联查），这个功能在很多业务中都有使用到，为了简化操作，定义一个视图
select s.name,s.no,c.name from student s student_course sc,couse c where s.id =sc.studentid and sc.courseid = c.id;

create view tb_stu_course_view as select s.name student_name,s.no student_no,c.name course_name from student s student_course sc,couse c where s.id =sc.studentid and sc.courseid = c.id;

select * from tb_stu_course_view;

存储过程

介绍：存储过程是实现经过编译并存储再数据库中的一段SQL语句的集合，调用存储过程可以简化应用开发人员的很多工作，减少数据库和应用服务器之间的传输，对于提高数据处理的效率是有好处的

存储过程的思想上很简单，就是数据库SQL语言层面的代码封装与重用。

• 特点

  • 封装，复用
  • 可以接受参数，也可以返回数据
  • 减少网络交互，效率提升

• 创建

create procedure 存储过程名称（[参数列表])
begin
	SQL语句
end;

• 调用

call 名称（[参数]）;

• 查看

select * from information_schema.routines where routine_schema = 'xxx'; --查询指定数据库的存储过程及状态信息
show create procedure 存储过程名称; -- 查询某个存储过程的定义

• 删除

drop procedure 存储过程名称;

变量

• 系统变量：是MYSQL服务器提供，不是用户定义的，属于服务器层面。分为全局变量（global）、会话变量（session）。

-- 查看系统变量
show session variables;
-- 通过like模糊匹配方式查找变量
show session variables like 'auto%';
-- 设置系统变量
set [session|global] 系统变量名 = 值;
set @@[session|global] 系统变量名 = 值;

• 用户自定义变量

是用户根据需要自己定义的变量，用户变量不用提前声明，再用的时候用‘ @变量名’ 使用就可以。其作用域为当前连接

-- 赋值
set @myname = 'itcast';
set @age := 10;
-- 使用
select @myname;

• 局部变量

是根据需要定义再局部生效的变量，访问之前，需要declare声明。可用作存储过程内的局部变量和输入参数，局部变量的范围是在其内声明的begin … end块

-- 声明
declare 变量名 变量类型 [default]；
# 变量类型就是数据库字段类型：int、char、varchar等
-- 赋值
set 变量名 = 值;
set 变量名 :=值;
select 字段名 into 变量名 from 表名...;

触发器

介绍：触发器是与表有关的数据库对象，指在insert/update/delete之前或之后，触发并执行触发器中定义的SQL语句集合。触发器的这种特点可以协助应用在数据库端保证数据的完整性，日志记录，数据校验等操作

使用别名old和new来引发触发器中发生变化的记录内容，这与其他的数据库是相似的。现在触发器还只支持行级触发，不支持语句级触发

触发器类型	new和old
insert型触发器	new表示将要或者已经新增的数据
update型触发器	old表示修改之前的数据，new表示将要或已经修改后的数据
delete型触发器	old表示将要或者已经删除的数据

 -- 创建触发器
 create trigger 名称
 before/after insert/update/delete
 on 表名 for each row 
 begin 
 	trigger_stmt
 end;
 
 -- 查看
 show triggers;
 -- 删除
 drop trigger [schema_name]trigger_name;

锁

锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源（cpu、ram、I/O）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。

• 分类
  • 全局锁：锁定数据库中的所有表
  • 表级锁：每次操作锁住整张表
  • 行级锁：每次操作锁住对应的行数据

全局锁

​ 全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新操作的事务提交语句都将被阻塞

​ 其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整

-- 加锁
flush tables with read lock;
-- 执行逻辑备份
mysqldump -uroot -p1234 itcast >itcast.sql #windows命令行执行
-- 解锁
unlock tables;

• 特点

  数据库加全局锁，是一个比较重的操作，存在以下问题

  1. 如果在主库上备份，那么在备份期间都不能执行更新，业务基本就得停摆
  2. 如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志，会导致主从延迟

表级锁

表级锁，每次操作锁住整张表。锁定粒度大，发送锁冲突的概率最高，并发度最低。应用在MyISAM、InnoDB等存储引擎中

对于表级锁，主要分为以下三类：

1. 表锁
2. 元数据锁
3. 意向锁

• 表锁

  对于表锁，分为两类：

  • 表共享读锁（read lock）
  • 表独占写锁（write lock）

-- 1. 加锁
lock tables 表名... read/write；
-- 2. 释放锁
unlock tables / 客户端断开连接；

• 元数据锁

  MDL加锁过程是系统自动控制，无需显式使用，在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。为了避免DML与DDL冲突，保证读写的正确性。

• 意向锁

为了避免DML在执行时，加的行锁与表锁的冲突，在InnoDB中引入了意向锁，使得表锁不用检查每行数据是否加锁，使用意向锁来减少表锁的检查.

1. 意向共享锁（IS）：与表锁共享锁（read）兼容，与表锁排他锁（write）互斥。
2. 意向排他锁（IX）：与表锁共享锁（read）及排他锁（write）都互斥。意向锁直接不会互斥

行级锁

行级锁，每次操作锁住对应的行数据。锁定粒度最小，发生锁冲突的概率最低，并发度最高。

1. 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
2. 排他锁（X）：允许获取排他锁的事务更新数据，组织其他事务获得相同数据集的共享锁和排他锁。

，发送锁冲突的概率最高，并发度最低。应用在MyISAM、InnoDB等存储引擎中

对于表级锁，主要分为以下三类：

1. 表锁
2. 元数据锁
3. 意向锁

• 表锁

  对于表锁，分为两类：

  • 表共享读锁（read lock）
  • 表独占写锁（write lock）

-- 1. 加锁
lock tables 表名... read/write；
-- 2. 释放锁
unlock tables / 客户端断开连接；

• 元数据锁

  MDL加锁过程是系统自动控制，无需显式使用，在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。为了避免DML与DDL冲突，保证读写的正确性。

• 意向锁

为了避免DML在执行时，加的行锁与表锁的冲突，在InnoDB中引入了意向锁，使得表锁不用检查每行数据是否加锁，使用意向锁来减少表锁的检查.

1. 意向共享锁（IS）：与表锁共享锁（read）兼容，与表锁排他锁（write）互斥。
2. 意向排他锁（IX）：与表锁共享锁（read）及排他锁（write）都互斥。意向锁直接不会互斥

行级锁

行级锁，每次操作锁住对应的行数据。锁定粒度最小，发生锁冲突的概率最低，并发度最高。

1. 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
2. 排他锁（X）：允许获取排他锁的事务更新数据，组织其他事务获得相同数据集的共享锁和排他锁。