MySQL进阶篇--超赞详尽学习笔记(好评如潮）

前言：首先感谢您的阅览，本篇记录的是mysql的进阶知识和面试重灾区的答案，如若有不足之处诸位多多包涵，也欢迎您的指正。也希望看完本篇笔记，您能心有所得。能解决您的疑惑与问题是本篇最大的荣誉。
学习分篇目标

如果你想回顾MySQL之前的知识（基础篇），传送门：http://t.csdn.cn/7oM1f

---

一.MySQL体系结构

下面是每层的详细解释说明

1). 连接层
最上层是一些客户端和链接服务，包含本地sock 通信和大多数基于客户端/服务端工具实现的类似于TCP/IP的通信。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于SSL的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。

2). 服务层
第二层架构主要完成大多数的核心服务功能，如SQL接口，并完成缓存的查询，SQL的分析和优化，部分内置函数的执行。所有跨存储引擎的功能也在这一层实现，如 过程、函数等。在该层，服务器会解析查询并创建相应的内部解析树，并对其完成相应的优化如确定表的查询的顺序，是否利用索引等，最后生成相应的执行操作。如果是select语句，服务器还会查询内部的缓存，如果缓存空间足够大，这样在解决大量读操作的环境中能够很好的提升系统的性能。

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

4). 存储层
数据存储层， 主要是将数据(如: redolog、undolog、数据、索引、二进制日志、错误日志、查询日志、慢查询日志等)存储在文件系统之上，并完成与存储引擎的交互。和其他数据库相比，MySQL有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎上，插件式存储引擎架构，将查询处理和其他的系统任务以及数据的存储提取分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。

---

二.存储引擎

2.1 存储引擎简介

存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式 。存储引擎是基于表的，而不是基于库的，所以存储引擎也可被称为表类型。我们可以在创建表的时候，来指定选择的存储引擎，如果没有指定将自动选择默认的存储引擎InnoDB。

建表时指定存储引擎

CREATE TABLE 表名(
字段1 字段1类型 [ COMMENT 字段1注释 ] ,
......
字段n 字段n类型 [COMMENT 字段n注释 ]
) ENGINE = INNODB [ COMMENT 表注释 ] ;

查询建表语句
show create table account;

查询当前数据库支持的存储引擎
show engines ;

创建表 my_myisam , 并指定MyISAM存储引擎

create table my_myisam(
id int,
name varchar(10)
) engine = MyISAM ;

---

2.2 存储引擎特点

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

2). 特点

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

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

show variables like 'innodb_file_per_table'; 查看是否开启

如果该参数开启，代表对于InnoDB引擎的表，每一张表都对应一个ibd文件。 我们直接打开MySQL的数据存放目录： C:\ProgramData\MySQL\MySQL Server 8.0\Data ， 这个目录下有很多文件夹，不同的文件夹代表不同的数据库

• 表空间 : InnoDB存储引擎逻辑结构的最高层，ibd文件其实就是表空间文件，在表空间中可以包含多个Segment段。

• 段 : 表空间是由各个段组成的， 常见的段有数据段、索引段、回滚段等。InnoDB中对于段的管理，都是引擎自身完成，不需要人为对其控制，一个段中包含多个区。

• 区 : 区是表空间的单元结构，每个区的大小为1M。 默认情况下， InnoDB存储引擎页大小为
  16K， 即一个区中一共有64个连续的页。

• 页 : 页是组成区的最小单元，页也是InnoDB 存储引擎磁盘管理的最小单元，每个页的大小默认为 16KB。为了保证页的连续性，InnoDB 存储引擎每次从磁盘申请 4-5 个区。

• 行 : InnoDB 存储引擎是面向行的，也就是说数据是按行进行存放的，在每一行中除了定义表时所指定的字段以外，还包含两个隐藏字段

---

MyISAM
1). 介绍
MyISAM是MySQL早期的默认存储引擎。

2). 特点
不支持事务，不支持外键
支持表锁，不支持行锁
访问速度快

3). 文件
xxx.sdi：存储表结构信息
xxx.MYD: 存储数据
xxx.MYI: 存储索引

InnoDB与MyISAM的三大区别

---

2.3 存储引擎选择

• InnoDB: 是Mysql的默认存储引擎，支持事务、外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询之外，还包含很多的更新、删除操作，那么InnoDB存储引擎是比较合适的选择。
• MyISAM ： 如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么选择这个存储引擎是非常合适的。
• MEMORY：将所有数据保存在内存中，访问速度快，通常用于临时表及缓存。MEMORY的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，而且无法保障数据的安全性。

MyISAM现在被MongoDB替代了

MEMORY现在被Redis替代了

---

三.索引

3.1 索引概述

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

下图只是演示，便于理解，并非真实索引结构

---

3.2 索引结构

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

下面是不同的存储引擎对于索引结构的支持情况。

---

如果主键是顺序插入的，则会形成一个单向链表

如果选择二叉树作为索引结构，会存在以下缺点：

• 顺序插入时，会形成一个链表，查询性能大大降低。
• 大数据量情况下，层级较深，检索速度慢。

红黑树是一颗自平衡二叉树，那这样即使是顺序插入数据，最终形成的数据结构也是一颗平衡的二叉树，但是，即使如此，由于红黑树也是一颗二叉树，所以也会存在一个缺点：

• 大数据量情况下，层级较深，检索速度慢

---

3.2.1 B-Tree

B-Tree，B树是一种多叉路衡查找树，相对于二叉树，B树每个节点可以有多个分支，即多叉。以一颗最大度数（max-degree）为5(5阶)的b-tree为例，那这个B树每个节点最多存储4个key，5个指针：
树的度数指的是一个节点的子节点个数。
解释：↓ key1 ↓ key2 ↓ key3 ↓ key4 ↓ （刚好五个指针（五个范围），四个key）

数据结构可视化的网站：https://www.cs.usfca.edu/~galles/visualization/BTree.html

当插入元素，当前结点数量超过最大key数量，取中间元素，向上分裂，抽出来放上面

我感觉是讲不清楚，必须的动画演示，直接拉到视频第7分钟看，地址：https://www.bilibili.com/video/BV1Kr4y1i7rup=68&spm_id_from=pageDriver&vd_source=66adabb689f7d7561280e7a943c2879d

奇数去网站实验过了 比如Degree=4 就把中间靠左的那个数拿上去

