MySQL基础（二）——学习笔记

一.MySQL存储引擎

1.体系结构

从上至下：连接-服务-引擎（包括索引）-存储层

2.存储引擎（mysql默认innodb）

#建表时指定存储引擎
CREATE TABLE  表名(
字段1  字段1类型   [ COMMENT  字段1注释 ] ,
 ......
字段n  字段n类型   [COMMENT  字段n注释 ] 
) ENGINE = INNODB   [ COMMENT  表注释 ] ;

#查询存储引擎
show engines;

存储引擎特点：

innoDB：

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

逻辑存储结构：表-段-区-页-行

1. 表空间 : InnoDB存储引擎逻辑结构的最高层，ibd文件其实就是表空间文件，在表空间中可以包含多个Segment段。
2. 段 : 表空间是由各个段组成的， 常见的段有数据段、索引段、回滚段等。InnoDB中对于段的管 理，都是引擎自身完成，不需要人为对其控制，一个段中包含多个区。
3. 区 : 区是表空间的单元结构，每个区的大小为1M。 默认情况下， InnoDB存储引擎页大小为 16K， 即一个区中一共有64个连续的页。
4. 页 : 页是组成区的最小单元，页也是InnoDB 存储引擎磁盘管理的最小单元，每个页的大小默认为 16KB。为了保证页的连续性，InnoDB 存储引擎每次从磁盘申请 4-5 个区。
5. 行 : InnoDB 存储引擎是面向行的，也就是说数据是按行进行存放的，在每一行中除了定义表时 所指定的字段以外，还包含两个隐藏字段。

myisam：

不支持事务，不支持外键，支持表锁，不支持行锁，访问速度快

memory：

内存存放，hash索引

二.索引：有序数据结构

索引也要占空间，大大提高查找效率，但降低更新表的速度

B+树索引结构：

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

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

hash索引结构： 

是采用一定的hash算法，将键值换算成新的hash值，映射到对应的槽位上，然后存储在 hash表中（Hash索引只能用于对等比较(=，in)，不支持范围查询（between，>，< ，...） ；无法利用索引完成排序操作；查询效率高，通常(不存在hash冲突的情况)只需要一次检索就可以了，效率通常要高于B+tree索引）

索引分类：

 

（聚集索引的叶子节点下挂的是这一行的数据 。 二级索引的叶子节点下挂的是该字段值对应的主键值。先查二级索引再查聚集索引称为回表查询） 

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

索引语法：

#创建索引
CREATE  [ UNIQUE | FULLTEXT ]  INDEX  index_name  ON  table_name  ( 
index_col_name,... ) ;

#查看索引：
SHOW  INDEX  FROM  table_name ;

#删除索引
DROP  INDEX  index_name  ON  table_name ;

sql优化基础判断语句：

查询执行频率： SHOW GLOBAL STATUS LIKE 'Com_______';（7个模糊匹配）

慢查询日志（默认10秒）-配置（/etc/my.cnf）

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

profile详情：

SELECT  @@have_profiling ;
SET  profiling = 1;

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

explain语句：增加在在select查询语句之前 

索引使用：

最左前缀法则：

