MySQL笔记

本章为学习b站“黑马程序员MySQL数据库入门到精通”所做笔记

全文目录

基础

SQL

在这里插入图片描述

DDL

来定义数据库对象(数据库,表,字段) 。

数据库操作

查询所有数据库

show databases ;

查询当前数据库

select database() ;

创建数据库

create database [ if not exists ] 数据库名 [ default charset 字符集 ] [ collate 排序
规则 ] ;

删除数据库

drop database [ if exists ] 数据库名 ;

切换数据库

use 数据库名 ;
表操作

创建表结构

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

查询当前数据库所有表

show tables;

查看指定表结构

desc 表名 ;

查询指定表的建表语句

show create table 表名 ;
表操作-数据类型

数值类型
在这里插入图片描述

字符串类型

在这里插入图片描述

日期时间类型

在这里插入图片描述

表操作-修改

添加字段

ALTER TABLE 表名 ADD 字段名 类型 (长度) [ COMMENT 1 注释 ] [ 约束 ];

修改数据类型

ALTER TABLE 表名 MODIFY 字段名 新数据类型 (长度);

修改字段名和字段类型

ALTER TABLE 表名 CHANGE 旧字段名 新字段名 类型 (长度) [ COMMENT 1 注释 ] [ 约束 ];

删除字段

ALTER TABLE 表名 DROP 字段名;

修改表名

ALTER TABLE 表名 RENAME TO 新表名;
表操作-删除

删除表

DROP TABLE [ IF EXISTS ] 表名;

删除指定表, 并重新创建表

TRUNCATE TABLE 表名;

DML

来对数据库中的表的数据记录进行增、删、改操作。

添加数据(INSERT)
修改数据(UPDATE)
删除数据(DELETE)

添加数据

给指定字段添加数据

INSERT INTO 表名 (字段名1, 字段名2, ...) VALUES (值1, 值2, ...);

给全部字段添加数据

INSERT INTO 表名 VALUES (值1, 值2, ...);

批量添加数据

INSERT INTO 表名 (字段名1, 字段名2, ...) VALUES (值1, 值2, ...), (值1, 值2, ...), (值
1, 值2, ...) ;
INSERT INTO 表名 VALUES (值1, 值2, ...), (值1, 值2, ...), (值1, 值2, ...) ;

注意事项:

• 插入数据时,指定的字段顺序需要与值的顺序是一一对应的。

• 字符串和日期型数据应该包含在引号中。
• 插入的数据大小,应该在字段的规定范围内。

修改数据
UPDATE 表名 SET 字段名1 = 值1 , 字段名2 = 值2 , .... 1 [ WHERE 条件 ] ;

注意事项:
修改语句的条件可以有,也可以没有,如果没有条件,则会修改整张表的所有数据。

删除数据
DELETE FROM 表名 [ WHERE 条件 ] ;

DQL

用来查询数据库中表的记录。查询关键字: SELECT

DQL 查询语句,语法结构如下:

SELECT
	字段列表
FROM
	表名列表
WHERE
	条件列表
GROUP BY
	分组字段列表
HAVING
	分组后条件列表
ORDER BY
	排序字段列表
LIMIT
	分页参数

将上面的完整语法进行拆分,分为以下几个部分:

基本查询(不带任何条件)
条件查询(WHERE)
聚合函数(count、max、min、avg、sum)
分组查询(group by)
排序查询(order by)
分页查询(limit)

基本查询

查询多个字段

SELECT 字段1, 字段2, 字段3 ... FROM 表名 ;
SELECT * FROM 表名 ;

* 号代表查询所有字段,在实际开发中尽量少用(不直观、影响效率)。

字段设置别名

SELECT 字段1 [ AS 别名1 ] , 字段2 [ AS 别名2 1 ] ... FROM 表名;
SELECT 字段1 [ 别名1 ] , 字段2 [ 别名2 ] ... FROM 表名;

去除重复记录

SELECT DISTINCT 字段列表 FROM 表名;
条件查询

语法:

SELECT 字段列表 FROM 表名 WHERE 条件列表 ;

常用的比较运算符如下:

在这里插入图片描述

常用的逻辑运算符如下:

在这里插入图片描述

聚合函数

将一列数据作为一个整体,进行纵向计算

常见聚合函数:

在这里插入图片描述

语法:

SELECT 聚合函数(字段列表) FROM 表名 ;

注意 : NULL值是不参与所有聚合函数运算的。

分组查询

语法:

SELECT 字段列表 FROM 表名 [ WHERE 条件 ] GROUP BY 分组字段名 [ HAVING 分组后过滤条件 ];

where与having区别
执行时机不同:where是分组之前进行过滤,不满足where条件,不参与分组;而having是分组
之后对结果进行过滤。
判断条件不同:where不能对聚合函数进行判断,而having可以。

注意事项: • 分组之后,查询的字段一般为聚合函数和分组字段,查询其他字段无任何意义。 • 执行顺序: where > 聚合函数 > having 。 • 支持多字段分组, 具体语法为 : group by columnA,columnB

排序查询

语法:

SELECT 字段列表 FROM 表名 ORDER BY 字段1 排序方式1 , 字段2 排序方式2 ;

排序方式
ASC : 升序(默认值)
DESC: 降序

注意事项: • 如果是升序, 可以不指定排序方式ASC ; • 如果是多字段排序,当第一个字段值相同时,才会根据第二个字段进行排序 ;

分页查询

语法:

SELECT 字段列表 FROM 表名 LIMIT 起始索引, 查询记录数 ;

注意事项: • 起始索引从0开始,起始索引 = (查询页码 - 1)* 每页显示记录数。 • 分页查询是数据库的方言,不同的数据库有不同的实现,MySQL中是LIMIT。 • 如果查询的是第一页数据,起始索引可以省略,直接简写为 limit 10。

执行顺序

在这里插入图片描述

DCL

用来管理数据库用户、控制数据库的访问权限

管理用户

查询用户

select * from mysql.user;

创建用户

CREATE USER '用户名'@'主机名' IDENTIFIED BY '密码';

修改用户密码