---

B树特点

• 5阶的B树，每一个节点最多存储4个key，对应5个指针。
• 一旦节点存储的key数量到达5，就会裂变，中间元素向上分裂。
• 在B树中，非叶子节点和叶子节点都会存放数据。

---

3.2.2 B+Tree

B+Tree是B-Tree的变种，我们以一颗最大度数（max-degree）为4（4阶）的b+tree为例

• 绿色框框起来的部分，是索引部分，仅仅起到索引数据的作用，不存储数据。
• 红色框框起来的部分，是数据存储部分，在其叶子节点中要存储具体的数据

所有叶节点包含所有关键字，叶节点将关键字按大小排列，并且相邻叶节点按大小顺序链接起来，非叶子节点主要起到索引作用，叶子节点包含了所有插入的元素

B+Tree 与 B-Tree相比，主要有以下三点区别：

• 所有的数据都会出现在叶子节点。
• 叶子节点形成一个单向链表。
• 非叶子节点仅仅起到索引数据作用，具体的数据都是在叶子节点存放的。

---

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

表空间->段->区->页->行，一个页默认大小是16kb

---

3.2.3 Hash

特点

• Hash索引只能用于对等比较(=，in)，不支持范围查询（between，>，< ，…）
• 无法利用索引完成排序操作
• 查询效率高，通常(不存在hash冲突的情况)只需要一次检索就可以了，效率通常要高于B+tree索引

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

---

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

• 相对于二叉树在顺序插入形成的单向链表，层级更少，搜索效率高；
• 对于B-tree，无论是叶子节点还是非叶子节点，都会保存数据，而页的大小固定为16kb，这样导致一页中存储的key键值减少，指针跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低；
• 相对Hash索引只支持等值匹配，B+tree支持范围匹配及排序操作；

---

3.4 索引分类

在MySQL数据库，将索引的具体类型主要分为以下几类：主键索引、唯一索引、常规索引、全文索引

---

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

可以这样理解，可以通过聚簇索引（一般都是主键索引）直接查到数据，如果通过二级索引，则需要通过二级索引定位数据对应的主键索引（聚簇索引），再通过主键索引（聚簇索引）找到数据，因为聚簇索引的叶子节点有数据

聚集索引选取规则:

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

---

聚簇索引叶子结点下面挂的是行数据（记录）

顾名思义，二级索引，指向的也是索引

查询过程

具体过程如下:

①. 由于是根据name字段进行查询，所以先根据name='Arm’到name字段的二级索引中进行匹配查找。但是在二级索引中只能查找到 Arm 对应的主键值 10。
②. 由于查询返回的数据是*，所以此时，还需要根据主键值10，到聚集索引中查找10对应的记录，最终找到10对应的行row。
③. 最终拿到这一行的数据，直接返回即可

回表查询： 这种先到二级索引中查找数据，找到主键值，然后再到聚集索引中根据主键值，获取数据的方式，就称之为回表查询。

---

InnoDB主键索引的B+tree高度为多高呢?

假设:
一行数据大小为1k，一页中可以存储16行这样的数据。InnoDB的指针占用6个字节的空间，主键即使为bigint，占用字节数为8。

高度为2：
n * 8 + (n + 1) * 6 = 16*1024 , 算出n约为 1170 (指针数量）

1171* 16 = 18736
也就是说，如果树的高度为2，则可以存储 18000 多条记录。

高度为3：
1171 * 1171 * 16 = 21939856
也就是说，如果树的高度为3，则可以存储 2200w 左右的记录。

---

3.5 索引语法

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

2). 查看索引
SHOW INDEX FROM table_name ;

3). 删除索引
DROP INDEX index_name ON table_name ;

---

范例

A. name字段为姓名字段，该字段的值可能会重复，为该字段创建索引。

CREATE INDEX idx_user_name ON tb_user(name);

B. phone手机号字段的值，是非空，且唯一的，为该字段创建唯一索引。

CREATE UNIQUE INDEX idx_user_phone ON tb_user(phone);

C. 为profession、age、status创建联合索引。

CREATE INDEX idx_user_pro_age_sta ON tb_user(profession,age,status);

D. 为email建立合适的索引来提升查询效率。

CREATE INDEX idx_email ON tb_user(email);

查看tb_user表的所有的索引数据。

show index from tb_user;

删除索引

drop index idx_email on tb_user;

---

3.6 SQL性能分析

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

• session 是查看当前会话 ;
• global 是查询全局数据 ;

后面跟7个下划线 查看SQL语句执行的频次

show global status like ‘Com_______’;

可以查看到当前数据库到底是以查询为主，还是以增删改为主，从而为数据库优化提供参考依据

如果是以增删改为主，我们可以考虑不对其进行索引的优化。 如果是以查询为主，那么就要考虑对数据库的索引进行优化了。

---

3.6.1 慢查询日志

记录查看耗时超过默认值的SQL

MySQL的慢查询日志默认没有开启，我们可以查看一下系统变量 slow_query_log。默认是OFF

show variables like 'slow_query_log';

注意下面操作不在mysql中了，finalshell复制一个窗口出来，下面是linux命令

如果要开启慢查询日志，需要在MySQL的配置文件（/etc/my.cnf）中配置如下信息：

# 进入配置文件中编辑
vi /etc/my.cnf

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

更改好后保存并退出，需要重启mysql服务

systemctl restart mysqld 

再重新进入mysql，查看开关情况，慢查询日志就已经打开了

mysql -u root -p

show variables like 'slow_query_log';

---

到另一个窗口，执行linux命令
查看慢日志文件中记录的信息/var/lib/mysql/localhost-slow.log

cd /var/lib/mysql

可以看到我的slow.log文件叫aliyun-slow.log，每个人的慢查询日志名称虽然不同，但后缀一定是-slow.log

查看慢查询日志文件

# 这里填你的慢查询日志名称
cat aliyun-slow.log

最终我们发现，在慢查询日志中，只会记录执行时间超多我们预设时间（2s）的SQL，执行较快SQL是不会记录的。

那这样，通过慢查询日志，就可以定位出执行效率比较低的SQL，从而有针对性的进行优化。

---

3.6.2 profile详情

show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。

通过have_profiling参数，能够看到当前MySQL是否支持profile操作：
SELECT @@have_profiling ;

