MySQL进阶部分

存储引擎

MySQL体系结构图：

• 连接层：

  最上层是一些客户端连接服务，主要完成一些类似于连接处理 ，授权认证及相关的安全方案。服务器也会为安全接入的每个用户端验证它所具有的操作权限。

• 服务层：

  第二层架构主要完成大多数的核心服务功能，如SQL接口，并完成缓存的查询，SQL的分析和优化，部分内置函数的执行。所有跨存储引擎的功能也在这一层实现，如过程，函数等。

• 引擎层：

  存储引擎真正的负责了MySQL中数据的存储和提取，服务器通过API和存储引擎进行通信，不同的存储引擎具有不同的功能，这样我们可以根据自己的需要，来选取合适的存储引擎。

• 存储层

  主要是将数据存储在文件系统上，并完成与存储引擎的交互

简介

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

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

   show engines

存储引擎的特点

1. InnoDB

   • 介绍：InnoDB是一种兼顾高可靠性和高性能的通用存储引擎，在MySQL 5.5之后，InnoDB是默认的 MySQL存储引擎

   • 特点：

     • DML操作遵循ACID模型，支持 事务

     • 行级锁，提高并发访问性能

     • 支持 外键 FORIGN KEY 约束，保证数据的完整性和正确性

   • 文件：

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

     参数：

     innoDB_file_per_table

2. MyISAM

   • 介绍：MyISAM是MySQL早期默认的存储引擎

   • 特点：

     • 不支持事务，不支持外键

     • 支持表锁，不支持行锁

     • 访问速度快

   • 文件：

     • xxx.sdi: 表结构信息

     • xxx.MYD: 存储数据

     • xxx.MYI: 存储索引

3. Memory

   • 介绍：Memory引擎的表数据是存储在内存中的，由于受到硬件问题，或断电问题的影响，只能将这些表作为临时表或缓存使用。

   • 特点：

     • 内存存放

     • hash索引（默认）

   • 文件：

     • xxx.sdi：表结构信息

存储引擎的选择

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

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

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

Linux中MySQL安装：

虚拟机中安装mysql 完整教程-简单实用-亲测有效（ CentOS7 版本）_虚拟机安装mysql-CSDN博客

索引

索引的概述

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

• 优缺点：

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

索引结构

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

• B-Tree(多路平衡查找树)

有n个节点就有 n+1 个指针

• B+Tree  
  • 相对于B-Tree的区别：
    • 所有的数据都会出现在叶子节点

    • 叶子节点形成一个单向链表

• mysql索引数据结构对经典的B+Tree进行了优化。在原B+Tree基础上，增加了一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的B+Tree

• Hash

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

  • Hash索引特点

    1. Hash索引只能用于对等比较(=,in),不支持范围查询(between, <, >, ...)

    2. 无法利用索引完成排序操作

    3. 查询效率高，通常只需要一次检索就可以了，效率通常要高于B+Tree索引

  • 存储引擎支持

    在MySQL中，支持hash索引的是Memory引擎，而InnoDB中具有自适应hash功能，hash索引是存储是存储引擎根据B+Tree索引在指定条件下自动构建的。

• 面试题：

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

    • 相较于二叉树，层级更少，搜索效率高

    • 对于B-tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低

  • 为什么使用B+Tree索引而不采用hash索引

    • Hash索引只能用于对等比较(=,in),不支持范围查询(between, <, >, ...)

索引的分类

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

聚集索引选取规则：

1. 如果存在主键，主键索引就是聚集索引

2. 如果不存在主键，将使用第一个唯一(UNIQUE)索引作为聚集索引

3. 如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引

• 聚集索引挂载数据为行数据

• 二级索引挂载数据为数据id

索引语法

创建索引

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性能分析

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)种配置如下信息：

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

配置完成后，通过以下指令重启MySQL服务器进行测试，查看慢日志文件中记录的信息 /var/lib/mysql/localhost-slow.log

profile详情

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

SELECT @@have_profiling;

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

SET profiling = 1;

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

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

explain执行计划