ALTER USER '用户名'@'主机名' IDENTIFIED WITH mysql_native_password BY '新密码' ;

删除用户

DROP USER '用户名'@'主机名' ;

注意事项: • 在MySQL中需要通过用户名@主机名的方式,来唯一标识一个用户。

• 主机名可以使用 % 通配,表示可以在任意主机访问该数据库。 • 这类SQL开发人员操作的比较少,主要是DBA( Database Administrator 数据库 管理员)使用。

权限控制

在这里插入图片描述

查询权限

SHOW GRANTS FOR '用户名'@'主机名' ;

授予权限

GRANT 权限列表 ON 数据库名.表名 TO '用户名'@'主机名';

撤销权限

REVOKE 权限列表 ON 数据库名.表名 FROM '用户名'@'主机名';

注意事项: • 多个权限之间,使用逗号分隔 • 授权时, 数据库名和表名可以使用 * 进行通配,代表所有。

函数

函数 是指一段可以直接被另一段程序调用的程序或代码。

字符串函数

在这里插入图片描述

数值函数

在这里插入图片描述

日期函数

在这里插入图片描述

流程函数

在这里插入图片描述

约束

概念:约束是作用于表中字段上的规则,用于限制存储在表中的数据。
目的:保证数据库中数据的正确、有效性和完整性。

在这里插入图片描述

注意:约束是作用于表中字段上的,可以在创建表/修改表的时候添加约束。

如:

alter table user modify id int NOT NULL;

外键约束

添加外键:

建表时添加:

CREATE TABLE 表名(
	字段名 数据类型,
	...
	[CONSTRAINT] [外键名称] FOREIGN KEY (外键字段名) REFERENCES 主表 (主表列名)
);

建表后添加:

ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY (外键字段名) REFERENCES 主表 (主表列名) ;

删除外键:

ALTER TABLE 表名 DROP FOREIGN KEY 外键名称;

删除/更新行为

在这里插入图片描述

语法:

ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY (外键字段) REFERENCES 主表名 (主表字段名) ON UPDATE CASCADE ON DELETE CASCADE;

多表查询

多表关系

  • 一对多(多对一)
  • 多对多
  • 一对一

一对多

案例: 部门 与 员工的关系
关系: 一个部门对应多个员工,一个员工对应一个部门
实现: 在多的一方建立外键,指向一的一方的主键

多对多

案例: 学生 与 课程的关系
关系: 一个学生可以选修多门课程,一门课程也可以供多个学生选择
实现: 建立第三张中间表,中间表至少包含两个外键,分别关联两方主键

一对一

案例: 用户 与 用户详情的关系
关系: 一对一关系,多用于单表拆分,将一张表的基础字段放在一张表中,其他详情字段放在另
一张表中,以提升操作效率
实现: 在任意一方加入外键,关联另外一方的主键,并且设置外键为唯一的(UNIQUE)

分类

  • 连接查询

    • 内连接:相当于查询A、B交集部分数据
    • 外连接:
    • 左外连接:查询左表所有数据,以及两张表交集部分数据
    • 右外连接:查询右表所有数据,以及两张表交集部分数据
    • 自连接:当前表与自身的连接查询,自连接必须使用表别名
  • 子查询

    内连接

    内连接查询的是两张表交集部分的数据。(也就是绿色部分的数据)

    在这里插入图片描述

    内连接语法分两种,隐式内连接和显示内连接

    隐式内连接:

    SELECT 字段列表 FROM 表1 , 表2 WHERE 条件 ... ;
    

    显式内连接:

    SELECT 字段列表 FROM 表1 [ INNER ] JOIN 表2 ON 连接条件 ... ;
    
    外连接

    外连接分为两种,分别是:左外连接 和 右外连接。

    在这里插入图片描述

    左外连接:

    SELECT 字段列表 FROM 表1 LEFT [ OUTER ] JOIN 1 表2 ON 条件 ... ;
    

    左外连接相当于查询表1(左表)的所有数据,当然也包含表1和表2交集部分的数据。

    右外连接:

    SELECT 字段列表 FROM 表1 RIGHT [ OUTER ] JOIN 表2 ON 条件 ... ;
    

    右外连接相当于查询表2(右表)的所有数据,当然也包含表1和表2交集部分的数据。

    左外连接和右外连接可以随时切换,当想要使用右外连接的语法显示出左外连接时,可以把需要包含的数据放在右边

    自连接:

    自己连接自己,也就是把一张表连接查询多次

    自连接查询:

    SELECT 字段列表 FROM 表A 别名A JOIN 表A 别1 名B ON 条件 ... ;
    

    联合查询:

    对于union查询,就是把多次查询的结果合并起来,形成一个新的查询结果集。

    SELECT 字段列表 FROM 表A ...
    UNION [ ALL ]
    SELECT 字段列表 FROM 表B ....;
    
    • 对于联合查询的多张表的列数必须保持一致,字段类型也需要保持一致。
    • union all 会将全部的数据直接合并在一起,union 会对合并之后的数据去重。
    子连接

    SQL语句中嵌套SELECT语句,称为嵌套查询,又称子查询。

    SELECT * FROM t1 WHERE column1 = ( SELECT column1 1 FROM t2 );
    

    子查询外部的语句可以是INSERT / UPDATE / DELETE / SELECT 的任何一个。

    根据子查询结果不同,分为:
    A. 标量子查询(子查询结果为单个值)
    B. 列子查询(子查询结果为一列)
    C. 行子查询(子查询结果为一行)
    D. 表子查询(子查询结果为多行多列)

    根据子查询位置,分为:
    A. WHERE之后
    B. FROM之后
    C. SELECT之后

    标量子查询:

    子查询返回的结果是单个值(数字、字符串、日期等),最简单的形式,这种子查询称为标量子查询。
    常用的操作符:= <> > >= < <=

    列子查询:

    子查询返回的结果是一列(可以是多行),这种子查询称为列子查询。

    常用的操作符:IN 、NOT IN 、 ANY 、SOME 、 ALL

    在这里插入图片描述

    行子查询:

    子查询返回的结果是一行(可以是多列),这种子查询称为行子查询。

    常用的操作符:= 、<> 、IN 、NOT IN

    表子查询:

    子查询返回的结果是多行多列,这种子查询称为表子查询。

    常用的操作符:

事务

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

事务操作

未控制事务

当事务出现异常报错的情况,发现数据操作前后不一致

控制事务一

查看/设置事务提交方式

SELECT @@autocommit ;
SET @@autocommit = 0 ;

提交事务

COMMIT;

回滚事务

ROLLBACK;

注意:上述的这种方式,我们是修改了事务的自动提交行为, 把默认的自动提交修改为了手动提 交, 此时我们执行的DML语句都不会提交, 需要手动的执行commit进行提交。

控制事务二

开启事务

START TRANSACTION 或 BEGIN;

提交事务

COMMIT;

回滚事务

ROLLBACK;

事务四大特性(ACID)

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

并发事务问题

脏读

一个事务读到另外一个事务还没有提交的数据。

在这里插入图片描述

不可重复读

一个事务先后读取同一条记录,但两次读取的数据不同,称之为不可重复读。

在这里插入图片描述

幻读

一个事务按照条件查询数据时,没有对应的数据行,但是在插入数据时,又发现这行数据
已经存在,好像出现了 “幻影”。

在这里插入图片描述

事务隔离级别

为了解决并发事务所引发的问题,在数据库中引入了事务隔离级别。主要有以下几种:

在这里插入图片描述

查看事务隔离级别

SELECT @@TRANSACTION_ISOLATION;

设置事务隔离级别

SET [ SESSION | GLOBAL ] TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }

SESSION 表示设置仅对当前会话有效

GLOBAL 表示设置将应用于整个服务器实例(包括所有会话)

注意:事务隔离级别越高,数据越安全,但是性能越低。

进阶

存储引擎

MySQL体系结构

在这里插入图片描述

建表时指定存储引擎

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

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

show engines;

查询建表语句 — 默认存储引擎: InnoDB

show create table account;

在这里插入图片描述

引擎特点

InnoDB

InnoDB是默认的MySQL 存储引擎。

特点:

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

文件:

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

show variables like 'innodb_file_per_table';

on为打开,如果该参数开启,代表对于InnoDB引擎的表,每一张表都对应一个ibd文件。

文件夹中查看ibd文件方式:

不能直接打开,里面都是二进制存储的。在cmd中通过 ibd2sdi 文件名.ibd方式打开查看

逻辑存储结构:

在这里插入图片描述

MyISAM

MyISAM是MySQL早期的默认存储引擎。

特点:

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

文件:

xxx.sdi:存储表结构信息,里面存放是json格式字符串,需要json解析
xxx.MYD: 存储数据
xxx.MYI: 存储索引

Memory

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

特点:

内存存放
hash索引(默认)

文件:

xxx.sdi:存储表结构信息

三者区别和特点

在这里插入图片描述

存储引擎选择

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

Linux使用MySQL

准备

首先要使主机能ping通虚拟机并且虚拟机能和主机ping通且百度也能ping通

虚拟机ping不通主机:

  1. 查看主机上VMnet8上的ip地址网段
  2. 将虚拟机的ip地址网段和网关设置为VMnet8同个网段
  3. BOOTPROTO=“static”、ONBOOT="yes"记得设置,使之不动态获取ip地址且开机生效
  4. systemctl restart network重启生效

操作

  1. 下载MySQL的Linux版本安装包,通过FinalShell上传到Linux下

  2. 解压文件

    mkdir mysql
    
    tar -xvf mysql-8.0.26-1.el7.x86_64.rpm-bundle.tar -C mysql
    
  3. 安装依赖包

    cd mysql
    
    rpm -ivh mysql-community-common-8.0.26-1.el7.x86_64.rpm 
    
    rpm -ivh mysql-community-client-plugins-8.0.26-1.el7.x86_64.rpm 
    
    rpm -ivh mysql-community-libs-8.0.26-1.el7.x86_64.rpm 
    如报错,卸载mariadb-libs,命令为:rpm -e mariadb-libs --nodeps
    
    rpm -ivh mysql-community-libs-compat-8.0.26-1.el7.x86_64.rpm
    
    yum install openssl-devel
    
    rpm -ivh  mysql-community-devel-8.0.26-1.el7.x86_64.rpm
    
    rpm -ivh mysql-community-client-8.0.26-1.el7.x86_64.rpm
    
    rpm -ivh  mysql-community-server-8.0.26-1.el7.x86_64.rpm
    
  4. 启动MySQL

    systemctl start mysqld		#启动
    systemctl restart mysqld	#重启
    systemctl stop mysqld		#停止
    
  5. 启动之后进入mysql默认密码是系统自动生成的,需要用暂时的密码进入

    grep 'temporary password' /var/log/mysqld.log
    

    登录mysq:

    mysql -u root -p
    

    然后输入上述查询到的自动生成的密码, 完成登录 .

  6. 修改root用户密码

    ALTER  USER  'root'@'localhost'  IDENTIFIED BY '1234';
    

    针对密码简单复杂度不够的情况可以设置密码的复杂度类型

    set global validate_password.policy = 0;		#设置复杂度
    set global validate_password.length = 4;		#设置密码长度
    
  7. 针对’root’@'localhost’的用户只能在当前主机使用(当前主机指的是当前虚拟机或当前客户机,不是当前主机和客户机的意思)

    所以我们要创建一个任意主机都能访问到的数据库

    create user 'root'@'%' identified with mysql_native_password BY '密码';
    
  8. 给该用户分配权限

    grant all on *.* to 'root'@'%';
    
  9. 测试在DateGrip中可不可以连接到linux的MySQL,不能的话则要确认一下Linux的防火墙有没有开放3306端口或者直接把防火墙关掉(不推荐)。

    //开启防火墙
    systemctl start firewalld
    //开放指定端口3306和8080
    firewall-cmd --zone=public --add-port=3306/tcp --permanent
    firewall-cmd --zone=public --add-port=8080/tcp --permanent
    //重启防火墙
    firewall-cmd --reload
    

    如果开放了端口之后还是不能连接,则要把DataGrip中的userSSL设置为false。即可连接

    在这里插入图片描述