可以看到，当前MySQL是支持 profile操作的，但是开关是关闭的。0是关闭，1是开启
SELECT @@profiling ;

可以通过set语句在session/global级别开启profiling
SET profiling = 1;

---

开关已经打开了，接下来，我们所执行的SQL语句，都会被MySQL记录，并记录执行时间消耗到哪去了

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

#查看每一条SQL的耗时基本情况
show profiles;

#查看指定query_id的SQL语句各个阶段的耗时情况
show profile for query query_id;

#查看指定query_id的SQL语句CPU的使用情况
show profile cpu for query query_id;

注 ：query_id 是每条sql语句的id，可以看下图

查看每一条SQL的耗时情况

show profiles;

查看指定SQL各个阶段的耗时情况

---

3.6.3 explain

explain查看SQL语句的执行计划
因为单以执行时间长短判读SQL语句效率的高低过于武断

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

语法:

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

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

• MySQL认为必须要执行查询的行数，在innodb引擎的表中，是一个估计值，可能并不总是准确的。

---

filtered

• 表示返回结果的行数占需读取行数的百分比， filtered 的值越大越好。

---

主要关注字段

---

3.7 索引使用

3.7.1 验证索引效率

查询千万条数据的时候，如果根据id主键查，你会发现，查询速度很快，如果根据name查，你会发现耗时是前者的10倍甚至更多，针对字段创建索引后，根据该字段查询时间大大缩短

第一次创建索引时，会为所有数据构建一个B+树结构，耗时较长，但磨刀不误砍柴工，索引创建完毕后，再次查询，速度会飞一般的提升。

建立索引前后，查询耗时都不是一个数量级的。

---

3.7.2 最左前缀法则

如果索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列始，并且不跳过索引中的列。如果最左边的列不存在，索引将全部失效；如果跳跃某一列，索引将会部分失效(后面的字段索引失效)。
与放的顺序无关，只判断是否存在

注意 ： 最左前缀法则中指的最左边的列，是指在查询时，联合索引的最左边的字段(即是第一个字段)必须存在，与我们编写SQL时，条件编写的先后顺序无关。

---

3.7.3 范围查询

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

当范围查询使用> 或 < 时，走联合索引了，但是索引的长度为49，就说明范围查询右边的status字段是没有走索引的。
当范围查询使用>= 或 <= 时，走联合索引了，但是索引的长度为54，就说明所有的字段都是走索引的。

所以，在业务允许的情况下，尽可能的使用类似于 >= 或 <= 这类的范围查询，而避免使用 > 或 <

---

3.7.4 索引失效

• 不要在索引列上进行运算操作（包括使用函数）， 索引将失效。

• 字符串类型字段使用时，不加引号，索引将失效。（char型不加单引号情况）

• 如果仅仅是尾部模糊匹配(如like ‘软件%’)，索引不会失效。如果是头部模糊匹配(如like ‘%工程’)，索引失效。

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

• 如果MySQL评估使用索引比全表更慢，则不使用索引。(比如查询age>0的数据，全表age数据都大于0，就不走索引，而是全表扫描）

---

3.7.5 SQL提示

当一个字段有创建的单列索引，又有联合索引时，MySQL会按自己优化器自动选择使用哪条索引

你给MySQL一个提示，你要用什么索引。提示MySQL，具体碰到该问题如何执行，覆盖其默认规则

---

注：explain是查看该条SQL执行计划

explain select * from tb_user use index(索引名称) where profession = '软件工程';

use是建议，mysql会权衡该索引效率高不高，效率低不接受建议
mysql：你在教我做事？

---

explain select * from tb_user force index(索引名称) where profession = '软件工程';

force是一定要用，必须用该索引
我：想法不要太多，没什么用，昂！

---

explain select * from tb_user ignore index(索引名称) where profession = '软件工程';

ignore index ： 忽略指定的索引。

---

3.7.6 覆盖索引

回表：先走二级索引找到对应主键，然后再走主键索引找对到对应行数据

使用select * 就会出现回表查询情况，造成效率过低，这就是开发生产中尽量避免使用select * 的原因

---

思考题：
一张表, 有四个字段(id, username, password, status), 由于数据量大, 需要对以下SQL语句进行优化, 该如何进行才是最优方案：
select id,username,password from tb_user where username =‘itcast’;

答案: 针对于 username, password建立联合索引, sql为: create indexidx_user_name_pass on tb_user(username,password);
联合索引下面挂着的就是id，这样可以避免上述的SQL语句，在查询的过程中，出现回表查询。

---

3.7.7 前缀索引

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

语法
create index 索引名 on 表名(字段名(截取几个));

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

select count(distinct substring(email,1,5)) / count(*) from tb_user ;

---

3.7.8 单列索引与联合索引

单列索引：即一个索引只包含单个列。
联合索引：即一个索引包含了多个列。

如果查询使用的是联合索引，具体的结构示意图如下：

在业务场景中，如果存在多个查询条件，考虑针对于查询字段建立索引时，建议建立联合索引，而非单列索引

---

3.8 索引设计原则

针对三方面来设计：表，字段，索引

1). 针对于数据量较大（一张表数据量100多万那种），且查询比较频繁的表建立索引（索引只是提高检索效率）。

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

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

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

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

6). 要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率。
create unique index idx_user_phone_name on tb_user(phone,name);

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

---

四.SQL优化

4.1 插入数据优化

如果我们需要一次性往数据库表中插入多条记录，可以从以下三个方面进行优化。

1). 优化方案一
批量插入数据

Insert into tb_test values(1,'Tom'),(2,'Cat'),(3,'Jerry');

2). 优化方案二
手动控制事务。默认是自动提交，每次insert一条语句就提交一次事务，会造成频繁的事务开启与提交

start transaction;
insert into tb_test values(1,'Tom'),(2,'Cat'),(3,'Jerry');
insert into tb_test values(4,'Tom'),(5,'Cat'),(6,'Jerry');
insert into tb_test values(7,'Tom'),(8,'Cat'),(9,'Jerry');
commit;

3). 优化方案三
主键顺序插入，性能要高于乱序插入。

---

大批量插入数据
如果一次性需要插入大批量数据(比如: 几百万的记录)，使用insert语句插入性能较低，此时可以使用MySQL数据库提供的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' ;

主键顺序插入性能高于乱序插入

---