EXPLAIN 或者 DESC 命令获取MySQL如何执行 SELECT 语句的信息，包括在 SELECT 语句的信息，包括在SELCET 语句执行过程中表如何连接和连接顺序。

//直接在select语句之前加上关键字 explain/desc、
EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件;

EXPLAIN执行计划个字段的含义：

• Id:

  select 查询的序列号，表示查询中执行 select 子句或者是操作表的顺序(id相同，执行顺序从上到下；id不同，值越大，越先执行)

• select_type:

  表示 SELECT 的类型，常见的取值有 SIMPLE (简单表，即不用表连接或者子查询)、PRIMARY(主查询，即外层查询)、UNION(UNION中的第二个或者后面的查询语句)、SUBQUERY(SELECT/WHERE之后包含子查询)等

• type：

  表示连接类型，性能由好到差的连接类型为NULL，system，const，eq_ref，ref，range，index，all

• possible_key

  显示可能应用在这张表上的索引，一个或多个。

• Key

  实际使用的索引，如果为NULL，则没有使用索引

• Key_len

  表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，再不损失精确性的前提下，长度越长越好

• rows

• filtered

索引的使用

• 最左前缀法则

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

  • 如果跳跃某一列， 索引将部分失效(后面的字段索引失效)

  • 存在即可，和写的顺序无关

• 范围查询

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

• 索引列运算

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

• 字符串不加引号

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

• 模糊查询

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

• or 连接条件

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

• 数据分布影响

  • 如果MySQL评估使用索引比全表更慢，则不使用索引。

• SQL提示

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

  • use index

    explain select * from Table1 use index(idx_user_name) where userName = 'Victor';

  • ignore index

    explain select * from Table1 ignore index(idx_user_name) where userName = 'Victor';

  • force index

    explain select * from Table1 force index(idx_user_name) where userName = 'Victor';

• 覆盖索引

  • 尽量使用覆盖索引(查询使用索引，并且需要返回的列，在该索引中已经能够全部找到)，减少 select *。

  • 注意：

    • using index condition: 查找使用索引，但是需要回表查询数据

    • using where；using index：查找使用索引，但是需要的数据都在索引列中能找到，所以不需要回表查询数据

• 前缀索引

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

  • 语法：

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

  • 前缀长度

    可以根据索引的选择性来决定，而选择性是指不重复的索引值(基数)和数据表的记录总数的比值，索引选择性越高则查询效率越高，唯一索引的选择就是1，这是最好的索引选择性，性能也是最好的。

• 单列索引和联合索引的选择

  • 单列索引：即一个索引只包含单个列

  • 联合索引：即一个索引包含了多个列

  • 多条件查询时MySQL优化器会评估哪个字段的索引效率更高，会选择该索引完成本次查询

索引的设计原则

1. 针对数据量较大而且查询频繁的表建立索引。（数据超过100w）

2. 针对于常作为查询条件(where)、排序(order by)、分组(group by)操作的字段建立索引。

3. 尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。

4. 如果是字符串型的字符，字段的长度较长，可以针对于字段的特点建立前缀索引。

5. 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表。

6. 要控制索引数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率。

7. 如果索引列不能存储NULL值，请在建表时使用NOT NULL约束它，当优化器知道每列是否包含NULL值时，它可以更好的确定哪个索引最有效的用于查询。

SQL优化

插入数据

insert优化

insert into Table values(1,"tom");
insert into Table values(2,"timy");
insert into Table values(3,"jack");

• 批量插入

  insert into Table values(1,"tom"),(2,"timy"),(3,"jack");

• 手动事务提交

  start transaction;
  insert into Table values(1,"tom");
  insert into Table values(2,"timy");
  insert into Table values(3,"jack");
  commit;

• 主键顺序插入

大批量插入数据

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

//客户端连接服务端时，加上参数 --local-infile
mysql--local-infile -u root -p
//设置全局参数--local-infile为1，开启从本地加载文件导入数据的开关
set global local_infile=1;
//执行load指令将准备好的数据，加载到表结构中
load data local infile '文件路径' into table '表名' fields terminated by ',' lines terminated by '\n';