索引

索引(index)是帮助MySQL高效获取数据数据结构(有序)

无索引情况:

在无索引情况下,就需要从第一行开始扫描,一直扫描到最后一行(即使这个数在中间已经找到了,也会继续进行索引),我们称之为 全表扫描,性能很低。

有索引情况:

假设索引结构就是二叉树,那么也就意味着,会对age这个字段建立一个二叉树的索引结构。

在这里插入图片描述

此时我们在进行查询时,只需要扫描三次就可以找到数据了,极大的提高的查询的效率。

备注: 这里我们只是假设索引的结构是二叉树,介绍一下索引的大概原理,只是一个示意图,并
不是索引的真实结构,索引的真实结构,后面会详细介绍。

特点:

在这里插入图片描述

索引结构

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

在这里插入图片描述

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

二叉树索引

每个节点下有两个子节点,左小右大。

假如说MySQL的索引结构采用二叉树的数据结构,比较理想的结构如下:

在这里插入图片描述

如果主键是顺序插入的,则会形成一个单向链表,结构如下:

在这里插入图片描述

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

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

所以,在MySQL的索引结构中,并没有选择二叉树或者红黑树,而选择的是B+Tree

B-Tree

B-Tree,B树是一种多叉路衡查找树,相对于二叉树,B树每个节点可以有多个分支,即多叉。

以一颗最大度数为5阶的b-tree为例,那这个B树每个节点最多存储4个key,5个指针

在这里插入图片描述

树的度数指的是一个节点的子节点个数。

我们可以通过一个数据结构可视化的网站来简单演示一下。 https://www.cs.usfca.edu/~galles/visualization/BTree.html

特点:

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

B+Tree是B-Tree的变种,我们以一颗最大度数为4阶的b+tree为例

在这里插入图片描述

我们可以看到,两部分:

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

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

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

上述我们所看到的结构是标准的B+Tree的数据结构,接下来,我们再来看看MySQL中优化之后的
B+Tree。
MySQL索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上,增加一个指向相邻叶子节点
的链表指针,就形成了带有顺序指针的B+Tree,提高区间访问的性能,利于排序。

在这里插入图片描述

Hash

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

如果两个(或多个)键值,映射到一个相同的槽位上,他们就产生了hash冲突(也称为hash碰撞),可以通过链表来解决。

特点:

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

存储引擎支持:

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

思考

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

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

索引分类

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

在这里插入图片描述

聚集索引&二级索引

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

在这里插入图片描述

聚集索引选取规则:

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

聚集索引和二级索引的具体结构如下:

在这里插入图片描述

  • 聚集索引的叶子节点下挂的是这一行的数据 。
  • 二级索引的叶子节点下挂的是该字段值对应的主键值。

当我们执行如下的SQL语句时,具体的查找过程这样的:

在这里插入图片描述

具体过程如下:
①. 由于是根据name字段进行查询,所以先根据name='Arm’到name字段的二级索引中进行匹配查
找。但是在二级索引中只能查找到 Arm 对应的主键值 10。

②. 由于查询返回的数据是*,所以此时,还需要根据主键值10,到聚集索引中查找10对应的记录,最
终找到10对应的行row。
③. 最终拿到这一行的数据,直接返回即可。

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

思考

以下两条SQL语句,那个执行效率高? 为什么?
A. select * from user where id = 10 ;
B. select * from user where name = ‘Arm’ ;
备注: id为主键,name字段创建的有索引;
解答:
A 语句的执行性能要高于B 语句。
因为A语句直接走聚集索引,直接返回数据。 而B语句需要先查询name字段的二级索引,然后再查询聚集索引,也就是需要进行回表查询。
思考题:
InnoDB主键索引的B+tree高度为多高呢?
假设:
一行数据大小为1k,一页中可以存储16行这样的数据。InnoDB的指针占用6个字节的空
间,主键即使为bigint,占用字节数为8。
高度为2:
n * 8 + (n + 1) * 6 = 161024 , 算出n约为 1170
1171
16 = 18736
也就是说,如果树的高度为2,则可以存储 18000 多条记录。
高度为3:
1171 * 1171 * 16 = 21939856
也就是说,如果树的高度为3,则可以存储 2200w 左右的记录。

索引语法

创建索引

CREATE [ UNIQUE | FULLTEXT ] INDEX index_name ON table_name (index_col_name,... );

index_name一般为idx_表名_字段名1_字段名2…

如果也有多个index_col_name,用逗号分隔开且此索引为联合索引

查看索引

SHOW INDEX FROM table_name ;

删除索引

DROP INDEX index_name ON table_name;

SQL性能分析

SQL执行频率

查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访问频次

show [session|global] status like 'Com_______';			#session 是查看当前会话,global 是查询全局数据

在这里插入图片描述

通过上述指令,我们可以查看到当前数据库到底是以查询为主,还是以增删改为主,从而为数据
库优化提供参考依据。 如果是以增删改为主,我们可以考虑不对其进行索引的优化。 如果是以
查询为主,那么就要考虑对数据库的索引进行优化了。

慢查询日志

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

查询有没有开启慢查询:

show variables like 'slow_query_log';

如果要开启慢查询日志,需要在MySQL的配置文件(/etc/my.cnf)中配置如下信息:

# 开启MySQL慢日志查询开关
slow_query_log=1

# 设置慢日志的时间为2秒,SQL语句执行时间超过2秒,就会视为慢查询,记录慢查询日志
long_query_time=2

配置完毕之后,通过以下指令重新启动MySQL服务器

systemctl restart mysqld

查看慢日志文件中记录的信息/var/lib/mysql/localhost-slow.log里会有一个主机名-slow.log的日志文件

tail -f tang11-slow.log			#实时查看该日志文件
profile详情

查看MySQL是否支持profile操作

SELECT @@have_profiling ;

开启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

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

语法:

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

Explain 执行计划中各个字段的含义:

在这里插入图片描述