4.2 主键优化

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

---

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

主键顺序插入

①. 从磁盘中申请页， 主键顺序插入

②. 第一个页没有满，继续往第一页插入

③. 当第一个也写满之后，再写入第二个页，页与页之间会通过指针连接

④. 当第二页写满了，再往第三页写入

---

主键乱序插入

①. 加入1#,2#页都已经写满了，存放了如图所示的数据

②. 此时再插入id为50的记录，我们来看看会发生什么现象，会再次开启一个页，写入新的页中吗？
不会。因为，索引结构的叶子节点是有顺序的。按照顺序，应该存储在47之后。

但是47所在的1#页，已经写满了，存储不了50对应的数据了。 那么此时会开辟一个新的页 3#。
但是并不会直接将50存入3#页，而是会将1#页后一半的数据，移动到3#页，然后在3#页，插入50。

移动数据，并插入id为50的数据之后，那么此时，这三个页之间的数据顺序是有问题的。 1#的下一个页，应该是3#， 3#的下一个页是2#。 所以，此时，需要重新设置链表指针。

上述的这种现象，称之为 “页分裂”，是比较耗费性能的操作。

---

页合并

会自动合并，将3号数据页数据合并到2号数据页

再插入20，直接放在3号数据页

MERGE_THRESHOLD：合并页的阈值，可以自己设置，在创建表或者创建索引时指定

---

主键设计原则

• 满足业务需求的情况下，尽量降低主键的长度。（因为聚集索引有一个，但二级索引有多个，每个二级索引下面叶子节点挂的是主键，主键过长，占用大量磁盘空间，搜索时耗费大量磁盘IO)

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

• 尽量不要使用UUID做主键或者是其他自然主键，如身份证号。

• 业务操作时，避免对主键的修改

---

4.3 order by优化

MySQL的排序，有两种方式：

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

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

对于以上的两种排序方式，Using index的性能高，而Using filesort的性能低，我们在优化排序操作时，尽量要优化为 Using index。

可以通过创建联合索引做覆盖索引，实现排序优化

 create index idx_age_phone on tb_user(age,phone);

对于先按age降序排，再按phone降序排的情况，也是通过索引返回数据，倒序只是反向扫描索引

但是对于先按age升序，再按phone降序的情况，走不了索引了，这时，我们需要创建创建联合索引(age 升序排序，phone 倒序排序)

create index idx_user_age_phone_ad on tb_user(age asc ,phone desc);

再次执行sql，即使时age升序，phone降序，也会走索引

升序/降序联合索引结构 （age asc, phone asc）

先升后降序联合索引结构（age asc, phone desc）

order by优化原则:
A. 根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则。

B. 尽量使用覆盖索引。

C. 多字段排序, 一个升序一个降序，此时需要注意联合索引在创建时的规则（ASC/DESC）。

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

---

4.4 group by优化

老规矩，创建联合索引，采用覆盖索引方式，通过索引分组效率更高

分组操作中，我们需要通过以下两点进行优化，以提升性能：
A. 在分组操作时，可以通过索引来提高效率。
B. 分组操作时，索引的使用也是满足最左前缀法则的。

对于覆盖索引

首先看type，all 是扫描全表，index是扫描整个索引树，这里用到索引覆盖，所以只需扫描索引树；其次分组条件没满足最左前缀，所以用到了临时表

---

4.5 limit优化

在数据量比较大时，如果进行limit分页查询，在查询时，越往后，分页查询效率越低。

当在进行分页查询时，如果执行 limit 2000000,10 ，此时需要MySQL排序前2000010 记录，仅仅返回 2000000 - 2000010 的记录，其他记录丢弃，查询排序的代价非常大 。

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

先查出200百万后十条数据id，这个是用覆盖索引查询，速度更快
select id from tb_sku order by id limit 2000000,10
把上面查询结果看出另一张表，做两表联查

#多表查询方式
explain select * from tb_sku t , (select id from tb_sku order by id limit 2000000,10) a where t.id = a.id;

---

4.6 count优化

select count(*) from tb_user ; 

• MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(*) 的时候（后面没有where查询条件）会直接返回这个数，效率很高； 但是如果是带条件的count，MyISAM也慢。
• InnoDB 引擎就麻烦了，它执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数

如果说要大幅度提升InnoDB表的count效率，主要的优化思路：自己计数(可以借助于redis这样的数据库进行,但是如果是带条件的count又比较麻烦了)。

---

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

---

4.7 update优化

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

当我们开启多个事务，根据主键修改数据，会锁定对应修改行数据，事务提交后才会释放行锁

执行更新操作时，更新条件一定要有索引，且索引不能失效，否则，行锁就会升级为表锁，严重降低并发性能。

如下，id是主键，为聚集索引，加的是行锁

 update course set name = 'javaEE' where id = 1 ;

而name自段，并未针对它创建对应的索引，修改时会加上表锁

update course set name = 'SpringBoot' where name = 'PHP' ;

当我们开启多个事务，在执行上述的SQL时，我们发现行锁升级为了表锁。 导致该update语句的性能大大降低。
索引字段行锁，非索引字段表锁

---

感觉优化的本质就是加索引，并不是去优化sql语句

---

五.视图/存储过程/触发器

MySQL数据库的存储对象

5.1 视图

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

5.1.1 基本操作

创建视图
create or replace view stu_v_1 as select id , name from student where id <= 10;

• 查询视图
  show create view stu_v_1;
  select * from stu_v_1;
  select * from stu_v_1 where id < 3;

• 修改视图
  create or replace view stu_v_1 as select id , name , no from student where id <= 10;
  alter view stu_v_1 as select id , name from student where id <= 10;

• 删除视图
  drop view if exists stu_v_1;

---

我们在创建视图的时候，指定的条件为 id<=10, id为17的数据，是不符合条件的，所以没有查询出来，但是这条数据确实是已经成功的插入到了基表中。

如果我们定义视图时，如果指定了条件，然后我们在插入、修改、删除数据时，是否可以做到必须足条件才能操作，否则不能够操作呢？ 答案是可以的，这就需要借助于视图的检查选项了。

---

5.1.2 检查选项

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

---

1). CASCADED
级联

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

cascaded级联，向上传递
可以简记 带with cascaded check option的，本条件和上一个及其相关的都检查。如果基于另一个视图创建的视图，没有带with cascaded check option的，则不检查本条件，但上一个条件及相关父条件都检查（另一视图加了cascaded的情况）。