主键优化

数据组织方式

在InnoDB存储引擎中，表数据都是根据主键顺序组织存放的，这种存储方式的表称为 索引组织表(index organized table IOT)

• 页分裂：页可以为空，也可以填充一半，也可以填充100%。每个页包含了 2-N 行数据(如果一行数据过大，就会行溢出)，根据主键排列。

• 页合并：

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

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

• 主键设计原则

  • 满足业务需求的情况下，尽量降低主键的长度

  • 插入数据时，尽量选择顺序插入，选择尽量使用 AUTO_INCREMENT自增主键

  • 尽量不要使用UUID或者其他自然主键作为主键，如身份证号(乱序插入，导致页分裂现象)

  • 业务操作尽量减少逐主键修改

order by优化

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

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

注意：

• 索引创建时的字段顺序应该和排序时字段数据一致

• 创建索引默认都是按照从小到大排

• 如需优化在创建索引时需要在字段代码段指定排序方式 asc/desc

总结：

• 根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则

• 尽量使用覆盖索引

• 多字段排序，一个升序一个降序，此时需要注意联合索引在创建时的规则(ASC/DESC)

• 如果不可避免的出现filesort，大数据量排序时，可以适当增大排序缓冲区大小 sort_buffer_size(默认256k)

Group By优化

• 创建索引增加效率

• 同样需要满足最左前缀法则

limit优化

值越大，查询效率越低

覆盖索引＋子查询进行优化

count 优化

• count的几种用法

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

  • 用法count(*), count(主键), count(字段), count(1)

Update 优化

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

视图

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

• 创建视图：

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

• 查询

  //查看创建视图语句：
  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 [IF EXISTS] 视图名称[,视图名称]...

视图检查选项

当使用WITH CHECK OPTION子句创建视图时，MySQL会通过视图检查正在更改的每个行，例如：插入、更新、删除、以使其符合视图的定义。MySQL允许基于另一个视图创建视图，它还会检查依赖视图中的规则以保证一致性。mysql提供两个选择：CASCADED和LOCAL默认为CASCADED

视图更新

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

1. 聚合函数或窗口函数(SUM(), MIN(), MAX(), COUNT())

2. DISTINCT

3. GROUP BY

4. HAVING

5. UNION 或者UNION ALL

视图作用

1. 简单：

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

2. 安全：

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

3. 数据独立：

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

存储过程

• 介绍：

  • 存储过程是事先经过编译并存储再数据库中的一段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语句结束。

• 变量：

  系统变量是MySQL服务器提供，不是用户定义的，属于服务器层面。分为全局变量(GLOBAL)、绘画变量(SESSION)

  • 查看系统变量

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

  • 设置系统变量

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

用户定义变量

是用户根据需要自己定义的变量，用户变量不用提前声明在用的时候直接用"@变量名"即可。其作用域为当前连接。

• 赋值

  SET @var_name=expr[,@var_name=expr]...;
  SET @var_name:=expr[,@var_name:=expr]...;
  ​
  SELECT @var_name:=expr[,@var_name:=expr]...;
  SELECT 字段名 INTO @var_name FROM 表名;

• 使用

  SELECT @var_name;

• 注意：用户定义的变量无需对其进行声明或者初始化，只不过获取到的值为NULL。

局部变量

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

• 声明

  DECLARE 变量名 变量类型[DEFAULT...];

  变量类型就是数据库字段类型：INT,VARCHAR,BIGINT...

• 赋值

  SET 变量名 = 值;
  SET 变量名 := 值;
  SELECT 字段名 INTO 变量名 FROM 表名...;

if

语法：

if 条件1 THEN
    ...
ELSEIF 条件2 THEN
    ...
ELSE
    ...
END IF;

参数

• 用法：

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

case

• 语法1：

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

• 语法2：

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

while

while循环是有条件的循环控制语句。满足条件后，再执行循环体中的SQL语句，具体语法为：

//先判定条件，如果条件为true，执行
WHILE 条件 DO
    SQL逻辑
END WHILE;

repeat