性能(type)描述:

  1. system:一般访问系统表
  2. const:使用主键、唯一索引查询
  3. ref:使用非唯一性索引进行查询,可能会返回多个符合条件的记录
  4. range:这个 type 值表示连接使用了索引前缀进行范围查找,返回匹配指定范围内的记录。
  5. index:这个 type 值表示连接扫描了整个索引,而不是对其进行查找操作。这通常发生在没有满足任何其他type 条件的情况下。
  6. all:这个 type 值表示连接需要扫描整个表或者使用了不可优化的索引扫描。这是最低效的 type 值,应该尽量避免出现。

索引使用

建立了索引之后,查询性能大大提升

最左前缀法则

如果索引了多列(联合索引),要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始,并且不跳过索引中的列。如果跳跃某一列,索引将会部分失效(后面的字段索引失效)。

可以根据索引长度来判断后面的索引有没有生效

范围查询

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

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

索引失效情况
  1. 在索引列上进行运算操作。比如值等于该数据的字段截取,里面用到了字段截取的操作
  2. 不加引号。字符串类型字段使用时,不加引号,索引将失效
  3. 模糊查询。如果仅仅是尾部模糊匹配,索引不会失效,如果是头部模糊匹配,索引失效
  4. or连接条件。用or分隔开的条件,or前条件有索引,后面条件没有索引,那么所涉及的索引不会生效
  5. 数据分布影响。使用的索引比全表更慢,则不使用索引,一般为需要查询的数据超过全表一半以上
SQL提示

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

  1. use index : 建议MySQL使用哪一个索引完成此次查询(仅仅是建议,mysql内部还会再次进行评估)。

    explain select * from tb_user use index(idx_user_pro) where profession = '软件工程';
    
  2. ignore index : 忽略指定的索引。

    explain select * from tb_user ignore index(idx_user_pro) where profession = '软件工程';
    
  3. force index : 强制使用索引。

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

覆盖索引指一个查询的所有数据都可以通过索引来获取,而不必再访问表中的其他数据块。也就是说,查询所需要的列都包含在了索引里面,因此不必去访问表中的行数据。所以在查询的过程中要减少select * 的使用,通过explain查询可以看到最后面Extra的变化。

进行一个测试,查询对应字段,前几次查询会发现Extra的结果为using index,而最后一次查询结果为Using index condition。是因为在tb_user表中有一个联合索引idx_user_pro_age_sta,该索引关联三个字段:profession、age、status,而这个索引也是一个二级索引,所以叶子节点下面挂的是这一行的主键id。 所以当我们查询返回的数据在 id、profession、age、status 之中,则直接走二级索引直接返回数据了。 如果超出这个范围,就需要拿到主键id,再去扫描聚集索引,再获取额外的数据了,这个过程就是回表。 而我们如果一直使用select * 查询返回所有字段值,很容易就会造成回表查询(除非是根据主键查询,此时只会扫描聚集索引)。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

思考题:
一张表, 有四个字段(id, username, password, status), 由于数据量大, 需要对
以下SQL语句进行优化, 该如何进行才是最优方案:
select id,username,password from tb_user where username =‘itcast’;
答案: 针对于 username, password建立联合索引, sql为: create index
idx_user_name_pass on tb_user(username,password);
这样可以避免上述的SQL语句,在查询的过程中,出现回表查询。

前缀索引

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

语法:

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

前缀长度:

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

select count(distinct email) / count(*) from tb_user ;
select count(distinct substring(email,1,5)) / count(*) from tb_user ;
单列索引与联合索引

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

当索引表中既有单列索引,又有联合索引,字段查询发现系统只会默认走单列索引。走单列索引的话这就导致了会有回表查询,会增加IO负载和延迟。需要通过SQL提示,建议系统走联合索引,走联合索引则不需要回表查询。

在这里插入图片描述

索引设计原则
  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'),(3,'Jerry');

优化方案二:手动控制事务

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;

优化方案三:主键顺序插入,性能要高于乱序插入。

主键乱序插入 : 8 1 9 21 88 2 4 15 89 5 7 3
主键顺序插入 : 1 2 3 4 5 7 8 9 15 21 88 89
大批量插入数据

如果一次性需要插入大批量数据(比如: 几百万的记录),使用insert语句插入性能较低,此时可以使用MySQL数据库提供的load指令进行插入。

-- 客户端连接服务端时,需要加载本地文件 --local-infile
mysql --local-infile -u root -p

--查看有没有开启local_infile
select @@local_infile;

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

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

主键优化

数据组织方式

在InnoDB存储引擎中,表数据都是根据主键顺序组织存放的,这种存储方式的表称为索引组织表行数据,都是存储在聚集索引的叶子节点上的。

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

页分裂

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

主键插入效果

  1. 从磁盘中申请页, 主键顺序插入
  2. 第一个页没有满,继续往第一页插入
  3. 当第一个也写满之后,再写入第二个页,页与页之间会通过指针连接
  4. 当第二页写满了,再往第三页写入

主键乱序插入效果

  1. 加入1#,2#页都已经写满了
  2. 此时再插入id为50的中间页记录
  3. 按照顺序,应该存储在47之后,47所在的1#页,已经写满了,存储不了50对应的数据了。
  4. 那么此时会开辟一个新的页 3#,但是并不会直接将50存入3#页,而是会将1#页后一半的数据,移动到3#页,然后在3#页,插入50
  5. 移动数据,并插入id为50的数据之后,那么此时,这三个页之间的数据顺序是有问题的。 1#的下一个
    页,应该是3#, 3#的下一个页是2#。 所以,此时,需要重新设置链表指针。
页合并
  1. 当我们对已有数据进行删除时,当删除一行记录时,实际上记录并没有被物理删除,只是记录被标记为删除并且它的空间变得允许被其他记录声明使用
  2. 我们删除2#的数据记录,当页中删除的记录达到 MERGE_THRESHOLD(默认为页的50%),InnoDB会开始寻找最靠近的页(前或后)看看是否可以将两个页合并以优化空间使用。
  3. 删除数据,并将页合并