---

2). LOCAL
本地
比如，v2视图是基于v1视图的，如果在v2视图创建的时候指定了检查选项为 local ，但是v1视图创建时未指定检查选项。 则在执行检查时，知会检查v2，不会检查v2的关联视图v1。

向上检查，但检查不向上传递，上面视图没加检查，就不判断条件

local和cascaded区别
local是本视图加了检查选项，除判断本视图条件还会去看它所依赖的视图是否加了检查选项，依赖的视图未加检查选项，就不判断其条件。

cascaded是本视图加了检查选项，它依赖的视图即使没加检查选项也要判断条件，层层上传，最后要满足本视图条件，及其依赖视图条件及…等等。

---

5.1.3 视图更新

要使视图可更新，视图中的行与基础表中的行之间必须存在一对一的关系。如果视图包含以下任何一项，则该视图不可更新
A.聚合函数或窗口函数（SUM()、 MIN()、 MAX()、 COUNT()等）
B. DISTINCT
C. GROUP BY
D. HAVING
E. UNION 或者 UNION ALL

---

5.1.4 视图作用

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

2). 安全
数据库可以授权，但不能授权到数据库特定行和特定的列上。通过视图用户只能查询和修改他们所见到的数据
create view stu_v_count as select count(*) from student;
insert into stu_v_count values(10);

3). 数据独立
视图可帮助用户屏蔽真实表结构变化带来的影响。

---

案例
1). 为了保证数据库表的安全性，开发人员在操作tb_user表时，只能看到的用户的基本字段，屏蔽手机号和邮箱两个字段。

create view tb_user_view as select id,name,profession,age,gender,status,createtimefrom tb_user;

select * from tb_user_view;

2). 查询每个学生所选修的课程（三张表联查），这个功能在很多的业务中都有使用到，为了简化操作，定义一个视图

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 , course c 
where
s.id = sc.studentid and sc.courseid = c.id;

select * from tb_stu_course_view;

---

5.2 存储过程

存储过程是事先经过编译并存储在数据库中的一段 SQL 语句的集合，调用存储过程可以简化应用开发人员的很多工作，减少数据在数据库和应用服务器之间的传输，对于提高数据处理的效率是有好的。
存储过程思想上很简单，就是数据库 SQL 语言层面的代码封装与重用。

5.2.1 特点

• 封装，复用 -----------------------> 可以把某一业务SQL封装在存储过程中，需要用到的时候直接调用即可。

• 可以接收参数，也可以返回数据 --------> 再存储过程中，可以传递参数，也可以接收返回值。

• 减少网络交互，效率提升 -------------> 如果涉及到多条SQL，每执行一次都是一次网络传输。 而如果封装在存储过程中，我们只需要网络交互一次可能就可以了。

---

5.2.2 语法

1). 创建，参数是可选的，不是必须加

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

2). 调用

CALL 名称 ([ 参数 ]);

3). 查看

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

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

4). 删除

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

---

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

---

5.2.3 变量

在MySQL中变量分为三种类型: 系统变量、用户定义变量、局部变量。

系统变量

系统变量 是MySQL服务器提供，不是用户定义的，属于服务器层面。分为全局变量（GLOBAL）、话变量（SESSION）。
1). 查看系统变量

SHOW [ SESSION | GLOBAL ] VARIABLES ; -- 查看所有系统变量

SHOW [ SESSION | GLOBAL ] VARIABLES LIKE '......'; -- 可以通过LIKE模糊匹配方式查找变量

SELECT @@[SESSION | GLOBAL] 系统变量名; -- 查看指定变量的值

2). 设置系统变量

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

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

注意:
如果没有指定SESSION/GLOBAL，默认是SESSION，会话变量。

1. 全局变量(GLOBAL): 全局变量针对于所有的会话。
2. 会话变量(SESSION): 会话变量针对于单个会话，在另外一个会话窗口就不生效了。

---

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

1). 赋值
方式一:

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

如下

赋值时，可以使用 = ，也可以使用 :=，但建议使用:=，因为mysql的等值匹配也是=，便于区分，赋值用:=

方式二:

SELECT 字段名 INTO @var_name FROM 表名;

2). 使用

SELECT @var_name ;

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

---

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

1). 声明

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

变量类型就是数据库字段类型：INT、BIGINT、CHAR、VARCHAR、DATE、TIME等。

2). 赋值

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

演示示例:

-- 声明局部变量 - declare
-- 赋值
create procedure p2()
begin
	declare stu_count int default 0;
	select count(*) into stu_count from student;
	select stu_count;
end;

call p2();

---

5.2.4 if判断

if 用于做条件判断，在if条件判断的结构中，ELSE IF 结构可以有多个，也可以没有。 ELSE结构可以有，也可以没有。

直接上案例，看的更加清晰
根据定义的分数score变量，判定当前分数对应的分数等级。

• score >= 85分，等级为优秀。
• score >= 60分 且 score < 85分，等级为及格。
• score < 60分，等级为不及格

create procedure p3()  #创建p3存储过程
begin
	declare score int default 58;  #定义两个局部变量
	declare result varchar(10);
	
	if score >= 85 then
		set result := '优秀';
	elseif score >= 60 then
		set result := '及格';
	else
		set result := '不及格';
	end if;
	select result;  #查询最后变量结果
end;

call p3(); #调用存储过程

由上可以看到有几处不足，它得变量是写死的，因为没有传参，其次就是结果只是查询了出来，没有返回，下面会对它进行完善

---

5.2.5 参数

参数

现在改善上面案例

create procedure p3(in score int, out result varchar(10))  #直接用参数传递
begin
	if score >= 85 then
		set result := '优秀';
	elseif score >= 60 then
		set result := '及格';
	else
		set result := '不及格';
	end if;
end;

call p3(68, @result); #传入分数参数，并用自定义变量接收返回值

案例
将传入的200分制的分数，进行换算，换算成百分制，然后返回。

create procedure p5(inout score double) #score既是传入参数又是输出参数
begin
	score := score * 0.5;
end;

set @score := 120;  #自定义变量并赋值
call p5(@score);  #这里不能直接传数字，因为还要接收换算后的score,所以用自定义参数
select @score;  #查询变量最后结果

---