repeat是有条件的循环控制语句，当满足条件的时候退出循环。具体语法为：

REPEAT
    SQL逻辑
    UNTIL 条件
END REPEAT;

loop

LOOP实现简单的循环，如果不在SQL逻辑中增加推出的循环条件，可以用来实现简单的死循环。LOOP可以配合以下两个语句使用：

• LEAVE: 配合循环使用，退出循环。

• ITERATE: 必须用在循环中，作用是跳过当前循环剩下的语句，直接进入下一次循环

[begin_lable:]LOOP
    SQL逻辑...
END LOOP[end_lable];

游标-cursor

游标是用来存储查询结果集的数据类型，在存储过程和函数中，可以使用游标对结果集进行循环处理。游标的使用包括游标的声明，OPEN,FETCH,CLOSE，其语法如下

1. 游标的声明：

   DECLARE 游标名称 CURSOR POR 查询语句;

2. 打开游标：

   OPEN 游标名称;

3. 获取游标记录

   FETCH 游标名称 INTO 变量[,变量];

4. 关闭游标：

   CLOSE 游标名称;

存储函数

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

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

characteristic说明：

• DETERMINISTIC：相同的输入参数总是产生相同效果

• NO SQL：不包含SQL语句

• READS SQL DATA：包含读取数据的语句，但不包含写入数据的语句

触发器

介绍：

• 触发器是与表有关的数据库对象，指在insert/update/delete 之前或之后，触发并执行触发器中定义的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，则默认为当前数据库

锁

保证数据并发访问的一致性、有效性是数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。

分类：

MySQL中的锁，按照锁的粒度分，分为以下三类：

1. 全局锁：锁定数据库中的所有表

2. 表级锁：每次操作锁住整张表

3. 行级锁：每次操作锁住对应的行数据

全局锁

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

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

• 演示

• 特点

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

  1. 如果在主库上备份，那么在备份期间都不能执行更新，业务基本上停摆

  2. 如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志(binlog)，会导致主从延迟。

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

  mysqldump --single-transaction -uroot -p123456 数据库名称 > 存储文件位置.sql

表级锁

• 介绍

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

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

    1. 表锁

    2. 元数据锁(meta data lock, MDL)

    3. 意向锁

表锁

对于表锁分为两类：

1. 表共享锁(read lock)

2. 表独占写锁(write lock)

语法：

1. 加锁：

   lock tables 表名... read/write

2. 释放锁：

   unlock tables/客户端断开连接

读锁不会阻塞其他客户端的读，但是会阻塞写。写锁既会阻塞其他客户端的读，又会阻塞其他客户端的写

元数据锁

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

在MySQL5.5中引入了MDL，当对一张表进行增删改查的时候，加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, uptate, delete, select ... for uptate 添加

  • 与表锁共享锁（read）及排他锁（write）都互斥。意向锁之间不会互斥。

• 查看意向锁：

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

行级锁

• 行级锁，每次操作锁住对应的行数据，锁定粒度最小，发生锁冲突概率最低，并发度最高。应用在InnoDB存储引擎中。

• InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项来加锁的，而不是对记录加的锁。主要分为以下三类：

  • 行锁(Record Lock)：锁定单个行记录的锁，防止其他事务对此进行update和delete。在RC, RR隔离级别下都支持。

  • 间隙锁(Gap Lock)：锁定索引记录间隙（不含该记录），确保索引记录间隙不变，防止其他事务在这个间隙进行insert，产生幻读。在RR隔离级别下都支持。

  • 临键锁(Next-Key Lock)：行锁和间隙锁组合，同时锁住数据和其前的gap，在RR隔离级别下支持。

行锁

InnoDB实现了以下2种类型的行锁：

1. 共享锁(S)：允许一个事务去读一行，阻止其他事务获取相同的数据集的排他锁

2. 排他锁(X)：允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排它锁。

默认情况下，InnoDB在REPEATABLE READ事务隔离级别运行，InnoDB使用 next-key 锁进行搜索和索引扫描，以防止幻读。

1. 针对唯一索引进行检索时，对已存在的记录进行等值匹配时，将会自动优化为行锁。