索引设计原理
  • 满足业务需求的情况下,尽量降低主键的长度。
  • 插入数据时,尽量选择顺序插入,选择使用AUTO_INCREMENT自增主键。
  • 尽量不要使用UUID做主键或者是其他自然主键,如身份证号。
  • 业务操作时,避免对主键的修改。

order by优化

MySQL的排序,有两种方式:
Using filesort : 通过表的索引或全表扫描,读取满足条件的数据行,然后在排序缓冲区sort buffer中完成排序操作,所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序。
Using index : 通过有序索引顺序扫描直接返回有序数据,这种情况即为 using index,不需要额外排序,操作效率高。
对于以上的两种排序方式,Using index的性能高,而Using filesort的性能低,我们在优化排序操作时,尽量要优化为 Using index。

创建索引:

create index index_name on table_name(age,phone);

常规这样创建的联合索引,默认是该字段升序或者降序才会调用到此索引。当一个字段升序一个字段降序的情况下,不会用到此索引

所以我们在优化order by性能的时候,针对联合索引不同的排序方式应该要标明

如下面这个字段是age升序,phone降序时,会用到此索引。记得在索引命名上标注,a为升序,d为降序

create index idx_user_age_phone_da on tb_user(age desc ,phone esc);

在这里插入图片描述

由上述的测试,我们得出order by优化原则:

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

group by优化

当我们没有创建索引时,系统会全表扫描

在这里插入图片描述

建立索引之后,索引扫描

在这里插入图片描述

在这里插入图片描述

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

limit优化

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

就是先用覆盖查询查到id,再用子查询多表连接。

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

count优化

select count(*) from tb_user ;

我们发现,如果数据量很大,在执行count操作时,是非常耗时的。

  • MyISAM 引擎把一个表的总行数存在了磁盘上,因此执行 count(*) 的时候会直接返回这个数,效率很高; 但是如果是带条件的count,MyISAM也慢。
  • InnoDB 引擎就麻烦了,它执行 count(*) 的时候,需要把数据一行一行地从引擎里面读出来,然后累积计数。
    如果说要大幅度提升InnoDB表的count效率,主要的优化思路:自己计数
count用法

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

用法:count(*)、count(主键)、count(字段)、count(数字)

在这里插入图片描述

按照效率排序的话,count(字段) < count(主键 id) < count(1) ≈ count(\*),所以尽量使用 count(*)

update优化

当我们在执行更新操作时候,开启事务时根据主键(一般为id)或索引指定条件的那一行数据会进行行锁锁定,提交事务时释放行锁。

但是当我们开启事务没有根据索引指定更新数据时,会发现行锁升级为表锁,导致整张表锁住其他字段也不能更新,大大减低了update的性能。

所以在更新时候,要指定索引为更新条件

视图/存储过程/触发器

视图(view)

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

语法

创建

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

查询

1.查看创建视图语句:SHOW CREATE VIEW 视图名称;
2.查看视图数据: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会通过视图检查正在更改的每个行,例如 插入,更新,删除,以使其符合视图的定义。 MySQL允许基于另一个视图创建视图,它还会检查依赖视图中的规则以保持一致性。为了确定检查的范围,mysql提供了两个选项: CASCADED 和 LOCAL,默认值为 CASCADED 。

  • CASCADED级联。

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

    在这里插入图片描述

  • Local 本地。

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

    在这里插入图片描述

视图的更新

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

A. 聚合函数或窗口函数(SUM()、 MIN()、 MAX()、 COUNT()等)
B. DISTINCT
C. GROUP BY
D. HAVING
E. UNION 或者 UNION ALL

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

存储过程(procedure)

对数据库 SQL 语言层面的代码封装与复用

特点:

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

创建:

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

调用:

CALL 名称 ([ 参数 ]);

查看:

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

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

删除:

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

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

变量

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

系统变量

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

查看系统变量:

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

设置系统变量:

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

注意: 如果没有指定SESSION/GLOBAL,默认是SESSION,会话变量。 A. 全局变量(GLOBAL): 全局变量针对于所有的会话。 B. 会话变量(SESSION): 会话变量针对于单个会话,在另外一个会话窗口就不生效了。

mysql服务重新启动之后,所设置的全局参数会失效,要想不失效,1 可以在 /etc/my.cnf 中配置。

用户自定义变量

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

一个@代表用户自定义变量,两个@代表系统变量

赋值:

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、BIGINT、CHAR、VARCHAR、DATE、TIME等。

赋值:

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

if 用于做条件判断,具体的语法结构为:

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

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

参数

参数的类型,主要分为以下三种:IN、OUT、INOUT。 具体的含义如下:

在这里插入图片描述

用法:

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

在使用call调用的时候,如果是有in也有out的情况,in为传进去的参数,out为用户自定义参数。如果是inout的情况,在调用时候需要使用set自定义参数,然后再传进去

case

case结构及作用,和在基础篇中的流程控制函数很类似。有两种语法格式:

语法1:

-- 含义: 当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;

语法2:

-- 含义: 当条件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

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

-- 先判定条件,如果条件为true,则执行逻辑,否则,不执行逻辑
WHILE 条件 DO
	SQL逻辑...
END WHILE;
repeat

repeat是有条件的循环控制语句, 当满足until声明的条件的时候,则退出循环 。具体语法为:

-- 先执行一次逻辑,然后判定UNTIL条件是否满足,如果满足,则退出。如果不满足,则继续下一次循环
REPEAT
	SQL逻辑...
	UNTIL 条件
END REPEAT;
loop

loop 实现简单的循环,如果不在SQL逻辑中增加退出循环的条件,可以用其来实现简单的死循环。
loop 可以配合以下两个语句使用:
leave:配合循环使用,退出循环。
iterate:必须用在循环中,作用是跳过当前循环剩下的语句,直接进入下一次循环。

[begin_label:] LOOP
	SQL逻辑...
END LOOP [end_label];
LEAVE label; -- 退出指定标记的循环体
ITERATE label; -- 直接进入下一次循环

上述语法中出现的 begin_label,end_label,label 指的都是我们所自定义的标记。

游标

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

声明游标:

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

打开游标:

OPEN 游标名称 ;

获取游标记录:

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

关闭游标:

CLOSE 游标名称 ;
条件处理程序

上述调用的过程中,会报错,之所以报错是因为上面的while循环中,并没有退出条件。当游标的数据集获取完毕之后,再次获取数据,就会报错,从而终止了程序的执行。

条件处理程序(Handler)可以用来定义在流程控制结构执行过程中遇到问题时相应的处理步骤。具体
语法为:

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

handler_action 的取值:
CONTINUE: 继续执行当前程序
EXIT: 终止执行当前程序
condition_value 的取值:
SQLSTATE sqlstate_value: 状态码,如 02000
SQLWARNING: 所有以01开头的SQLSTATE代码的简写
NOT FOUND: 所有以02开头的SQLSTATE代码的简写
SQLEXCEPTION: 所有没有被SQLWARNING 或 NOT FOUND捕获的SQLSTATE代码的简写

如:

declare exit handler for not found close user_cur;

存储函数(function)

存储函数是有返回值的存储过程,存储函数的参数只能是IN类型的。具体语法如下:

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

characteristic说明:

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

触发器(trigger)

触发器是与表有关的数据库对象,指在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中, 包含增加,修改 , 删除 ;

表结构准备:

-- 准备工作 : 日志表 user_logs
create table user_logs(
	id int(11) not null auto_increment,
	operation varchar(20) not null comment '操作类型, insert/update/delete',
	operate_time datetime not null comment '操作时间',
	operate_id int(11) not null comment '操作的ID',
	operate_params varchar(500) comment '操作参数',
	primary key(`id`)
)engine=innodb default charset=utf8;

插入数据触发器:

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;

测试:

-- 查看
show triggers ;
-- 插入数据到tb_user
insert into tb_user(id, name, phone, email, profession, age, gender, status,
createtime) VALUES (26,'三皇子','18809091212','erhuangzi@163.com','软件工
程',23,'1','1',now());

MySQL中的锁,按照锁的粒度分,分为以下三类:

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

全局锁

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

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

加了全局锁后的情况:

在这里插入图片描述

语法

加全局锁:

flush tables with read lock ;

数据备份(这个不是sql语言,无需再mysql命令行中使用):

备份本机的数据库:

mysqldump -u用户 –p密码 数据库名 > 路径

备份非本机数据库:

mysqldump -h主机ip地址 -u用户 –p密码 数据库名 > 路径

释放锁:

unlock tables ;
特点

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

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

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

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

表级锁

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

对于表级锁,主要分为以下三类:

  • 表锁
  • 元数据锁(meta data lock,MDL)
  • 意向锁
表锁

对于表锁,分为两类:

  • 表共享读锁(read lock)
  • 表独占写锁(write lock)
语法

加锁

lock tables 表名 read/write

释放锁

unlock tables / 客户端断开连接
元数据锁

元数据锁,简写MDL。

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

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

常见的SQL操作时,所添加的元数据锁:

在这里插入图片描述

查看数据库中元数据锁的情况:

select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks ;
意向锁
介绍

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

假如没有意向锁,客户端一对表加了行锁后,客户端二如何给表加表锁呢?

  • 首先客户端一,开启一个事务,然后执行DML操作,在执行DML语句时,会对涉及到的行加行锁。

  • 当客户端二,想对这张表加表锁时,会检查当前表是否有对应的行锁,如果没有,则添加表锁,此时就
    会从第一行数据,检查到最后一行数据,效率较低。

有了意向锁之后 :

客户端一,在执行DML操作时,会对涉及的行加行锁,同时也会对该表加上意向锁。

而其他客户端,在对这张表加表锁的时候,会根据该表上所加的意向锁来判定是否可以成功加表锁,而不用逐行判断行锁情况了。

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

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

可以通过以下SQL,查看意向锁及行锁的加锁情况:

select object_schema,object_name,index_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实现了以下两种类型的行锁:

  • 共享锁(S):允许一个事务去读一行,阻止其他事务获得相同数据集的排它锁。

  • 排他锁(X):允许获取排他锁的事务更新数据,阻止其他事务获得相同数据集的共享锁和排他锁。

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

在这里插入图片描述

常见的SQL语句,在执行时,所加的行锁如下:

在这里插入图片描述

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

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

可以通过以下SQL,查看意向锁及行锁的加锁情况:

select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_locks;
间隙锁&临键锁

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

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

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

InnoDB引擎(了解)

逻辑存储结构

InnoDB的逻辑存储结构如下图所示:

在这里插入图片描述

  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日志中,然后这个隐藏列就相当于一个指针,可以通过它来找到该记录修改前的信息。

架构

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

在这里插入图片描述

内存结构

在这里插入图片描述

Buffer Pool

InnoDB存储引擎基于磁盘文件存储,访问物理硬盘和在内存中进行访问,速度相差很大,为了尽可能弥补这两者之间的I/O效率的差值,就需要把经常使用的数据加载到缓冲池中,避免每次访问都进行磁盘I/O。
在InnoDB的缓冲池中不仅缓存了索引页和数据页,还包含了undo页、插入缓存、自适应哈希索引以及
InnoDB的锁信息等等。

缓冲池 Buffer Pool,是主内存中的一个区域,里面可以缓存磁盘上经常操作的真实数据,在执行增删改查操作时,先操作缓冲池中的数据(若缓冲池没有数据,则从磁盘加载并缓存),然后再以一定频率刷新到磁盘,从而减少磁盘IO,加快处理速度。

缓冲池以Page页为单位,底层采用链表数据结构管理Page。根据状态,将Page分为三种类型:
• free page:空闲page,未被使用。
• clean page:被使用page,数据没有被修改过。
• dirty page:脏页,被使用page,数据被修改过,也中数据与磁盘的数据产生了不一致。

Change Buffer

Change Buffer,更改缓冲区(针对于非唯一二级索引页),在执行DML语句时,如果这些数据Page没有在Buffer Pool中,不会直接操作磁盘,而会将数据变更存在更改缓冲区 Change Buffer中,在未来数据被读取时,再将数据合并恢复到Buffer Pool中,再将合并后的数据刷新到磁盘中。

Change Buffer的意义是什么呢?先来看一幅图,这个是二级索引的结构图:

在这里插入图片描述

与聚集索引不同,二级索引通常是非唯一的,并且以相对随机的顺序插入二级索引。同样,删除和更新可能会影响索引树中不相邻的二级索引页,如果每一次都操作磁盘,会造成大量的磁盘IO。有了ChangeBuffer之后,我们可以在缓冲池中进行合并处理,减少磁盘IO。

Adaptive Hash Index

适应hash索引,用于优化对Buffer Pool数据的查询。MySQL的innoDB引擎中虽然没有直接支持hash索引,但是给我们提供了一个功能就是这个自适应hash索引。因为前面我们讲到过,hash索引在进行等值匹配时,一般性能是要高于B+树的,因为hash索引一般只需要一次IO即可,而B+树,可能需要几次匹配,所以hash索引的效率要高,但是hash索引又不适合做范围查询、模糊匹配等。
InnoDB存储引擎会监控对表上各索引页的查询,如果观察到在特定的条件下hash索引可以提升速度,则建立hash索引,称之为自适应hash索引。
自适应哈希索引,无需人工干预,是系统根据情况自动完成。
参数: adaptive_hash_index

Log Buffer

Log Buffer:日志缓冲区,用来保存要写入到磁盘中的log日志数据(redo log 、undo log),默认大小为 16MB,日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事务,增加日志缓冲区的大小可以节省磁盘 I/O。

参数:
innodb_log_buffer_size:缓冲区大小
innodb_flush_log_at_trx_commit:日志刷新到磁盘时机,取值主要包含以下三个:
1: 日志在每次事务提交时写入并刷新到磁盘,默认值。
0: 每秒将日志写入并刷新到磁盘一次。

​ 2: 日志在每次事务提交后写入,并每秒刷新到磁盘一次。

磁盘结构

在这里插入图片描述

System Tablespace

系统表空间是更改缓冲区的存储区域。如果表是在系统表空间而不是每个表文件或通用表空间中创建的,它也可能包含表和索引数据。(在MySQL5.x版本中还包含InnoDB数据字典、undolog等)
参数:innodb_data_file_path

系统表空间,默认的文件名叫 ibdata1。

File-Per-Table Tablespaces

如果开启了innodb_file_per_table开关 ,则每个表的文件表空间包含单个InnoDB表的数据和索引 ,并存储在文件系统上的单个数据文件中。
开关参数:innodb_file_per_table ,该参数默认开启。

General Tablespaces

通用表空间,需要通过 CREATE TABLESPACE 语法创建通用表空间,在创建表时,可以指定该表空间。

创建表空间:

CREATE TABLESPACE ts_name ADD DATAFILE 'file_name' ENGINE = engine_name;

创建表时指定表空间:

CREATE TABLE xxx ... TABLESPACE ts_name;

Undo Tablespaces

撤销表空间,MySQL实例在初始化时会自动创建两个默认的undo表空间(初始大小16M),用于存储
undo log日志。

Temporary Tablespaces

InnoDB 使用会话临时表空间和全局临时表空间。存储用户创建的临时表等数据。

Doublewrite Buffer Files

双写缓冲区,innoDB引擎将数据页从Buffer Pool刷新到磁盘前,先将数据页写入双写缓冲区文件中,便于系统异常时恢复数据。

Redo Log

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

以循环方式写入重做日志文件,涉及两个文件:ib_logfile0、ib_logfile1

事务原理

事务基础

事务

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

特性

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

那实际上,我们研究事务的原理,就是研究MySQL的InnoDB引擎是如何保证事务的这四大特性的。

在这里插入图片描述

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

在这里插入图片描述

我们在讲解事务原理的时候,主要就是来研究一下redolog,undolog以及MVCC。

redo log

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

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

如果没有redolog,可能会存在什么问题的? 我们一起来分析一下。

我们知道,在InnoDB引擎中的内存结构中,主要的内存区域就是缓冲池,在缓冲池中缓存了很多的数据页。 当我们在一个事务中,执行多个增删改的操作时,InnoDB引擎会先操作缓冲池中的数据,如果缓冲区没有对应的数据,会通过后台线程将磁盘中的数据加载出来,存放在缓冲区中,然后将缓冲池中的数据修改,修改后的数据页我们称为脏页。 而脏页则会在一定的时机,通过后台线程刷新到磁盘中,从而保证缓冲区与磁盘的数据一致。 而缓冲区的脏页数据并不是实时刷新的,而是一段时间之后将缓冲区的数据刷新到磁盘中,假如刷新到磁盘的过程出错了,而提示给用户事务提交成功,而数据却没有持久化下来,这就出现问题了,没有保证事务的持久性。

在这里插入图片描述

那么,如何解决上述的问题呢? 在InnoDB中提供了一份日志 redo log,接下来我们再来分析一下,通过redolog如何解决这个问题。

在这里插入图片描述

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

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

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

undo log

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

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

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

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

MVCC

基本概念

当前读

读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。对于我们日常的操作,如:select … lock in share mode(共享锁),select …for update、update、insert、delete(排他锁)都是一种当前读。

快照读

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

MVCC

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

隐藏字段

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

在这里插入图片描述

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

查看ibd表结构及其其中的字段信息:

ibd2sdi xxxx.ibd

undolog

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

当insert的时候,产生的undo log日志只在回滚时需要,在事务提交后,可被立即删除。

而update、delete的时候,产生的undo log日志不仅在回滚时需要,在快照读时也需要,不会立即被删除。

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

readview

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

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

在这里插入图片描述

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

trx_id 代表当前undolog版本链对应事务ID。

在这里插入图片描述

不同的隔离级别,生成ReadView的时机不同:

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

原理分析

RC隔离级别

RR隔离级别

系统数据库

Mysql数据库安装完成后,自带了一下四个数据库,具体作用如下:

在这里插入图片描述

常用工具

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

mysqlimport

mysqlimport 是客户端数据导入工具,用来导入mysqldump 加 -T 参数后导出的文本文件。

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

source

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

语法 :
	source /root/xxxxx.sql
  • 8
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值