5.2.6 case判断

case结构及作用，和我们在基础篇中所讲解的流程控制函数很类似

案例
根据传入的月份，判定月份所属的季节（要求采用case结构）。

• 1-3月份，为第一季度
• 4-6月份，为第二季度
• 7-9月份，为第三季度
• 10-12月份，为第四季度

create procedure p6(in month int)
begin
	declare result varchar(10);
	case
	when month >= 1 and month <= 3 then
		set result := '第一季度';
	when month >= 4 and month <= 6 then
		set result := '第二季度';
	when month >= 7 and month <= 9 then
		set result := '第三季度';
	when month >= 10 and month <= 12 then
		set result := '第四季度';
	else
		set result := '非法参数';
	end case ;
	select concat('您输入的月份为: ',month, ', 所属的季度为: ',result);
end;

call p6(16);

注意：如果判定条件有多个，多个条件之间，可以使用 and 或 or 进行连接。

---

5.2.7 while，repeat，loop循环

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

上案例
计算从1累加到n的值，n为传入的参数值。

create procedure p7(in n int)
begin
	declare total int default 0;
	while n>0 do
		set total := total + n;
		set n := n - 1;
	end while;
	select total;
end;
call p7(100);

---

repeat
repeat是有条件的循环控制语句, 当满足until声明的条件的时候，则退出循环

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

仍然是这个案例
计算从1累加到n的值，n为传入的参数值。

create procedure p8(in n int)
begin
	declare total int default 0;
	repeat
		set total := total + n;
		set n := n - 1;
	until n <= 0
	end repeat;
	
	select total;
end;
call p8(10);

---

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

• LEAVE ：配合循环使用，退出循环。
• ITERATE：必须用在循环中，作用是跳过当前循环剩下的语句，直接进入下一次循环

计算从1累加到n的值，n为传入的参数值

create procedure p9(in n int)
begin
	declare total int default 0;
	sum:loop
		if n <= 0;
			leave;
		end if;
		set total := toatal + n;
		set n := n - 1 ;
	end loop sum;
	select total;
end;

call p9(10);

案例二
计算从1到n之间的偶数累加的值，n为传入的参数值。

create procedure p10(in n int)
begin
	declare total int default 0;
	sum:loop
		if n <= 0;
			leave;
		end if;
		
		if n % 2 = 1 then
			set n := n - 1;
			iterate sum;  #进入下一次循环
		end if;
		
		set total := toatal + n;
		set n := n - 1 ;
	end loop sum;
	select total;
end;

call p10(10);

---

5.2.8 游标

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

A声明游标

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

B. 打开游标

OPEN 游标名称 ;

C. 获取游标记录

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

D. 关闭游标

CLOSE 游标名称 ;

---

5.3 存储函数

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

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

characteristic说明：

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

案例
计算从1累加到n的值，n为传入的参数值。

create function fun1(n int)
returns int deterministic
begin
	declare total int default 0;
	while n>0 do
		set total := total + n;
		set n := n - 1;
	end while;
	return total;
end;

select fun1(50);

---

5.4 触发器

触发器是与表有关的数据库对象，指在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，默认为当前数据库 。

---

案例：
通过触发器记录 tb_user 表的数据变更日志，将变更日志插入到日志表user_logs中, 包含增加,修改 , 删除 ;

插入数据触发器

create trigger tb_user_insert_trigger
after insert on tb_user for each row
begin
	insert into user_logs(id, operation, operate_time, operate_id, operate_params)
	VALUES
	(null, 'insert', now(), new.id, concat('插入的数据内容为:
	id=',new.id,',name=',new.name, ', phone=', NEW.phone, ', email=', NEW.email, ',
	profession=', NEW.profession));
end;

修改数据触发器

create trigger tb_user_update_trigger
after update on tb_user for each row
begin
	insert into user_logs(id, operation, operate_time, operate_id, operate_params)
	VALUES
	(null, 'update', now(), new.id,
	concat('更新之前的数据: id=',old.id,',name=',old.name, ', phone=',
	old.phone, ', email=', old.email, ', profession=', old.profession,
	' | 更新之后的数据: id=',new.id,',name=',new.name, ', phone=',
	NEW.phone, ', email=', NEW.email, ', profession=', NEW.profession));
end;

删除数据触发器

create trigger tb_user_delete_trigger
after delete on tb_user for each row
begin
	insert into user_logs(id, operation, operate_time, operate_id, operate_params)
	VALUES
	(null, 'delete', now(), old.id,
	concat('删除之前的数据: id=',old.id,',name=',old.name, ', phone=',
	old.phone, ', email=', old.email, ', profession=', old.profession));
end;

---

六.锁

6.1 概述

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

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

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

• ---

6.2 全局锁

全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新操作的事务提交语句都将被阻塞。
其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。数据在进行逻辑备份的过程中，数据库中的数据就是不会发生变化的，这样就保证了数据的一致性和完整性。

全局锁是锁的所有数据库的表，不是当前数据库的所有表

语法
1). 加全局锁
flush tables with read lock ;

2). 数据备份 >是指定备份到哪个文件
mysqldump -uroot –p1234 itcast > itcast.sql

3). 释放锁
unlock tables ;

---

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

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

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

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

快照读的方式来备份的

---

6.3 表级锁

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

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

• 表锁
• 元数据锁（meta data lock，MDL）
• 意向锁

---

6.3.1 表锁

对于表锁，分为两类：

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

语法

加锁：lock tables 表名… read/write。

释放锁：unlock tables / 客户端断开连接 。

如下示例

读锁

左侧为客户端一，对指定表加了读锁，不会影响右侧客户端二的读，但是会阻塞右侧客户端的写。右侧的操作会一直阻塞到左侧的锁释放，才会继续进行

---

写锁

左侧为客户端一，对指定表加了写锁，会阻塞右侧客户端的读和写。右侧的操作会一直阻塞到左侧的锁释放，才会继续进行

---

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

---

6.3.2 元数据锁

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

元数据，可以简单理解为就是一张表的表结构。 也就是说，某一张表涉及到未提交的事务时，是不能够修改这张表的表结构的。

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

示例如下：

---

6.3.3 意向锁

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

分类

• 意向共享锁(IS): 由语句select … lock in share mode添加 。 与 表锁共享锁(read)兼容，与表锁排他锁(write)互斥。
• 意向排他锁(IX): 由insert、update、delete、select…for update添加 。与表锁共享锁(read)及排他锁(write)都互斥，意向锁之间不会互斥。