2. InnoDB的行锁是针对于索引加的锁，不通过索引条件检索数据，那么InnoDB将对表中所有记录加锁，此时 就会升级为表锁

3. 查看行锁：

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

间隙锁/临键锁

默认情况下，InnoDB在 REPEATABLE READ事务隔离级别运行，InnoDB使用 next-key 锁进行扫描，以防止幻读：

1. 索引上的等值查询(唯一索引)，给不存在的记录加锁时，优化为间隙锁。

2. 索引上的等值查询(普通索引)，向右遍历时，最后一个值不满足查询需求时，next-key 退化为间隙锁。

3. 索引上的范围查询(唯一索引)--会访问到不满足条件的第一个值为止。

注意：间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存，一个事务采用的间隙锁，不会阻止另一个事务在同一间隙上采用间隙锁

InnoDB引擎

逻辑存储结构：

架构

MySQL5.5开始，默认使用InnoDB存储引擎，他擅长处理事务，具有崩溃恢复特性，在日常开发中使用非常广泛。下面是InnoDB架构图，左侧为内存结构，右侧为磁盘结构。

后台线程

1. Master Thread：

   核心后台线程，负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中，保持数据一致性，还包括脏页刷新，合并插入缓存，undo页的回收。

2. IO Thread：

   在InnoDB存储引擎中大量使用了AIO来处理IO请求，这样可以极大地提高数据库的性能，而IO Thread主要负责这些IO请求的回调。

   线程类型	默认个数	职责
   Read Thread	4	负责读操作
   Write Thread	4	负责写操作
   Log Thread	1	负责将日志缓冲区刷新到磁盘
   Insert buffer Thread	1	负责将写缓冲区内容刷新到磁盘

3. Purge Thread

   主要用于回收事务已经提交了的 undo log，在事务提交之后，undo log可能不用了，就用它来回收。

4. Page Cleaner Thread

   协助 Master Thread 刷新脏页到磁盘的线程，它可以减轻 Master Thread 的工作压力，减少阻塞。

事务原理

redo log -- 持久性

• 重做日志，记录的是事务提交的物理修改，是用来实现事务的持久性。

• 该日志文件由两部分组成：重做日志缓冲(redo log buffer) 以及重做日志文件(redo log file), 前者是在内存中，后者在磁盘中。当事务提交之后会把所有的修改信息都存到该日志文件中，用于刷新脏页到磁盘，发生错误时，进行数据恢复使用。

undo log -- 原子性

• 回滚日志，用于记录数据被修改前的信息，作用包含两个：

  • 提供回滚

  • MVCC（多版本并发控制）

• 是逻辑日志

• undo log销毁：undo log在事务执行时产生，事务提交时，并不会立即删除 undo log，因为这些日志还可能用于MVCC

• undo log存储：undo log采用段的方式进行管理和记录，存放在前面介绍的 rollback segament 回滚段中，内部包含1024个 undo log segment。

MVCC

当前读：

读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们的日常操作，如：

都算一种当前读。

快照读：

简单的select（不加锁）就是快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。

• Read Committed：每次select，都生成一个快照读。

• Repeatable Read：开启事务后第一个select语句才是快照读的地方

• Serializable：快照读会退化为当前读

MVCC

全称 Multi-Version Concurrency Control, 多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞功能呢。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段，undo log 日志， readView

undo log版本链

不同的事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧纪录。

readview

ReadView(读视图) 是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务(未提交的)id。

ReadView中包含了四个核心字段：

1. m_ids：当前活跃的事务ID集合

2. min_trx_id：最小活跃事务ID

3. max_trx_id：预分配事务ID，当前最大事务ID+1（因为事务ID是自增的）

4. creator_trx_id：ReadView创建者的事务ID

不同隔离级别，生成ReadView的时机不同：

• READ COMMITTED：在事务中每一次执行快照读时，生成ReadView

• REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView

MySQL管理

mysql常用工具

• mysql

• mysqladmin

• mysqlshow

• mysqldump

• mysqlimport/source