索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始（即建立索引时的最左字段）， 并且不跳过索引中的列。如果跳跃某一列，索引将会部分失效(后面的字段索引失效）-并不要求查询语句中字段的顺序，只要存在即可

范围查询：

联合索引中，出现范围查询(>,<)，范围查询右侧的列索引失效。（尽量使用>=，<=）

索引列运算：

不要在索引列上进行运算操作， 索引将失效（eg：调用函数）

explain  select  *  from  tb_user  where  substring(phone,10,2) = '15';

字符串不加引号：

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

模糊查询：

是尾部模糊匹配，索引不会失效；头部模糊匹配，索引失效

or连接条件：

or连接的条件，左右两侧字段都有索引时，索引才会生效

数据分布影响：

MySQL评估使用索引比全表更慢，则不使用索引（因为索引是用来索引少量数据的，如果通过索引查询返回大批量的数据，则不如走全表扫描来的快，此时索引就会失效）

SQL提示：

# use index ： 建议MySQL使用哪一个索引完成此次查询（仅仅是建议，mysql内部还会再次进
行评估）。
explain select * from tb_user use index(idx_user_pro) where profession = 'x';

#ignore index ： 忽略指定的索引。
explain select * from tb_user ignore index(idx_user_pro) where profession = 'x';

#force index ： 强制使用索引。
explain select * from tb_user force index(idx_user_pro) where profession = 'x';

覆盖索引： 

尽量使用覆盖索引，减少select *。覆盖索引是指查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到（即索引本身包含该字段） ，则可以避免回表查询。

 前缀索引：

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

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

#评估合适字段前缀长度
#可以根据索引的选择性来决定，而选择性是指不重复的索引值（基数）和数据表的记录总数的比值，
索引选择性越高则查询效率越高， 唯一索引的选择性是1，这是最好的索引选择性，性能也是最好的。

select  count(distinct column) / count(*)   from  tb_user ;

select  count(distinct substring(column,1,n)) / count(*)  from  tb_user ;

前缀索引查询流程：

通过对应二级索引找到相应主键后，回表查询走聚集索引找到数据，因为前缀索引可能存在相同情况，因此找到数据后查询条件整体再与数据中相应字段比较看是否符合。

单列索引与联合索引：

情况：在and连接的两个字段 phone、name上都是有单列索引的，但是mysql只会选择一个索引，也就是只能走一个字段的索引，此时是产生回表查询；因此建议使用联合索引

索引设计原则：

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

三.SQL优化：

插入优化：

插入数据：

insert 1.批量插入数据；2.手动控制事务；3.主键顺序插入，性能要高于乱序插入。

大批量插入数据：load 

-- 客户端连接服务端时，加上参数  -–local-infile
 mysql –-local-infile  -u  root  -p

-- 设置全局参数local_infile为1，开启从本地加载文件导入数据的开关
set  global  local_infile = 1;

-- 执行load指令将准备好的数据，加载到表结构中
load  data  local  infile  '/root/sql1.log'  into  table  tb_user  fields  
terminated  by  ','  lines  terminated  by  '\n' ; 

主键优化：

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

在InnoDB引擎中，数据行是记录在逻辑结构 page 页中的，而每一个页的大小是固定的，默认16K。 一个页中所存储的行也是有限的，如果插入的数据行row在该页存储不下，将会存储到下一个页中，页与页之间会通过指针连接。

页分裂：每个页包含了2-N行数据，乱序插入时会导致页分裂

页合并：当删除一行记录时，实际上记录并没有被物理删除，只是记录被标记（flaged）为删除并且它的空间变得允许被其他记录声明使用；当页中删除的记录达到 MERGE_THRESHOLD（默认为页的50%），InnoDB会开始寻找最靠近的页（前 或后）看看是否可以将两个页合并以优化空间使用。

索引设计原则：尽量降低主键的长度。 插入数据时，尽量选择顺序插入，选择使用AUTO_INCREMENT自增主键。 尽量不要使用UUID做主键或者是其他自然主键，如身份证号。尽量避免对主键的修改。

order by优化：

MySQL排序方式：

Using filesort : 通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓冲区sort buffer中完成排序操作，所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序。

Using index : 通过有序索引顺序扫描直接返回有序数据，这种情况即为 using index，不需要 额外排序，操作效率高。

优化原则：

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

group by优化：

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

limit优化：

问题：越往后，分页查询效率越低（查询前默认会指定位置及之前的进行排序）

优化思路: 一般分页查询时，通过创建覆盖索引能够比较好地提高性能，可以通过覆盖索引加子查 询形式进行优化。

explain   select  *  from  tb_sku  t  ,  (select  id  from  tb_sku  order  by  id 
limit  2000000,10)  a  where t.id  =  a.id;

count优化：

MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(*) 的时候会直接返回这个 数，效率很高； 但是如果是带条件的count，MyISAM也慢。

InnoDB 引擎就麻烦了，它执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出 来，然后累积计数。

count() 是一个聚合函数，对于返回的结果集，一行行地判断，如果 count 函数的参数不是 NULL，累计值就加 1，否则不加，最后返回累计值。

用法：count（*）、count（主键）、count（字段）、count（数字）

 效率排序：count(字段) < count(主键 id) < count(1) ≈ count(*)

update优化：

InnoDB的行锁是针对索引加的锁，不是针对记录加的锁 ,并且该索引不能失效，否则会从行锁升级为表锁 。

因此对更改数据时的条件需增加索引，否则行锁则会变成表锁，降低并发性。

四.视图：

一种虚拟存在的表。视图中的数据并不在数据库中实际存在，行和列数据来自定义视图的查询中使用的表，并且是在使用视图时动态生成的。

基本语法：

#创建
CREATE   [OR REPLACE]   VIEW  视图名称[(列名列表)]   AS   SELECT语句   [ WITH [ 
CASCADED  |  LOCAL ]  CHECK  OPTION ]

#查询
查看创建视图语句：SHOW  CREATE  VIEW  视图名称;

查看视图数据：SELECT  *  FROM   视图名称 ...... ;

#修改
方式一：CREATE   [OR REPLACE]   VIEW  视图名称[(列名列表)]   AS   SELECT语句   [ WITH 
[ CASCADED  |  LOCAL ]  CHECK  OPTION ]

方式二：ALTER   VIEW  视图名称[(列名列表)]   AS   SELECT语句   [ WITH [ CASCADED  |  
LOCAL ]  CHECK  OPTION ]

#删除
DROP  VIEW  [IF EXISTS]   视图名称   [,视图名称]  ...

检查选项：

使用WITH CHECK OPTION子句创建视图时，MySQL会通过视图检查正在更改的每个行

cascaded-级联：v2视图是基于v1视图的，如果在v2视图创建的时候指定了检查选项为 cascaded，但是v1视图创建时未指定检查选项。 则在执行检查时，不仅会检查v2，还会级联检查v2的关联视图v1（向下检查）

local-本地：v2视图是基于v1视图的，如果在v2视图创建的时候指定了检查选项为 local ，但是v1视图创建时未指定检查选项，则在执行检查时，只查v2，不会检查v2的关联视图v1（检查自身）

视图的更新条件:

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

• 聚合函数或窗口函数（SUM()、 MIN()、 MAX()、 COUNT()等）
• DISTINCT
• GROUP BY
• HAVING
• UNION 或者 UNION ALL

视图作用：

• 简单：视图不仅可以简化用户对数据的理解，也可以简化他们的操作。那些被经常使用的查询可以被定义为视图，从而使得用户不必为以后的操作每次指定全部的条件
• 安全：数据库可以授权，但不能授权到数据库特定行和特定的列上。通过视图用户只能查询和修改他们所能见到的数据
• 数据独立：视图可帮助用户屏蔽真实表结构变化带来的影响。

五.存储过程：

事先经过编译并存储在数据库中的一段 SQL 语句的集合，减少数据在数据库和应用服务器之间的传输

• 封装，复用 > 可以把某一业务SQL封装在存储过程中，需要用到的时候直接调用即可。
• 可以接收参数，也可以返回数据 > 再存储过程中，可以传递参数，也可以接收返回值。
• 减少网络交互，效率提升 > 涉及到多条SQL，每执行一次都是一次网络传输。 封装在存储过程中，只需要网络交互一次可能就可以了。

基本语法：

#创建
CREATE  PROCEDURE   存储过程名称 ([ 参数列表 ])
 BEGIN-- SQL语句
END ;

#调用
CALL  名称  ([ 参数 ]); 

#查看
SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA = 'xxx';  -- 查询指
定数据库的存储过程及状态信息

SHOW  CREATE  PROCEDURE   存储过程名称 ;  -- 查询某个存储过程的定义

#删除
DROP  PROCEDURE   [ IF EXISTS ]  存储过程名称 ；

#在命令行中，执行创建存储过程的SQL时，需要通过关键字 delimiter 指定SQL语句的
结束符。

变量：系统变量、用户定义变量、局部变量

系统变量：分为全局变量（GLOBAL）、会话 变量（SESSION）

#（默认session）
#查看
 SHOW  [ SESSION | GLOBAL ]   VARIABLES ;                    -- 查看所有系统变量
SHOW  [ SESSION | GLOBAL ]   VARIABLES  LIKE  '......';     -- 可以通过LIKE模糊匹配方
式查找变量
SELECT  @@[SESSION | GLOBAL]  系统变量名;                    --  查看指定变量的值

#设置
SET  [ SESSION | GLOBAL ]   系统变量名 = 值 ; 
SET  @@[SESSION | GLOBAL]系统变量名 = 值 ;

用户自定义变量：用户变量不用提前声明，用的时候直接用 "@变量名" 使用就可以（未赋值直接使用则为null）。其作用域为当前session

#赋值
SET   @var_name := expr  [, @var_name := expr] ... ; 

SELECT   @var_name := expr  [, @var_name := expr] ... ; 

SELECT  字段名  INTO @var_name  FROM  表名;

#使用
SELECT   @var_name ; 

局部变量：定义的在局部生效的变量，访问之前，需要DECLARE声明。可用作存储过程内的局部变量和输入参数，局部变量的范围是在其内声明的BEGIN ... END块。

#声明
DECLARE 变量名 变量类型 [DEFAULT ... ] ;//默认值可选

#赋值
SET  变量名 := 值 ;

SELECT  字段名  INTO  变量名  FROM  表名 ... ; 

几种语法结构：

if语法结构：

IF  条件1  THEN 
    .....
 ELSEIF  条件2  THEN       -- 可选
    .....
 ELSE                     -- 可选
    .....
 END  IF;

#在if条件判断的结构中，ELSE IF 结构可选；ELSE结构可选

存储过程的参数：

CREATE  PROCEDURE   存储过程名称 ([ IN/OUT/INOUT  参数名  参数类型 ])
 BEGIN
    -- SQL语句
END ;

#out 和 inout 型传入自定义变量

 case结构：

-- 含义： 当case_value的值为 when_value1时，执行statement_list1，当值为 when_value2时，
执行statement_list2， 否则就执行 statement_list

 CASE  case_value
    WHEN  when_value1  THEN  statement_list1
   [ WHEN  when_value2  THEN  statement_list2] ...
   [ ELSE  statement_list ]
 END  CASE;

-- 含义： 当条件search_condition1成立时，执行statement_list1，当条件search_condition2成
立时，执行statement_list2， 否则就执行 statement_list

 CASE
  WHEN  search_condition1  THEN  statement_list1
  [WHEN  search_condition2  THEN  statement_list2] ...
  [ELSE  statement_list]
 END CASE;

while语法结构：

-- 先判定条件，如果条件为true，则执行逻辑，否则，不执行逻辑

WHILE  条件  DO
    SQL逻辑...    
END WHILE;

repeat语法结构：

- 先执行一次逻辑，然后判定UNTIL条件是否满足，如果满足，则退出。如果不满足，则继续下一次循环

REPEAT
    SQL逻辑...  
    UNTIL  条件
END REPEAT;

loop语法结构：

[begin_label:]  LOOP
    SQL逻辑...  
END  LOOP  [end_label];

LEAVE  label;   -- 退出指定标记的循环体
ITERATE  label; -- 直接进入下一次循环

游标：

用来存储查询结果集的数据类型 , 在存储过程和函数中可以使用游标对结果集进行循环的处理

#声明游标（在声明赋值局部变量之前）
 DECLARE   游标名称  CURSOR  FOR  查询语句 ;

#打开游标

 OPEN   游标名称 ;

#获取游标记录
FETCH  游标名称  INTO  变量 [, 变量  ] ;

#关闭游标
CLOSE   
游标名称 ;

#eg：
create procedure p11(in uage int)
 begin
 declare uname varchar(100);
 declare upro varchar(100);
 declare u_cursor cursor for select name,profession from tb_user where age <= 
uage;
 drop table if exists tb_user_pro;
 create table if not exists tb_user_pro(
 id int primary key auto_increment,
 name varchar(100),
 profession varchar(100)
 );
 open u_cursor;
 while true do
 fetch u_cursor into uname,upro;
 insert into tb_user_pro values (null, uname, upro);
 end while;
 close u_cursor;
 end;

条件处理程序handler：

用来定义在流程控制结构执行过程中遇到问题时相应的处理步骤

DECLARE     handler_action   HANDLER FOR  condition_value  [, condition_value] .. statement ;

handler_action 的取值： 
CONTINUE: 继续执行当前程序
EXIT: 终止执行当前程序


condition_value 的取值： 

#SQLSTATE  sqlstate_value: 状态码，如 02000
declare exit handler for SQLSTATE '02000' close u_cursor;

SQLWARNING: 所有以01开头的SQLSTATE代码的简写
NOT FOUND: 所有以02开头的SQLSTATE代码的简写
SQLEXCEPTION: 所有没有被SQLWARNING 或 NOT FOUND捕获的SQLSTATE代码的简写  

declare exit handler for not found close u_cursor;

六.存储函数：

有返回值的存储过程，存储函数的参数只能是IN类型的

 CREATE  FUNCTION   存储函数名称 ([ 参数列表 ])
 RETURNS  type  [characteristic ...]
 BEGIN-- SQL语句
RETURN ...;
 END ;

#DETERMINISTIC：相同的输入参数总是产生相同的结果
#NO SQL ：不包含 SQL 语句。
#READS SQL DATA：包含读取数据的语句，但不包含写入数据的语句。

七.触发器：

是与表有关的数据库对象，指在insert/update/delete之前(BEFORE)或之后(AFTER)，触 发并执行触发器中定义的SQL语句集合；使用别名OLD和NEW来引用触发器中发生变化的记录内容，现在触发器还只支持行级触发（更改涉及几行数据，触发几次），不支持语句级触发。

 

#创建

CREATE  TRIGGER  trigger_name 
 BEFORE/AFTER  INSERT/UPDATE/DELETE
 ON tbl_name   FOR EACH ROW  -- 行级触发器
BEGIN
 trigger_stmt ;
 END;

#查看
SHOW  TRIGGERS ;

#删除

DROP  TRIGGER  [schema_name.]trigger_name ; 
 -- 如果没有指定 schema_name，默认为当前数据库 。

八.锁：

计算机协调多个进程或线程并发访问某一资源的机制

分类：

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

全局锁：

是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语 句，已经更新操作的事务提交语句都将被阻塞。（典型的使用场景是做全库的逻辑备份）

#加全局锁（任意位置）

 flush tables with read lock ;

#数据备份（退出mysql执行）
mysqldump  -uroot –p1234  itcast > itcast.sql

#释放锁
unlock tables ;

全局锁的弊端：如果在主库上备份，那么在备份期间都不能执行更新。 如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志（binlog），会导致主从延迟。

措施：InnoDB引擎中，可以在备份时加上参数 --single-transaction 参数来完成不加锁的一致性数据备份。

 mysqldump  --single-transaction  -uroot –p123456  itcast > itcast.sql

表级锁：

每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低

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

加锁：lock tables 表名... read/write。
释放锁：unlock tables / 客户端断开连接 。

读锁：所有用户只可读不可写（加锁用户执行写报错，其余用户执行写阻塞直到解锁）

写锁：仅加锁用户可读可写，其余用户读与写均被阻塞直到解锁

元数据锁：MDL

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

当对一张表进行增删改查的时候，加MDL读锁(共享)；当对表结构进行变更操作的时候，加MDL写锁(排他)。

#查看元数据锁情况
select object_type,object_schema,object_name,lock_type,lock_duration from 
performance_schema.metadata_locks ;

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

意向共享锁(IS): 由语句select ... lock in share mode添加 。与表锁共享锁 (read)兼容，与表锁排他锁(write)互斥。

意向排他锁(IX): 由insert、update、delete、select...for update添加 。与表锁共享锁(read)及排他锁(write)都互斥。

意向锁之间不会互斥，事务提交了，意向共享锁、意向排他锁，都会自动释放

#查看意向锁与行锁情况

select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from 
performance_schema.data_locks;

行级锁：

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

行锁：通过对索引上的索引项加锁来实现的，而不是对记录加的锁。锁定单个行记录的锁，防止其他事务对此行进行update和delete。在 RC、RR隔离级别下都支持。

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

间隙锁：锁定索引记录间隙（向前间隙，不含该记录），确保索引记录间隙不变，防止其他事务在这个间隙进行insert，产生幻读。在RR隔离级别下都支持。（间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存，一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用间隙锁。）

临键锁：行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap。 在RR隔离级别下支持

InnoDB使用 next-key 锁进行搜索和索引扫描，以防止幻读。

• 针对唯一索引进行检索时，对已存在的记录进行等值匹配时，将会自动优化为行锁。 InnoDB的行锁是针对于索引加的锁，不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，此时 就会升级为表锁。
• 索引上的等值查询(唯一索引)，给不存在的记录加锁时, 优化为间隙锁 。
• 索引上的等值查询(非唯一普通索引)，向右遍历时最后一个值不满足查询需求时，next-key lock 退化为间隙锁。 索引上的范围查询(唯一索引)--会访问到不满足条件的第一个值为止。
• 索引上的范围查询(唯一索引)--会访问到不满足条件的第一个值为止（eg：查询的条件为id>=19，是将19加了行锁，25（是第一个数据）的临键锁（包含25及25之前的间隙），正无穷的临键锁(正无穷及到25的间隙)。）