一旦事务提交了，意向共享锁、意向排他锁，都会自动释放。

---

测试
意向共享锁与表读锁是兼容的

---

意向排他锁与表读锁、写锁都是互斥的

---

6.4 行级锁

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

查看行锁及意向锁加锁情况的SQL

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

InnoDB的数据是基于索引组织的（因为聚集索引的叶子结点下挂的就是行数据），行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁。对于行级锁，主要分为以下三类：

• 行锁（Record Lock）：锁定单个行记录的锁，防止其他事务对此行进行update和delete。在RC（read comitted）、RR隔离级别下都支持。
  注：RC,RR是事务的隔离级别，不清楚可以跳转看一看，几秒钟就理解了，地址：http://t.csdn.cn/Z0znj
  

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

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

---

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

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

两种行锁的兼容情况如下:

---

常见的SQL语句，在执行时，所加的行锁如下：

• 针对唯一索引进行检索时，对已存在的记录进行等值匹配时，将会自动优化为行锁。
• InnoDB的行锁是针对于索引加的锁，不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，此时 就会升级为表锁。

---

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

• 索引上的等值查询(唯一索引)，给不存在的记录加锁时, 优化为间隙锁 。
• 索引上的等值查询(非唯一普通索引)，向右遍历时最后一个值不满足查询需求时，next-keylock （临键锁）退化为间隙锁。
• 索引上的范围查询(唯一索引)–会访问到不满足条件的第一个值为止

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

---

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

再对其间隙插入，会阻塞

---

②索引上的等值查询(非唯一普通索引)，向右遍历时最后一个值不满足查询需求时，next-keylock （临锁）退化为间隙锁。

由于是非唯一索引，所以可以再插入一条age=3的数据，所以为了避免出现这个，要锁住包括3在内的前后两个间隙，也是为了防止幻读

---

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

---

七.InnoDB引擎

7.1 逻辑存储结构

1). 表空间
表空间是InnoDB存储引擎逻辑结构的最高层， 如果用户启用了参数 innodb_file_per_table(在8.0版本中默认开启) ，则每张表都会有一个表空间（xxx.ibd），一个mysql实例可以对应多个表空间，用于存储记录、索引等数据。

2). 段
段，分为数据段（Leaf node segment）、索引段（Non-leaf node segment）、回滚段（Rollback segment），InnoDB是索引组织表，数据段就是B+树的叶子节点， 索引段即为B+树的非叶子节点。段用来管理多个Extent（区）。

3). 区
区，表空间的单元结构，每个区的大小为1M。 默认情况下， InnoDB存储引擎页大小为16K， 即一个区中一共有64个连续的页。

4). 页
页，是InnoDB 存储引擎磁盘管理的最小单元，每个页的大小默认为 16KB。为了保证页的连续性，InnoDB 存储引擎每次从磁盘申请 4-5 个区。

5). 行
行，InnoDB 存储引擎数据是按行进行存放的。在行中，默认有两个隐藏字段：

• Trx_id：每次对某条记录进行改动时，都会把对应的事务id赋值给trx_id隐藏列。
• Roll_pointer：每次对某条引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

---

7.2 架构

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

---

7.2.1 内存架构

1.缓存池

---

2.变更缓存区

相当于缓冲区的缓冲区，套娃

---

3.自适应hash索引

---

4.日志缓冲区

---

7.2.2 磁盘架构

// 不是我不想写文字描述，而是这个图理解起来就方便太多了

---

---

---

---

7.3 事务原理

事务 是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败。

特性

• 原子性（Atomicity）：事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
• 一致性（Consistency）：事务完成时，必须使所有的数据都保持一致状态。
• 隔离性（Isolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。
• 持久性（Durability）：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的。

而对于这四大特性，实际上分为两个部分。 其中的原子性、一致性、持久化，实际上是由InnoDB中的两份日志来保证的，一份是redo log日志，一份是undo log日志。 而持久性是通过数据库的锁，加上MVCC来保证的。

---

7.3.1 redo log

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

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

流程原理
有了redolog之后，当对缓冲区的数据进行增删改之后，会首先将操作的数据页的变化，记录在redo log buffer中。在事务提交时，会将redo log buffer中的数据刷新到redo log file磁盘文件中。

过一段时间之后，如果刷新缓冲区的脏页到磁盘时，发生错误，此时就可以借助于redo log进行数据恢复，这样就保证了事务的持久性。 而如果脏页成功刷新到磁盘 或 或者涉及到的数据已经落盘，此时redolog就没有作用了，就可以删除了，所以存在的两个redolog文件是循环写的。

就是数据备份的意思，一旦持久化出错，就用Redo Log这个备份进行持久化

致命一问

那为什么每一次提交事务，要刷新redo log 到磁盘中呢，而不是直接将buffer pool中的脏页刷新到磁盘呢 ?

因为在业务操作中，我们操作数据一般都是随机读写磁盘的，而不是顺序读写磁盘。 而redo log在往磁盘文件中写入数据，由于是日志文件，往后追加内容，所以都是顺序写的。顺序写的效率，要远大于随机写。 这种先写日志的方式，称之为 WAL（Write-Ahead Logging）。

---

7.3.2 undo log

回滚日志，用于记录数据被修改前的信息 , 作用包含两个 : 提供回滚(保证事务的原子性) 和MVCC(多版本并发控制) 。

undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录（就是数据未修改时的模样）。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。

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

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

---

7.4 MVCC

多版本并发控制

7.4.1 基本概念

1). 当前读
读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。

对于我们日常的操作，如：select … lock in share mode(共享锁)，select …，for update、update、insert、delete(排他锁)都是一种当前读。

即使是在默认的RR隔离级别下（可重复读，保证一个事务中两次读取内容相同），事务A中依然可以读取到事务B最新提交的内容，因为在查询语句后面加上了 lock in share mode 共享锁，此时是当前读操作。当然，当我们加排他锁的时候，也是当前读操作。

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

• Read Committed：每次select，都生成一个快照读。
• Repeatable Read：开启事务后第一个select语句才是快照读的地方。
• Serializable：快照读会退化为当前读。

注：在当前默认的RR隔离级别下，开启事务后第一个select语句才是快照读的地方，后面执行相同的select语句都是从快照中获取数据，可能不是当前的最新数据，这样也就保证了可重复读。

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

---

7.4.2 隐藏字段

当我们创建了上面的这张表，我们在查看表结构的时候，就可以显式的看到这三个字段。 实际上除了这三个字段以外，InnoDB还会自动的给我们添加三个隐藏字段及其含义分别是：

而上述的前两个字段是肯定会添加的， 是否添加最后一个字段DB_ROW_ID，得看当前表有没有主键，如果有主键，则不会添加该隐藏字段。

---

7.4.3 undolog

回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志。

当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。
而update、delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除。

---

有一张表原始数据为：

DB_TRX_ID : 代表最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID，是自增的。

DB_ROLL_PTR ： 由于这条数据是才插入的，没有被更新过，所以该字段值为null。

有四个并发事务同时在访问这张表。

---

7.4.4 readview

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

而在readview中就规定了版本链数据的访问规则：

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

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

这个访问规则看不懂可以结合下面图看就明白了

---

事务5第一次查询id为30的记录，套用DR_TRX_ID到右边公式，有结果就直接返回

下面是匹配过程的详细说明：
在进行匹配时，会从undo log的版本链，从上到下进行挨个匹配：

先匹配

这条记录，这条记录对应的trx_id为4，也就是将4带入右侧的匹配规则中。 ①不满足 ②不满足 ③不满足 ④也不满足 ，都不满足，则继续匹配undo log版本链的下一条。

再匹配第二条

这条记录对应的trx_id为3，也就是将3带入右侧的匹配规则中。①不满足 ②不满足 ③不满足 ④也不满足 ，都不满足，则继续匹配undo log版本链的下一条。

再匹配第三条

这条记录对应的trx_id为2，也就是将2带入右侧的匹配规则中。①不满足 ②满足 终止匹配，此次快照读，返回的数据就是版本链中记录的这条数据

---

匹配规则和上面RC一致，只是不再重新生成ReadView了，根据RR的可重复读原则直接复用。

---

总结

---

八.MySQL管理

8.1 系统数据库

创建数据库后，会有四个自带的数据库

---

8.2 常用工具

注：以分号结尾的是在MySQL下执行的语句，结尾没有符号就在linux下直接执行
mysql
该mysql不是指mysql服务，而是指mysql的客户端工具。

语法 ：
mysql [options] [database]

选项 ：

-u, --user=name #指定用户名
-p, --password[=name] #指定密码
-h, --host=name #指定服务器IP或域名
-P, --port=port #指定连接端口
-e, --execute=name #执行SQL语句并退出

-e选项可以在Mysql客户端执行SQL语句，而不用连接到MySQL数据库再执行，对于一些批处理脚本，这种方式尤其方便。

---

mysqladmin
mysqladmin 是一个执行管理操作的客户端程序。可以用它来检查服务器的配置和当前状态、创建并
删除数据库等。

通过帮助文档查看选项：

mysqladmin --help

语法:

mysqladmin [options] command ...

选项:
-u, --user=name #指定用户名
-p, --password[=name] #指定密码
-h, --host=name #指定服务器IP或域名
-P, --port=port #指定连接端口

---

mysqlbinlog
由于服务器生成的二进制日志文件以二进制格式保存，所以如果想要检查这些文本的文本格式，就会使用到mysqlbinlog 日志管理工具。(提示，主从复制用的）

语法 ：
mysqlbinlog [options] log-files1 log-files2 …

选项 ：
-d, --database=name 指定数据库名称，只列出指定的数据库相关操作。

-o, --offset=# 忽略掉日志中的前n行命令。

-r,–result-file=name 将输出的文本格式日志输出到指定文件。

-s, --short-form 显示简单格式， 省略掉一些信息。

–start-datatime=date1 --stop-datetime=date2 指定日期间隔内的所有日志。

–start-position=pos1 --stop-position=pos2 指定位置间隔内的所有日志。

---

mysqlshow
mysqlshow 客户端对象查找工具，用来很快地查找存在哪些数据库、数据库中的表、表中的列或者索引。

语法 ：
mysqlshow [options] [db_name [table_name [col_name]]]
选项 ：
--count 显示数据库及表的统计信息（数据库，表 均可以不指定）
-i 显示指定数据库或者指定表的状态信息

示例：
#查询test库中每个表中的字段书，及行数
mysqlshow -uroot -p2143 test --count
#查询test库中book表的详细情况
mysqlshow -uroot -p2143 test book --count

---

mysqldump
mysqldump 客户端工具用来备份数据库或在不同数据库之间进行数据迁移。备份内容包含创建表，及插入表的SQL语句。

语法 ：
mysqldump [options] db_name [tables]
mysqldump [options] --database/-B db1 [db2 db3...]
mysqldump [options] --all-databases/-A

连接选项 ：
-u, --user=name 指定用户名
-p, --password[=name] 指定密码
-h, --host=name 指定服务器ip或域名
-P, --port=# 指定连接端口

输出选项：
--add-drop-database 在每个数据库创建语句前加上 drop database 语句
--add-drop-table 在每个表创建语句前加上 drop table 语句 , 默认开启 ; 不开启 (--skip-add-drop-table)

-n, --no-create-db 不包含数据库的创建语句
-t, --no-create-info 不包含数据表的创建语句
-d --no-data 不包含数据
-T, --tab=name 自动生成两个文件：一个.sql文件，创建表结构的语句；一个.txt文件，数据文件

---

mysqlimport/source
1). mysqlimport
mysqlimport 是客户端数据导入工具，用来导入mysqldump 加 -T 参数后导出的文本文件。

语法 ：
mysqlimport [options] db_name textfile1 [textfile2...]
示例 ：
mysqlimport -uroot -p2143 test /tmp/city.txt

2). source
如果需要导入sql文件,可以使用mysql中的source 指令 :

语法 ：
source /root/xxxxx.sql;

---

至此，进阶篇就告一段落了，如有任何问题欢迎您反馈留言，我会完善补充，最后非常感谢你的阅览，相信您已经找到了困惑问题的答案。能帮助各位有所收获，正是该篇文章的价值所在。

---

学完回顾

进阶篇学完，呼应开头给出的问题，心中稍作对比，有些问题的答案已经呼之欲出，运维篇再续前缘