1、Linux下MySQL的安装与使用

1.1、安装前说明

克隆虚拟机主要修改一下几点
MAC地址
主机名
1
vim /etc/hostname
IP地址
1
vim /etc/sysconfig/network-scripts/ifcfg-ens33
UUID
1
vim /etc/sysconfig/network-scripts/ifcfg-ens33

1.1.1、查看是否安装过MySQL

如果你是用rpm安装, 检查一下RPM PACKAGE：
1
2
# -i 忽略大小写 rpm -qa | grep -i mysql
检查mysql service：
1
systemctl status mysqld.service

1.1.2、MySQL的卸载

关闭mysql服务
1
systemctl stop mysqld.service

查看当前mysql安装状况

1
2
3

rpm -qa | grep -i mysql
# 或
yum list installed | grep mysql

卸载上述命令查询出的已安装程序
1
yum remove mysql-xxx mysql-xxx mysql-xxx mysql-xxxx
务必卸载干净，反复执行rpm -qa | grep -i mysql确认是否有卸载残留
删除mysql相关文件
- 查找相关文件
1
find / -name mysql
- 删除上述命令查找出的相关文件
1
rm -rf xxx
删除 my.cnf
1
rm -rf /etc/my.cnf

1.2、MySQL的Linux版安装

1.2.1、MySQL的四大版本

MySQL Community Server社区版本，开源免费，自由下载，但不提供官方技术支持，适用于大多数普通
用户。

MySQL Enterprise Edition企业版本，需付费，不能在线下载，可以试用30天。提供了更多的功能和更完
备的技术支持，更适合于对数据库的功能和可靠性要求较高的企业客户。

MySQL Cluster集群版，开源免费。用于架设集群服务器，可将几个MySQL Server封装成一个Server。需
要在社区版或企业版的基础上使用。

MySQL Cluster CGE高级集群版，需付费。

1.2.2、MySQL下载

下面是5.7与8.0两个版本

MySQL版本命名说明

mysql-8.0.29-1.el7.x86_64.rpm-bundle.tar

下载完成之后解压，上传标记六个的rpm
- mysql-community-client-8.0.29-1.el7.x86_64.rpm
- mysql-community-client-plugins-8.0.29-1.el7.x86_64.rpm
- mysql-community-common-8.0.29-1.el7.x86_64.rpm
- mysql-community-debuginfo-8.0.29-1.el7.x86_64.rpm
- mysql-community-devel-8.0.29-1.el7.x86_64.rpm
- mysql-community-embedded-compat-8.0.29-1.el7.x86_64.rpm
- mysql-community-icu-data-files-8.0.29-1.el7.x86_64.rpm
- mysql-community-libs-8.0.29-1.el7.x86_64.rpm
- mysql-community-libs-compat-8.0.29-1.el7.x86_64.rpm
- mysql-community-server-8.0.29-1.el7.x86_64.rpm
- mysql-community-server-debug-8.0.29-1.el7.x86_64.rpm
- mysql-community-test-8.0.29-1.el7.x86_64.rpm
mysql-5.7.38-1.el7.x86_64.rpm-bundle.tar

下载完成之后解压，上传标记四个的rpm
- mysql-community-client-5.7.38-1.el7.x86_64.rpm
- mysql-community-common-5.7.38-1.el7.x86_64.rpm
- mysql-community-devel-5.7.38-1.el7.x86_64.rpm
- mysql-community-embedded-5.7.38-1.el7.x86_64.rpm
- mysql-community-embedded-compat-5.7.38-1.el7.x86_64.rpm
- mysql-community-embedded-devel-5.7.38-1.el7.x86_64.rpm
- mysql-community-libs-5.7.38-1.el7.x86_64.rpm
- mysql-community-libs-compat-5.7.38-1.el7.x86_64.rpm
- mysql-community-server-5.7.38-1.el7.x86_64.rpm
- mysql-community-test-5.7.38-1.el7.x86_64.rpm

1.2.3、CentOS7下检查MySQL依赖

检查/tmp临时目录权限（必不可少）

由于mysql安装过程中，会通过mysql用户在/tmp目录下新建tmp_db文件，所以请给/tmp较大的权限。执行：
1
chmod -R 777 /tmp

安装前，检查依赖

rpm -qa|grep libaio
rpm -qa|grep net-tools
# 不存在执行以下命令
yum -y install libaio
yum -y install net-tools

1.2.4、CentOS7下MySQL安装过程

将安装程序拷贝到/opt目录下

在mysql的安装文件目录下执行：（必须按照顺序执行）

rpm -ivh mysql-community-common-8.0.29-1.el7.x86_64.rpm
rpm -ivh mysql-community-client-plugins-8.0.29-1.el7.x86_64.rpm
rpm -ivh mysql-community-libs-8.0.29-1.el7.x86_64.rpm
rpm -ivh mysql-community-client-8.0.29-1.el7.x86_64.rpm 
rpm -ivh mysql-community-icu-data-files-8.0.29-1.el7.x86_64.rpm
rpm -ivh mysql-community-server-8.0.29-1.el7.x86_64.rpm

rpm是Redhat Package Manage缩写，通过RPM的管理，用户可以把源代码包装成以rpm为扩展名的文件形式，易于安装。
-i, –install 安装软件包
-v, –verbose 提供更多的详细信息输出
-h, –hash 软件包安装的时候列出哈希标记 (和 -v 一起使用效果更好)，展示进度条

若存在mariadb-libs问题，则执行yum -y remove mysql-libs即可(mysql-community-libs-8.0.29-1.el7.x86_64.rpm会出现)

1.2.5、查看MySQL版本

1
2
3

mysql --version 
#或
mysqladmin --version

1.2.6、服务的初始化

为了保证数据库目录与文件的所有者为 mysql 登录用户，如果你是以 root 身份运行 mysql 服务，需要执行下面的命令初始化：

1	`mysqld --initialize --user=mysql`

说明：--initialize选项默认以“安全”模式来初始化，则会为 root 用户生成一个密码并将该密码标记为过期，登录后你需要设置一个新的密码。生成的临时密码会往日志中记录一份。

查看密码：

1	`cat /var/log/mysqld.log`

root@localhost: 后面就是初始化的密码

1.2.7、启动MySQL，查看状态

# 加不加.service后缀都可以 
启动：systemctl start mysqld.service 
关闭：systemctl stop mysqld.service 
重启：systemctl restart mysqld.service 
查看状态：systemctl status mysqld.service

1.2.8、查看MySQL服务是否自启动

1	`systemctl list-unit-files\|grep mysqld.service`

如不是enabled可以运行如下命令设置自启动
1
systemctl enable mysqld.service
如果希望不进行自启动，运行如下命令设置
1
systemctl disable mysqld.service

1.3、MySQL登录

1.3.1、首次登录

通过mysql -hlocalhost -P3306 -uroot -p进行登录，在Enter password：录入初始化密码

1.3.2、修改密码

1	`ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';`

1.3.3、设置远程登录

确认网络
1. 在远程机器上使用ping ip地址保证网络畅通
2. 在远程机器上使用telnet命令保证端口号开放访问

关闭防火墙或开放端口

方式一：关闭防火墙

CentOS7

# 开启防火墙
systemctl start firewalld.service
# 查看防火墙状态
systemctl status firewalld.service
# 关闭防火墙
systemctl stop firewalld.service
# 设置开机启用防火墙 
systemctl enable firewalld.service 
# 设置开机禁用防火墙 
systemctl disable firewalld.service

方式二：开放端口

查看开放的端口号
1
firewall-cmd --list-all

设置开放的端口号

1 2	`firewall-cmd --add-service=http --permanent firewall-cmd --add-port=3306/tcp --permanent`

重启防火墙
1
firewall-cmd --reload

1.4、Linux下修改配置

修改允许远程登陆
1
2
3
4
use mysql; select Host,User from user; update user set host = '%' where user ='root'; flush privileges;
%是个通配符，如果Host=192.168.180.1%，那么就表示只要是IP地址前缀为“192.168.180.1”的客户端都可以连接。如果Host=%，表示所有IP都有连接权限。

注意：在生产环境下不能为了省事将host设置为%，这样做会存在安全问题，具体的设置可以根据生产环境的IP进行设置。

配置新连接报错：错误号码 2058，分析是 mysql 密码加密方法变了。

解决方法一：升级远程连接工具版本

解决方法二：

1	`ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'root';`

1.5、字符集的相关操作

在MySQL8.0版本之前，默认字符集为latin1,utf8字符集指向的是utf8mb3。网站开发人员在数据库设计的时
候往往会将编码修改为utf8字符集。如果遗忘修改默认的编码，就会出现乱码的问题。从MySQL8.0开始，数据库
的默认编码将改为utfmbb4，从而避免上述乱码的问题。

1.5.1、各级别的字符集

1	`show variables like 'character%';`

+--------------------------+--------------------------------+
| Variable_name            | Value                          |
+--------------------------+--------------------------------+
| character_set_client     | utf8mb4                        |
| character_set_connection | utf8mb4                        |
| character_set_database   | utf8mb4                        |
| character_set_filesystem | binary                         |
| character_set_results    | utf8mb4                        |
| character_set_server     | utf8mb4                        |
| character_set_system     | utf8mb3                        |
| character_sets_dir       | /usr/share/mysql-8.0/charsets/ |
+--------------------------+--------------------------------+

character_set_server：服务器级别的字符集
character_set_database：当前数据库的字符集
character_set_client：服务器解码请求时使用的字符集
character_set_connection：服务器处理请求时会把请求字符串从character_set_client转为character_set_connection
character_set_results：服务器向客户端返回数据时使用的字符集

修改已有数据库/表字符集

# 修改已有数据库字符集
alter database dbtest1 character set utf8mb4;
# 修改已有表字符集
alter table t_tmp1 convert to character set utf8mb4;
# 查看已有数据库字符集
show create table dbtest1;
# 查看已有表字符集
show create table t_tmp1;

字符集小结

如果创建或修改列时没有显式的指定字符集和比较规则，则该列默认用表的字符集和比较规则
如果创建表时没有显式的指定字符集和比较规则，则该表默认用数据库的字符集和比较规则
如果创建数据库时没有显式的指定字符集和比较规则，则该数据库默认用服务器的字符集和比较规则

1.5.2、字符集与比较规则

1.5.2.1、utf8与utf8mb4

utf8字符集表示一个字符需要使用1~ 4个字节，但是我们常用的一些字符使用1~ 3个字节就可以表示了。而字
符集表示一个字符所用的最大字节长度，在某些方面会影响系统的存储和性能，所以设计MySQL的设计者偷偷的
定义了两个概念：

utf8mb3：阉割过的utf8字符集，只使用1~3个字节表示字符。
utf8mb4：正宗的utf8字符集，使用1~ 4个字节表示字符。

在MySQL中utf8是utf8mb3的别名，所以之后在MySQL中提到utf8就意味着使用1~3个字节来表示一个字符。
如果大家有使用4字节编码一个字符的情况，比如存储一些emoji表情，那请使用utf8mb4。
此外，通过如下指令可以查看MySQL支持的字符集：

1
2
3

SHOW charset;
-- 或者
SHOW CHARACTER SET;

1.5.2.2、比较规则

上表中，MySQL版本一共支持41种字符集，其中的Default collation列表示这种字符集中一种默认的比较规则，里面包含着该比较规则主要作用于哪种语言，比如utf8_polish_ci表示以波兰语的规则比较，utf8_spanish_ci 是以西班牙语的规则比较，utf8_general_ci是一种通用的比较规则。

后缀表示该比较规则是否区分语言中的重音、大小写。具体如下：

后缀	英文释义	描述
`_ai`	`accent insensitive`	不区分重音
`_as`	`accent sensitive`	区分重音
`_ci`	`case insensitive`	不区分大小写
`_cs`	`case sensitive`	区分大小写
`_bin`	`binary`	以二进制方式比较

最后一列Maxlen,它代表该种字符集表示一个字符最多需要几个字节。

这里把常见的字符集和对应的Maxlen显式如下：

字符集名称	Maxlen
`ascii`	`1`
`latin1`	`1`
`gb2312`	`2`
`gbk`	`2`
`utf8`	`3`
`utf8mb4`	`4`

常用操作之字符集：

# 查看GBK字符集的比较规则
SHOW COLLATION LIKE 'gbk%';
# 查看UTF-8字符集的比较规则
SHOW COLLATION LIKE 'utf8%';

常见操作之数据库：

# 查看服务器的字符集和比较规则
SHOW VARIABLES LIKE '%_server';
# 查看数据库的字符集和比较规则
SHOW VARIABLES LIKE '%_database';
# 查看具体数据库的字符集
SHOW CREATE DATABASE dbtest1;
# 修改具体数据库的字符集
ALTER DATABASE dbtest1 DEFAULT CHARACTER SET utf8 COLLATE 'utf8_general_ci';

说明1：

utf8_unicode_ci和utf8_general_ci对中、英文来说没有实质的差别。

utf8_general_ci校对速度快，但准确度稍差。

utf8_unicode_ci准确度高，但校对速度稍慢。

一般情况，用utf8_general_ci就够了，但如果你的应用有德语、法语或者俄语，请一定使用utf8_unicode_ci。
说明2：

修改了数据库的默认字符集和比较规则后，原来已经创建的表格的字符集和比较规则并不会改变，如果需要，那么需单独修改。

常用操作之表：

# 查看表的字符集
show create table t_table;
# 查看表的比较规则
show table status from test_db like 't_table';
# 修改表的字符集和比较规则
ALTER TABLE t_table DEFAULT CHARACTER SET utf8mb4 COLLATE 'utf8mb4_general_ci';

1.5.3、请求到响应过程中字符集的变化

我们知道从客户端发往服务器的请求本质上就是一个字符串，服务器向客户端返回的结果本质上也是一个字符
串，而字符串其实是使用某种字符集编码的二进制数据。这个字符串可不是使用一种字符集的编码方式一条道走
到黑的，从发送请求到返回结果这个过程中伴随着多次字符集的转换，在这个过程中会用到3个系统变量，我们先
把它们写出来看一下：

系统变量	描述
`character_set_client`	服务器解码请求时使用的字符集
`character_set_connection`	服务器处理请求时会把请求字符串从`character_set_client`转为`character_set_connection`
`character_set_results`	服务器向客户端返回数据时使用的字符集

graph TB
A(客户端) --> |"使用操作系统的字符集编码请求字符串"| B(从character_set_client转换为character_set_connection)
B --> C(从character_set_connection转换为具体的列使用的字符集)
C --> D(将查询结果从具体的列上使用的字符集转换为character_set_results)
D --> |"使用操作系统的字符集解码响应的字符串"| A

1.6、SQL大小写规范问题

1.6.1、Linux和Windows平台的区别

在SQL中，关键字和函数名是不用区分字母大小写的，比如SELECT、WHERE、ORDER、GROUP BY等关键字，以及ABS、MOD、ROUND、MAX等函数名。

不过在SQL中，你还是要确定大小写的规范，因为在Liux和Windows环境下，你可能会遇到不同的大小写问题。windows系统默认大小写不敏感，但是linux系统是大小写敏感的。

通过如下命令查看：

1	`SHOW VARIABLES LIKE '%lower_case_table_names%';`

+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| lower_case_table_names | 0     |
+------------------------+-------+

lower_case_table_names参数值的设置：
- 默认为0，大小写敏感。
- 设置1，大小写不敏感。创建的表，数据库都是以小写形式存放在磁盘上，对于sq语句都是转换为小写对表和数据库进行查找。
- 设置2，创建的表和数据库依据语句上格式存放，凡是查找都是转换为小写进行。
两个平台上SQL大小写的区别具体来说：
MySQL在Liux下数据库名、表名、列名、别名大小写规则是这样的：
1. 数据库名、表名、表的别名、变量名是严格区分大小写的：
2. 关键字、函数名称在SQL中不区分大小写，
3. 列名（或字段名）与列的别名（或字段别名）在所有的情况下均是忽略大小写的
MySQL在Windows的环境下全部不区分大小写

1.6.2、Linux下大小写规则设置

当想设置为大小写不敏感时，要在my.cnf这个配置文件[mysqld]中加入lower_case_table_names=1,然后重启服务器。

但是要在重启数据库实例之前就需要将原来的数据库和表转换为小写，否则将找不到数据库名。
此参数适用于MySQL5.7。在MySQL8下禁止在重新启动MySQL服务时将lower_case_table_names设置成不同于初始化MySQL服务时设置的lower_case_table_names值。如果非要将MySQL8设置为大小写不敏感，具体步骤为：
1. 停止MySQL服务
2. 删除数据目录，即删除/var/1ib/mysq1目录(数据库文件)
3. 在MySQL配置文件(/etc/my.cnf)中添加lower_case_table_names=1
4. 启动MySQL服务

注意：在进行数据库参数设置之前，需要掌握这个参数带来的影响，切不可盲目设置。

1.6.3、SQL编写建议

如果你的变量名命名规范没有统一，就可能产生错误。这里有一个有关命名规范的建议：

关键字和函数名称全部大写；

数据库名、表名、表别名、字段名、字段别名等全部小写；

SQL语必须以分号结尾。

数据库名、表名和字段名在Linux MySQL环境下是区分大小写的，因此建议你统一这些字段的命名规侧，比如全部采用小写的方式。

虽然关键字和函数名称在SQL中不区分大小写，也就是如果小写的话同样可以执行。但是同时将关键词和函数名称全部大写，以便于区分数据库名、表名、字段名。

1.7、sql_model的合理设计

1.7.1、介绍

sql_mode会影响MySQL支持的sQL语法以及它执行的数据验证验查。通过设置sql_mode,可以完成不同严格程度的数据校验，有效地保障数据准确性。

MySQL服务器可以在不同的SQL模式下运行，并且可以针对不同的客户端以不同的方式应用这些模式，具体取决于sql_mode系统变量的值。

MySQL5.6和MySQL5.7默认的sql_mode模式参数是不一样的：

5.6的mode默认值为空（即：N0_ENGINE_SUBSTITUTION),其实表示的是一个空值，相当于没有什么模式
设置，可以理解为宽松模式。在这种设置下是可以允许一些非法操作的，比如允许一些非法数据的插入。
5.7的mode是STRICT_TRANS_TABLES,也就是严格模式。用于进行数据的严格校验，错误数据不能插入，报
error(错误)，并且事务回滚。

1.7.2、宽松模式Vs严格模式

宽松模式：

如果设置的是宽松模式，那么我们在插入数据的时候，即便是给了一个错误的数据，也可能会被接受，并且不报
错。

举例：我在创建一个表时，该表中有一个字段为name,给name设置的字段类型时char(10),如果我在插入数据的时候，其中name这个字段对应的有一条数据的长度超过了10，例如**’1234567890abc’**,超过了设定的字段长度10，那么不会报错，并且取前10个字符存上，也就是说你这个数据被存为了’1234567890’，而’abc’就没有了。但是，我们给的这条数据是错误的，因为超过了字段长度，但是并没有报错，并且ysq自行处理并接受了，这就是宽松模式的效果。

应用场景：通过设置sql mode为宽松模式，来保证大多数sq符合标准的sql语法，这样应用在不同数据库之间进行迁移时，则不需要对业务sq进行较大的修改。

严格模式：

出现上面宽松模式的错误，应该报错才对，所以MySQL5.7版本就将sql_mode默认值改为了严格模式。所以在生产等环境中，我们必须采用的是严格模式，进而开发、测试环境的数据库也必须要设置，这样在开发测试阶段就可以发现问题。并且我们即便是用的MySQL5.6,也应该自行将其改为严格模式。

开发经验：MySQL等数据库总想把关于数据的所有操作都自己包揽下来，包括数据的校验，其实开发中，我们应该在自己开发的项目程序级别将这些校验给做了，虽然写项目的时候麻烦了一些步骤，但是这样做之后，我们在进行数据库迁移或者在项目的迁移时，就会方便很多。

改为严格模式后可能会存在的问题：

若设置模式中包含了NO_ZER0_DATE,那么MySQL数据库不允许插入零日期，插入零日期会抛出错误而不是警告。例如，表中含字段TIMESTAMP列（如果未声明为NULL或显示DEFAULT子句）将自动分配DEFAULT’0000-00-0000:00:00’(零时间戳)，这显然是不满足sql_mode中的NO_ZERO_DATE而报错。

1.7.3、模式查看和设置

查看当前的sql_model

select @@session.sql_mode;

select @@global.sql_mode;
# 或者
show variables like 'sql_mode';

临时设置方式：设置当前窗口中设置sql_mode

SET GLOBAL sql_mode='modes...'; # 全局
SET SESSION sq1_mode='modes...';# 当前会话

# 例子
# 改为严格模式。此方法只在当前会话中生效，关闭当前会话就不生效了。
set SESSION sql_mode='STRICT_TRANS_TABLES';
# 改为严格模式。此方法在当前服务中生效，重启心ySQL服务后失效。
set GLOBAL sql_mode='STRICT_TRANS_TABLES';

永久设置方式：在/etc/my.cnf中配置sql_mode

在my.cnf文件(windows系统是my.ini文件)，新增：
1
2
[mysqld] sql_mode=ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
然后重启MySQL

当然生产环境上是禁止重启MySQL服务的，所以采用临时设置方式+永久设置方式来解决线上的问题，那么即便是有一天真的重启了MySQL服务，也会永久生效了。

1.7.4、sql_mode常用值

下面列出MySQL中最重要的3种模式：

模式名称	解释
`ONLY_FULL_GROUP_BY`	对于GROUP BY聚合操作，如果在SELECT中的列，没有在GROUP BY中出现，那么这个SQL是不合法的，因为列不在GROUP BY从句中。
`NO_AUTO_VALUE_ON_ZERO`	该值影响自增长列的插入。默认设置下，插入O或NULL代表生成下一个自增长值。如果用户希望插入的值为0，而该列又是自增长的，那么这个选项就有用了。
STRICT_TRANS_TABLES	在该模式下，如果一个值不能插入到一个事务表中，则中断当前的操作，对非事务表不做限制。
`NO_ZERO_IN_DATE`	在严格模式下，不允许日期和月份为零。
`NO_ZERO_DATE`	设置该值，ysq数据库不允许插入零日期，插入零日期会抛出错误而不是警告。
`ERROR_FOR_DIVISION_BY_ZERO`	在INSERTE或JPDATEi过程中，如果数据被零除，则产生错误而非警告。如果未给出该模式，那么数据被零除时MySQ返回NULL
`NO_AUTO_CREATE_USER`	禁止GRANT创建密码为空的用户
`NO_ENGINE_SUBSTITUTION`	如果需要的存储引擎被禁用或未编译，那么抛出错误。不设置此值时，用默认的存储引擎替代，并抛出一个异常。
`PIPES_AS_CONCAT`	将”\|\|”视为字符串的连接操作符而非或运算符，这和Oracle数据库是一样的，也和字符串的拼接函数Concat相类似
`ANSI_QUOTES`	启用ANSl_QUOTES后，不能用双引号来引用字符串，因为它被解释为识别符

2、MySQL的数据目录

2.1、MySQL8的主要目录结构

1	`find / -name mysql`

/var/lib/mysql
/var/lib/mysql/mysql
/etc/selinux/targeted/active/modules/100/mysql
/etc/logrotate.d/mysql
/usr/lib64/mysql
/usr/bin/mysql

2.1.1、数据库文件的存放路径

MySQL数据库文件的存放路径：/var/lib/mysql/

MySQL服务器程序在启动时会到文件系统的某个目录下加载一些文件，之后在运行过程中产生的数据也都会存储到这个目录下的某些文件中，这个目录就称为数据目录。

MySQL把数据都存到哪个路径下呢？其实数据目录对应着一个系统变量datadir,我们在使用客户端与服务器建立连接之后查看这个系统变量的值就可以了：

show variables like 'datadir';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+

从结果中可以看出，在我的计算机上MySQL的数据目录就是/var/lib/mysql/。

2.1.2、相关命令目录

相关命令目录：/usr/bin(mysqladmin、mysqlbinlog、mysqldump等命令)和/usr/sbin。

安装目录下非常重要的bin目录，它里边存储了许多关于控制客户端程序和服务器程序的命令（许多可执行文件，比如mysql,mysqld,mysqld_safe等)。而数据目录是用来存储MySQL在运行过程中产生的数据，注意区分开二者。

2.1.3、配置文件目录

配置文件目录：/usr/share/mysql--8.0(命令及配置文件)，/etc/mysql(如my.cnf)

2.2、数据库和文件系统的关系

像InnoDB、MyISAM这样的存储引整都是把表存储在磁盘上的，操作系统用来管理磁盘的结构被称为文件系统，所以用专业一点的话来表述就是：像InnoDB、MyISAM这样的存储引擎都是把表存储在文件系统上的。当我们想读取数据的时候，这些存储引擎会从文件系统中把数据读出来返回给我们，当我们想写入数据的时候，这些存储引擎会把这些数据又写回文件系统。本章学习一下InnoDB和MyISAM这两个存储引擎的数据如何在文件系统中存储。

2.2.1、查看默认数据库

查看一下在我的计算机上当前有哪些数据库：

1	`SHOW DATABASES;`

可以看到有4个数据库是属于MySQL自带的系统数据库。

mysql

MySQL系统自带的核心数据库，它存储了MySQL的用户账户和权限信息，一些存储过程、事件的定义信息，一些运行过程中产生的日志信息，一些帮助信息以及时区信息等。
information_schema

MySQL系统自带的数据库，这个数据库保存着MySQL服务器维护的所有其他数据库的信息，比如有哪些表、哪些视图、哪些触发器、哪些列、哪些索引。这些信息并不是真实的用户数据，而是一些描述性信息，有时候也称之为元数据。在系统数据库information_schema中提供了一些以innodb_sys开头的表，用于表示内部系统表。
1
2
USE information_schema; SHOW TABLES LIKE 'innodb_sys%';
performance_schema

MySQL系统自带的数据库，这个数据库里主要保存MySQL服务器运行过程中的一些状态信息，可以用来监控MySQL服务的各类性能指标。包括统计最近执行了哪些语句，在执行过程的每个阶段都花费了多长时间，内存的使用情况等信息。
sys

MySQL系统自带的数据库，这个数据库主要是通过视图的形式把information_schema和performance_schema结合起来，帮助系统管理员和开发人员监控MySQL的技术性能。

2.2.2、数据库在文件系统中的表示

使用CREATE DATABASE 数据库名语句创建一个数据库的时候，在文件系统上实际发生了什么呢？其实很简单，每个数据库都对应数据目录下的一个子目录，或者说对应一个文件夹，每当新建一个数据库时，MySQL会帮我们做这两件事儿：

在数据目录下创建一个和数据库名同名的子目录。
在与该数据库名同名的子目录下创建一个名为db.opt的文件（仅限MySQL5.7及之前版本），这个文件中包含了该数据库的各种属性，比如该数据库的字符集和比较规则。

我们再看一下我的计算机上的数据目录下的内容：

[root@mysql160 mysql]# cd /var/lib/mysql
[root@mysql160 mysql]# ll -h
总用量 121M
-rw-r-----. 1 mysql mysql   56 7月  20 16:20 auto.cnf
-rw-------. 1 mysql mysql 1.7K 7月  20 16:20 ca-key.pem
-rw-r--r--. 1 mysql mysql 1.1K 7月  20 16:20 ca.pem
-rw-r--r--. 1 mysql mysql 1.1K 7月  20 16:20 client-cert.pem
-rw-------. 1 mysql mysql 1.7K 7月  20 16:20 client-key.pem
-rw-r-----. 1 mysql mysql  436 7月  20 16:20 ib_buffer_pool
-rw-r-----. 1 mysql mysql  12M 7月  20 16:21 ibdata1
-rw-r-----. 1 mysql mysql  48M 7月  20 16:21 ib_logfile0
-rw-r-----. 1 mysql mysql  48M 7月  20 16:20 ib_logfile1
-rw-r-----. 1 mysql mysql  12M 7月  20 16:21 ibtmp1
drwxr-x---. 2 mysql mysql 4.0K 7月  20 16:20 mysql
srwxrwxrwx. 1 mysql mysql    0 7月  20 16:21 mysql.sock
-rw-------. 1 mysql mysql    7 7月  20 16:21 mysql.sock.lock
drwxr-x---. 2 mysql mysql 4.0K 7月  20 16:20 performance_schema
-rw-------. 1 mysql mysql 1.7K 7月  20 16:20 private_key.pem
-rw-r--r--. 1 mysql mysql  452 7月  20 16:20 public_key.pem
-rw-r--r--. 1 mysql mysql 1.1K 7月  20 16:20 server-cert.pem
-rw-------. 1 mysql mysql 1.7K 7月  20 16:20 server-key.pem
drwxr-x---. 2 mysql mysql  12K 7月  20 16:20 sys

这个数据目录下的文件和子目录比较多，除了information_schema这个系统数据库外，其他的数据库在数拥目录下都有对应的子目录。

2.2.3、表在文件系统中的表示

我们的数据其实都是以记录的形式插入到表中的，每个表的信息其实可以分为两种：

表结构的定义
表中的数据

表结构就是该表的名称，表里边有多少列，每个列的数据类型，约束条件和索引，使用的字符集和比较规则等各种信息，这些信息都体现在了我们的建表语句中了。

2.2.3.1、InnoDB存储引擎模式

1.表结构

为了保存表结构，InnoDB在数据目录下对应的数据库子目录下创建了一个专门用于描述表结构的文件，文件名是这样的

表名.frm

比方说我们在temp_db数据库下创建一个名为test的表：

mysql> USE atguigu;
Database changed

mysql> CREATE TABLE test(c1 INT);
Query OK,0 rows affected (0.03 sec)

那在数据库temp_db对应的子目录下就会创建一个名为test.frm的用于描述表结构的文件。.frm文件的格式在不同的平台上都是相同的。这个后缀名为.frm是以二进制格式存储的，我们直接打开是乱码的。

2.表中数据和索引

InnoDB:其实是使用页为基本单位来管理存储空间的，默认的页大小为16KB。

对于InnoDB存储引擎来说，每个索引都对应着一棵B+树，该B+树的每个节点都是一个数据页，数据页之间不必要是物理连续的，因为数据页之间有双向链表来维护着这些页的顺序。

InnoDB的聚簇索引的叶子节点存储了完整的用户记录，也就是所谓的索引即数据，数据即索引。

为了更好的管理这些页，InnoDB提出了一个表空间或者文件空间（英文名：table space或者file space)的概念，这个表空间是一个抽象的概念，它可以对应文件系统上一个或多个真实文件（不同表空间对应的文件数量可能不同)。每一个表空间可以被划分为很多个页，我们的表数据就存放在某个表空间下的某些页里。这里表空间有几种不同的类型：

①系统表空间(system tablespace)

默认情况下，InnoDB会在数据目录下创建一个名为ibdata1、大小为12M的文件，这个文件就是对应的系统表空间在文件系统上的表示。怎么才12M？注意这个文件是自扩展文件，当不够用的时候它会自己增加文件大
小。

当然，如果你想让系统表空间对应文件系统上多个实际文件，或者仅仅觉得原来的ibdata1这个文件名难听，那可以在MySQL启动时配置对应的文件路径以及它们的大小，比如我们这样修改一下my.cnf配置文件：

1 2	`[server] innodb_data_file_path=datal:512M;data2:512M:autoextend`

这样在MySQL启动之后就会创建这两个512M大小的文件作为系统表空间，其中的autoextend表明这两个文件如果不够用会自动扩展data2文件的大小。

需要注意的一点是，在一个MySQL服务器中，系统表空间只有一份。从MySQL5.5.7到MySQL5.6.6之间的各个版本
中，我们表中的数据都会被默认存储到这个系统表空间。

②独立表空间(file-per-table tablespace)

在MySQL5.6.6以及之后的版本中，InnoDB并不会默认的把各个表的数据存储到系统表空间中，而是为每一个表建立一个独立表空间，也就是说我们创建了多少个表，就有多少个独立表空间。使用独立表空间来存储表数据的话，会在该表所属数据库对应的子目录下创建一个表示该独立表空间的文件，文件名和表名相同，只不过添加了一个.ibd的扩展名而已，所以完整的文件名称长这样：

表名.ibd

比如：我们使用了独立表空间去存储temp_db数据库下的test表的话，那么在该表所在数据库对应的temp_db目录下会为test表创建这两个文件：

1 2	`test.frm test.ibd`

③系统表空间与独立表空间的设置

我们可以自己指定使用系统表空间还是独立表空间来存储数据，这个功能由启动参数innodb_file_per_table控制，比如说我们想刻意将表数据都存储到系统表空间时，可以在启动MySQL服务器的时候这样配置：

1 2	`[server] Innodb_file_per_table=0 # 0:代表使用系统表空间；1：代表使用独立表空间`

默认情况：

mysql> SHOW VARIABLES like 'innodb_file_per_table';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | ON    |
+-----------------------+-------+

说明：innodb_file_per_table参数的修改只对新建的表起作用，对于已经分配了表空间的表开不起作用。

如果我们想把已经存在系统表空间中的表转移到独立表空间，可以使用下边的语法：

1	`ALTER TABLE 表名 TABLESPACE [=] innodb_file_per_table;`

或者把已经存在独立表空间的表转移到系统表空间，可以使用下边的语法：

1	`ALTER TABLE 表名 TABLESPACE [=] innodb_system;`

其中括号扩起来的=可有可无，比如：我们想把test表从独立表空间移动到系统表空间，可以这么写：

1	`ALTER TABLE test TABLESPACE innodb_system;`

④其他类型的表空间
随着MySQL的发展，除了上述两种老牌表空间之外，现在还新提出了一些不同类型的表空间，比如通用表空间(general tablespace)、临时表空间(temporary tablespace)等。

3.疑问

.frm在MySQL8中不存在了。那去哪里了呢？

这就需要解析ibd文件。Oracle官方将frm文件的信息及更多信息移动到叫做序列化字典信息(Serialized Dictionary Information,SDl),SDI被写在ibd文件内部。MySQL8.0属于Oracle旗下，同理。

为了从IBD文件中提取SDl信息，Oracle提供了一个应用程序ibd2sdi

ibd2sdi官方文档

这个工具不需要下载，MySQL8自带的有，只要你配好环境变量就能到处用。

(1)查看表结构

到存储ibd文件的目录下，执行下面的命令：

1	`ibd2sdi --dump-file=t_test.txt t_test.ibd`

文件格式主要包含

表名
列
列名
列的长度

通过上面的测试结果可以发现，MySQL8把之前版本的frm文件合并到ibd文件中了。

2.2.3.2、MyISAM存储引擎模式

1.表结构

在存储表结构方面，MyISAM和InnoDB一样，也是在数据目录下对应的数据库子目录下创建了一个专门用于描
述表结构的文件：

表名.frm

2.表中数据和索引

在MylSAM中的索引全部都是二级索引，该存储引擎的数据和索引是分开存放的。所以在文件系统中也是使用不同的文件来存储数据文件和索引l文件，同时表数据都存放在对应的数据库子目录下。假如test表使用MyISAM存储引擎的话，那么在它所在数据库对应的db_test目录下会为test表创建这三个文件：

1
2
3

test.frm		存储表结构
test.MYD		存储数据(MYData)
test.MYI		存储索引(MYIndex)

其中test.MYD代表表的数据文件，也就是我们插入的用户记录。采用独立表存储模式，每个表对应一个MYD文件；test.MYI代表表的索引文件，我们为该表创建的索引都会放到这个文件中。

举例：创建一个MyISAM表，使用ENGINE选项显式指定引擎。因为InnoDB是默认引擎。

CREATE TABLE test_myisam (
	`id` BIGINT NOT NULL AUTO_INCREMENT,
	`name` VARCHAR ( 64 ) DEFAULT NULL,
	`age` INT DEFAULT NULL,
	`sex` VARCHAR ( 2 ) DEFAULT NULL,
	PRIMARY KEY ( id ) 
) ENGINE = MYISAM AUTO_INCREMENT = 0 DEFAULT CHARSET = utf8mb3

包含三个文件：

1
2
3

student_myisam.frm	--存储表结构
student_myisam.MYD	--存储数据
student_myisam.MYI	--存储索引

可以发现，在之前的数据库版本中，MyISAM引擎已存在frm文件，但是在MySQL8之后也和InnoDB引擎一样去掉了，放入了sdi文件中。

2.2.4、小结

举例：数据库a,表b

如果表b采用InnoDB,data\a中会产生1个或者2个文件：
- b.frm:描述表结构文件，字段长度等
- 如果采用系统表空间模式的，数据信息和索引信息都存储在ibdata1中
- 如果采用独立表空间存储模式，datala中还会产生b.ibd文件（存储数据信息和索引信息）
此外：
①MySQL5.7中会在data/a的目录下生成db.opt文件用于保存数据库的相关配置。比如：字符集、比较规则。而MySQL8.0不再提供db.opt文件。

②MySQL8.0中不再单独提供b.frm,而是合并在b.ibd文件中。
如果表b采用MyISAM,data\a中会产生3个文件：
- MySQL5.7中：b.frm:描述表结构文件，字段长度等。
  
  MySQL8.0中b.xxx.sdi:描述表结构文件，字段长度等
- b.MYD(MYData:数据信息文件，存储数据信息（如果采用独立表存储模式）
- b.MYI(MYIndex):存放索引信息文件

2.2.5、视图在文件系统中的表示

我们知道MySQL中的视图其实是虚拟的表，也就是某个查询语句的一个别名而已，所以在存储视图的时候是不需
要存储真实的数据的，只需要把它的结构存储起来就行了。和表一样，描述视图结构的文件也会被存储到所属数
据库对应的子目录下边，只会存储一个视图名.frm的文件。如：emp_details_view.frm

2.2.6、其他的文件

除了我们上边说的这些用户自己存储的数据以外，数据目录下还包括为了更好运行程序的一些额外文件，主要包括这几种类型的文件：

服务器进程文件

我们知道每运行一个MySQL服务器程序，都意味着启动一个进程。MySQL服务器会把自己的进程ID写入到一个文件中。
服务器日志文件
在服务器运行过程中，会产生各种各样的日志，比如常规的查询日志、错误日志、二进制日志、redo日志等。这些日志各有各的用途，后面讲解。
默认/自动生成的SSL和RSA证书和密钥文件

主要是为了客户端和服务器安全通信而创建的一些文件。

3、用户与权限管理

3.1、用户管理

MySQL用户可以分为普通用户和root用户。root用户是超级管理员，拥有所有权限，包括创建用户、删除用户和修改用户的密码等管理权限；普通用户只拥有被授予的各种权限。

MySQL提供了许多语句用来管理用户账号，这些语句可以用来管理包括登录和退出MySQL服务器、创建用户、删
除用户、密码管理和权限管理等内容。

MySQL数据库的安全性需要通过账户管理来保证。

3.1.1、登录MySQL服务器

启动MySQL服务后，可以通过mysql命令来登录MySQL服务器，命令如下：

1	`mysql –h hostname\|hostIP –P port –u username –p DatabaseName –e "SQL语句"`

-h参数后面接主机名或者主机IP，hostname为主机，hostIP为主机IP。
-P参数后面接MySQL服务的端口，通过该参数连接到指定的端口。MySQL服务的默认端口是3306，不使用该参数时自动连接到3306端口，port为连接的端口号。
-u参数后面接用户名，username为用户名。
-p参数会提示输入密码。
DatabaseName参数指明登录到哪一个数据库中。如果没有该参数，就会直接登录到MySQL数据库中，然后可以使用USE命令来选择数据库。
-e参数后面可以直接加SQL语句。登录MySQL服务器以后即可执行这个SQL语句，然后退出MySQL服务器。

1	`mysql -uroot -p -hlocalhost -P3306 mysql -e "select host,user from user"`

3.1.2、创建用户

1	`CREATE USER 用户名 [IDENTIFIED BY '密码'][,用户名 [IDENTIFIED BY '密码']];`

举例：

1 2	`CREATE USER zhang3 IDENTIFIED BY '123123'; # 默认host是 % CREATE USER 'xiaoyu'@'localhost' IDENTIFIED BY '123456';`

3.1.3、修改用户

1 2	`UPDATE mysql.user SET USER='zhang3' WHERE USER='li4'; FLUSH PRIVILEGES;`

3.1.4、删除用户

方式1：使用DROP方式删除（推荐）

1	`DROP USER user[,user]…;`

举例：

1 2	`DROP USER li4 ; # 默认删除host为%的用户 DROP USER 'xiaoyu'@'localhost';`

方式2：使用DELETE方式删除（不推荐，有残留信息）

1 2	`DELETE FROM mysql.user WHERE Host='hostname' AND User='username'; FLUSH PRIVILEGES;`

3.1.5、设置当前用户密码

1. 使用ALTER USER命令来修改当前用户密码

1	`ALTER USER USER() IDENTIFIED BY 'new_password';`

2. 使用SET语句来修改当前用户密码

1	`SET PASSWORD='new_password';`

3.1.6、修改其它用户密码

1. 使用ALTER语句来修改普通用户的密码

1	`ALTER USER 'user' [IDENTIFIED BY 'new_password'] [,user[IDENTIFIED BY 'new_password']]…;`

2. 使用SET命令来修改普通用户的密码

1	`SET PASSWORD FOR 'username'@'hostname'='new_password';`

3.1.7、MySQL8密码管理

MySQL中记录使用过的历史密码，目前包含如下密码管理功能：

密码过期：要求定期修改密码。
密码重用限制：不允许使用引旧密码。
密码强度评估：要求使用高强度的密码。

提示
MySQL密码管理功能只针对使用基于MySQL授权插件的账号，这些插件有mysql_native_password、sha256_password和caching_sha2_password

3.1.7.1、密码过期策略

在MySQL中，数据库管理员可以手动设置账号密码过期，也可以建立一个自动密码过期策略。
过期策略可以是全局的，也可以为每个账号设置单独的过期策略。

手动设置立马过期

手动设置账号密码过期，可使用如下语句：

1	`ALTER USER user PASSWORD EXPIRE;`

例子：

1	`ALTER USER li4'@'localhost'PASSWORD EXPIRE;`

该语句将用户li4的密码设置为过期，li4用户仍然可以登录进入数据库，但无法进行查询。密码过期后，只有重新设置了新密码，才能正常使用。

手动设置指定时闻过期方式①：全局

如果密码使用的时间大于允许的时间，服务器会自动设置为过期，不需要手动设置。

MySQL使用default_password_lifetime系统变量建立全局密码过期策略。

它的默认值是0，表示禁用自动密码过期。
它允许的值是正整数N,表示允许的密码生存期。密码必须每隔N天进行修改。

两种实现方式分别如下所示：

方式①：使用SQL语句更改该变量的值并持久化

1	`SET PERSIST default_password_lifetime = 180; #建立全局策略，设置密码每隔180天过期`

方式②：配置文件my.cnf中进行维护

1 2	`[mysqld] default_password_lifetime=180 #建立全局策略，设置密码每隔180天过期`

手动设置指定时间过期方式②：单独设置

每个账号既可延用全局密码过期策略，也可单独设置策略。在CREATE USER和ALTER USER语句上加入PASSWORD EXPIRE选项可实现单独设置策略。下面是一些语句示例。

#设置 li4 账号密码每90天过期：
CREATE USER 'li4'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;
ALTER USER 'li4'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;

#设置密码永不过期：
CREATE USER 'li4'@'localhost' PASSWORD EXPIRE NEVER;
ALTER USER 'li4'@'localhost' PASSWORD EXPIRE NEVER;

#延用全局密码过期策略：
CREATE USER 'li4'@'localhost' PASSWORD EXPIRE DEFAULT;
ALTER USER 'li4'@'localhost' PASSWORD EXPIRE DEFAULT;

3.1.7.2、密码重用策略

MySQL限制使用已用过的密码。重用限制策略基于密码更改的数量和使用的时间。重用策略可以是全局的，也可以为每个账号设置单独的策略。

账号的历史密码包含过去该账号所使用的密码。MySQL基于以下规则来限制密码重用：
- 如果账号的密码限制基于密码更改的数量，那么新密码不能从最近限制的密码数量中选择。例如，如果密码更改的最小值为3，那么新密码不能与最近3个密码中任何一个相同。
- 如果账号密码限制基于时间，那么新密码不能从规定时间内选择。例如，如果密码重用周期为60天，那么新密码不能从最近60天内使用的密码中选择。
MySQL使用password_history和password_reuse_interval系统变量设置密码重用策略。
- password_history:规定密码重用的数量_
- password_reuse_interval:规定密码重用的周期
这两个值可在服务器的配置文件中进行维护，也可在运行期间使用SQL语句更改该变量的值并持久化。

手动设置密码重用方式1：全局

方式①：使用SQL

1 2	`SET PERSIST password_history=6; #设置不能选择最近使用过的6个密码 SET PERSIST password_reuse_interval=365; #设置不能选择最近一年内的密码`

方式②：my.cnf配置文件

1
2
3

[mysql]
password_history=6
password_reuse_interval=365

手动设置密码重用方式2：单独设置

每个账号可以延用全局密码重用策略，也可单独设置策略。这两个选项可以单独使用，也可以结合在一起使用。

下面是一些语句示例。

#不能使用最近5个密码：
CREATE USER 'li4'@'localhost' PASSWORD HISTORY 5;
ALTER USER 'li4'@'localhost' PASSWORD HISTORY 5;
#不能使用最近365天内的密码：
CREATE USER 'li4'@'localhost' PASSWORD REUSE INTERVAL 365 DAY;
ALTER USER 'li4'@'localhost' PASSWORD REUSE INTERVAL 365 DAY;

#既不能使用最近5个密码，也不能使用365天内的密码
CREATE USER 'li4'@'localhost'
PASSWORD HISTORY 5
PASSWORD REUSE INTERVAL 365 DAY
ALTER USER 'li4'@'localhost'
PASSWORD HISTORY 5
PASSWORD REUSE INTERVAL 365 DAY;

#延用全局策略
CREATE USER 'li4'@'localhost
PASSWORD HISTORY DEFAULT
PASSWORD REUSE INTERVAL DEFAULT;
ALTER USER 'li4'@'localhost'
PASSWORD HISTORY DEFAULT
PASSWORD REUSE INTERVAL DEFAULT;

3.2、权限管理

关于MySQL的权限简单的理解就是MySQL允许你做你权力以内的事情，不可以越界。比如只允许你执行SELECT操作，那么你就不能执行UPDATE操作。只允许你从某台机器上连接MySQL,那么你就不能从除那台机器以外的其他机器连接MySOL。

3.2.1、权限列表

1	`show privileges;`

GRANT和REVOKE语句中可以使用的权限如下：

CREATE和DROP权限，可以创建新的数据库和表，或删除（移掉）已有的数据库和表。如果将MySQL数据库中的DROP权限授予某用户，用户就可以删除MySQL访问权限保存的数据库。
SELECT、INSERT、UPDATE和DELETE权限允许在一个数据库现有的表上实施操作。
SELECT权限只有在它们真正从一个表中检索行时才被用到。
INDEX权限允许创建或删除索引，INDEX适用于已有的表。如果具有某个表的CREATE权限，就可以在CREATE TABLE语句中包括索引定义。
ALTER权限可以使用ALTER TABLE来更改表的结构和重新命名表。
CREATE ROUTINE权限用来创建保存的程序（函数和程序），ALTER ROUTINE权限用来更改和删除保存的程序，EXECUTE权限用来执行保存的程序。
GRANT权限允许授权给其他用户，可用于数据库、表和保存的程序。
FILE权限使用户可以使用LOAD DATA INFILE和SELECT ... INTO OUTFILE语句读或写服务器上的文件，任何被授予FILE权限的用户都能读或写MySQL服务器上的任何文件（说明用户可以读任何数据库目录下的文件，因为服务器可以访问这些文件）。

MySQL的权限如何分布

权限分布	可能的设置权限
表权限	`Select`,`Insert`,`Update`,`Delete`,`Create`,`Drop`,`Grant`,`References`,`Index`,`Alter`
列权限	`Select`,`Insert`,`Update`,`References`
过程权限	`Execute`,`Alter` ,`Routine`,`Grant`

3.2.2、授予权限的原则

权限控制主要是出于安全因素，因此需要遵循以下几个经验原则：

只授予能满足需要的最小权限，防止用户干坏事。比如用户只是需要查询，那就只给select权限就可以了，不要给用户赋予update、insert或者delete权限。
创建用户的时候限制用户的登录主机，一般是限制成指定IP或者内网IP段。
为每个用户设置满足密码复杂度的密码。
定期清理不需要的用户，回收权限或者删除用户。

3.2.3、授予权限

给用户授权的方式有2种，分别是通过把角色赋予用户给用户授权和直接给用户授权。用户是数据库的使用者，我们可以通过给用户授予访问数据库中资源的权限，来控制使用者对数据库的访问，消除安全隐患。

权限命令：

1	`GRANT 权限1,权限2,…权限n ON 数据库名称.表名称 TO 用户名@用户地址 [IDENTIFIED BY ‘密码口令’];`

该权限如果发现没有该用户，则会直接新建一个用户。
给li4用户用本地命令行方式，授予test_db这个库下的所有表的插删改查的权限。

1	`GRANT SELECT,INSERT,DELETE,UPDATE ON test_db.* TO li4@localhost;`

授予通过网络方式登录的joe用户，对所有库所有表的全部权限，密码设为123。注意这里唯独不包括grant的权限

1	`GRANT ALL PRIVILEGES ON . TO joe@'%' IDENTIFIED BY '123';`

ALL PRIVILEGES是表示所有权限，你也可以使用SELECT、UPDATE:等权限。
ON用来指定权限针对哪些库和表。
.中前面的*号用来指定数据库名，后面的*****号用来指定表名。这里的*表示所有的。
TO表示将权限赋予某个用户。
li4@'localhost'表示li4用户，@后面接限制的主机，可以是IP、IP段、域名以及%，%表示任何地方。注意：这里%有的版本不包括本地，以前碰到过给某个用户设置了%允许任何地方登录，但是在本地登录不了，这个和版本有关系，遇到这个问题再加一个localhost的用户就可以了。
IDENTIFIED BY指定用户的登录密码。

如果需要赋予包括GRANTE的权限，添加参数WITH GRANT OPTION这个选项即可，表示该用户可以将自己拥有的权限授权给别人。经常有人在创建操作用户的时候不指定NITH GRANT OPTION:选项导致后来该用户不能使用GRANT命令创建用户或者给其它用户授权。

可以使用GRANTI重复给用户添加权限，权限叠加，比如你先给用户添加一个SELECT权限，然后又给用户添加一个INSERT权限，那么该用户就同时拥有了SELECT和INSERT权限。

我们在开发应用的时候，经常会遇到一种需求，就是要根据用户的不同，对数据进行横向和纵向的分组。

所谓横向的分组，就是指用户可以接触到的数据的范围，比如可以看到哪些表的数据；

所谓纵向的分组，就是指用户对接触到的数据能访问到什么程度，比如能看、能改，甚至是删除。

3.2.4、查看权限

查看当前用户权限

SHOW GRANTS; 
# 或 
SHOW GRANTS FOR CURRENT_USER; 
# 或 
SHOW GRANTS FOR CURRENT_USER();

查看某用户的全局权限

1	`SHOW GRANTS FOR 'user'@'主机地址';`

3.2.5、收回权限

收回权限就是取消已经赋予用户的某些权限。收回用户不必要的权限可以在一定程度上保证系统的安全性。MySQL中使用REVOKE语句取消用户的某些权限。使用REVOKEI收回权限之后，用户账户的记录将从db、host、tables_priv和columns_priv表中删除，但是用户账户记录仍然在user表中保存（删除user表中的账户记录使用DROP USER语句)。

注意：在将用户账户从user表删除之前，应该收回相应用户的所有权限。

收回权限命令

1	`REVOKE 权限1,权限2,…权限n ON 数据库名称.表名称 FROM 用户名@用户地址;`

举例

#收回全库全表的所有权限 
REVOKE ALL PRIVILEGES ON *.* FROM joe@'%'; 
#收回mysql库下的所有表的插删改查权限 
REVOKE SELECT,INSERT,UPDATE,DELETE ON mysql.* FROM joe@localhost;

注意：须用户重新登录后才能生效

总结：

有一些程序员喜欢使用Root超级用户来访问数据库，完全把权限控制放在应用层面实现。这样当然也是可以的。但建议大家，尽量使用数据库自己的角色和用户机制来控制访问权限，不要轻易用Root账号。因为Root账号密码放在代码里面不安全，一旦泄露，数据库就会完全失去保护。

而且，MySQL的权限控制功能十分完善，应该尽量利用，可以提高效率，而且安全可靠。

3.3、权限表

MySQL服务器通过权限表来控制用户对数据库的访问，权限表存放在mysq1数据库中。MySQL数据库系统会根据这些权限表的内容为每个用户赋予相应的权限。这些权限表中最重要的是user表、db表。除此之外，还有table_priv表、column_priv表和proc-priv表等。在MySQL启动时，服务器将这些数据库表中权限信息的内容读入内存。

表名	描述
`user`	用户账号及权限信息
`global_grants`	动态全局授权
`db`	数据库层级的权限
`tables_priv`	表层级的权限
`columns_priv`	列层级的权限
`procs_priv`	存储的过程和函数权限
`proxies_priv`	代理用户的权限
`default_roles`	账号连接并认证后默认授了的角色
`role_edges`	角色了图的边界
`password_history`	密码更改信息

3.3.1、user表

user表是MySQL中最重要的一个权限表， 记录用户账号和权限信息，有49个字段。

这些字段可以分成4类，分别是范围列（或用户列）、权限列、安全列和资源控制列.

范围列（或用户列）
- host：表示连接类型
  - %表示所有远程通过 TCP方式的连接
  - IP地址如 (192.168.1.2、127.0.0.1) 通过制定ip地址进行的TCP方式的连接
  - 机器名通过制定网络中的机器名进行的TCP方式的连接
  - ::1IPv6的本地ip地址，等同于IPv4的 127.0.0.1
  - localhost本地方式通过命令行方式的连接，比如mysql -u xxx -p xxx 方式的连接。
- user：表示用户名，同一用户通过不同方式链接的权限是不一样的。
- password：密码
  - 所有密码串通过password(明文字符串) 生成的密文字符串。MySQL8.0在用户管理方面增加了角色管理，默认的密码加密方式也做了调整，由之前的SHA1改为了SHA2，不可逆。同时加上 MySQL5.7的禁用用户和用户过期的功能，MySQL在用户管理方面的功能和安全性都较之前版本大大的增强了。
  - mysql 5.7 及之后版本的密码保存到authentication_string字段中不再使用password字段。
权限列
- Grant_priv字段
  - 表示是否拥有GRANT权限
- Shutdown_priv字段
  - 表示是否拥有停止MySQL服务的权限
- Super_priv字段
  - 表示是否拥有超级权限
- Execute_priv字段
  - 表示是否拥有EXECUTE权限。拥有EXECUTE权限，可以执行存储过程和函数。
- Select_priv , Insert_priv等
  - 为该用户所拥有的权限。
安全列

安全列只有6个字段，其中两个是ssl相关的（ssl_type、ssl_cipher），用于加密；两个是x509相关的（x509_issuer、x509_subject），用于标识用户 ；另外两个Plugin字段用于验证用户身份的插件，该字段不能为空。如果该字段为空，服务器就使用内建授权验证机制验证用户身份。
资源控制列

资源控制列的字段用来限制用户使用的资源，包含4个字段，分别为：
1. max_questions，用户每小时允许执行的查询操作次数；
2. max_updates，用户每小时允许执行的更新操作次数；
3. max_connections，用户每小时允许执行的连接操作次数；
4. max_user_connections，用户允许同时建立的连接次数。

查看字段：

1	`DESC mysql.user;`

查看用户, 以列的方式显示数据：

1	`SELECT * FROM mysql.user \G;`

查询特定字段：

1	`SELECT host,user,authentication_string,select_priv,insert_priv,drop_priv FROM mysql.user;`

3.3.2、db表

使用DESCRIBE查看db表的基本结构：

用户列

db表用户列有3个字段，分别是Host、User、Db。这3个字段分别表示主机名、用户名和数据库名。表示从某个主机连接某个用户对某个数据库的操作权限，这3个字段的组合构成了db表的主键。
权限列

Create_routine_priv和Alter_routine_priv这两个字段决定用户是否具有创建和修改存储过程的权限

3.3.3、 tables_priv表和columns_priv表

tables_priv表用来对表设置操作权限，columns_priv表用来对表的某一列设置权限。tables_priv表和columns_priv表的结构分别如下：

1	`desc mysql.tables_priv;`

tables_priv表有8个字段，分别是Host、Db、User、Table_name、Grantor、Timestamp、Table_priv和Column_priv，各个字段说明如下：

Host、Db、User、Table_name四个字段分别表示主机名、数据库名、用户名和表名。
Grantor表示修改该记录的用户。
Timestamp表示修改该记录的时间。
Table_priv表示对象的操作权限。包括Select、Insert、Update、Delete、Create、Drop、Grant、 References、Index和Alter。
Column_priv字段表示对表中的列的操作权限，包括Select、Insert、Update和References。

1	`desc mysql.columns_priv;`

3.3.4、procs_priv表

procs_priv表可以对存储过程和存储函数设置操作权限，表结构如下查看：

1	`desc mysql.procs_priv;`

3.4、访问控制

正常情况下，并不希望每个用户都可以执行所有的数据库操作。当MySQL允许一个用户执行各种操作时，它将首先核实该用户向MySQL服务器发送的连接请求，然后确认用户的操作请求是否被允许。这个过程称为MySQL中的访问控制过程。MySQL的访问控制分为两个阶段：连接核实阶段和请求核实阶段。

3.4.1、连接核实阶段

当用户试图连接MySQL服务器时，服务器基于用户的身份以及用户是否能提供正确的密码验证身份来确定接受或者拒绝连接。即客户端用户会在连接请求中提供用户名、主机地址、用户密码，MySQL服务器接收到用户请求后，会使用user表中的host、user和authentication_string这3个字段匹配客户端提供信息。

服务器只有在use表记录的Host和User字段匹配客户端主机名和用户名，并且提供正确的密码时才接受连接。如果连接核实没有通过，服务器就完全拒绝访问；否则，服务器接受连接，然后进入阶段2等待用户请求。

3.4.2、请求核实阶段

一旦建立了连接，服务器就进入了访问控制的阶段2，也就是请求核实阶段。对此连接上进来的每个请求，服务器检查该请求要执行什么操作、是否有足够的权限来执行它，这正是需要授权表中的权限列发挥作用的地方。这些权限可以来自user、db、table_priv和column_priv表。

确认权限时，ySQL首先检查user表，如果指定的权限没有在user表中被授予，那么ySQL就会继续检查db表，db表是下一安全层级，其中的权限限定于数据库层级，在该层级的SELECT权限允许用户查看指定数据库的所有表中的数据；如果在该层级没有找到限定的权限，则MySQL继续检查tables_priv表以及co1umns_priv表，如果所有权限表都检查完毕，但还是没有找到允许的权限操作，MySQL将返回错误信息，用户请求的操作不能执行，操作失败。步骤如下：

用户向MySQL发出操作请求
MySQL检查user权限表中的权限信息，匹配user、host字段值，查看请求的全局权限是否被允许，如果找到匹配结果，操作被允许执行，否则MySQL继续向下查找.
MySQL检查db权限表中的权限信息，匹配user、host字段值，查看请求的数据库级别的权限是否被允许，如果找到匹配结果，操作被允许执行，否则MySQL继续向下查找
MySQL检查table_priv权限表中的权限信息，匹配user、host字段值，查看请求的数据表级别的权限是否被允许，如果找到匹配结果，操作被允许执行，否则MySQL继续向下查找.
MySQL检查columns_priv权限表中的权限信息，匹配user、host字段值，查看请求的列级别的权限是否被允许，如果找到匹配结果，操作被允许执行，否则MySQLi返回错误信息.

提示：MySQL通过向下层级的顺序（从user表到columns_priv表）检查权限表，但并不是所有的权限都要执行该过程。例如，一个用户登录到MySQL服务器之后只执行对MySQL的管理操作，此时只
涉及管理权限，因此MySQL只检查user表。另外，如果请求的权限操作不被允许，MySQL也不会继续检查下一层级的表。

3.5、角色管理

3.5.1、角色的理解

角色是在MySQL8.0中引入的新功能。在MySQL中，角色是权限的集合，可以为角色添加或移除权限。用户可以被赋予角色，同时也被授予角色包含的权限。对角色进行操作需要较高的权限。并且像用户账户一样，角色可以拥有授予和撤消的权限。

引入角色的目的是方便管理拥有相同权限的用户。恰当的权限设定，可以确保数据的安全性，这是至关重要的。

3.5.2、创建角色

在实际应用中，为了安全性，需要给用户授予权限。当用户数量较多时，为了避免单独给每一个用户授予多个权限，可以先将权限集合放入角色中，再赋予用户相应的角色。

创建角色使用CREATE ROLE语句，语法如下：

1	`CREATE ROLE 'role_name'[@'host_name'] [,'role_name'[@'host_name']]...`

角色名称的命名规则和用户名类似。如果host_name省略，默认为%，role_name不可省略，不可为空。

3.5.3、给角色赋予权限

1	`GRANT privileges ON table_name TO 'role_name'[@'host_name'];`

上述语句中privileges代表权限的名称，多个权限以逗号隔开。可使用SHOW语句查询权限名称

1	`SHOW PRIVILEGES\G`

3.5.4、查看角色的权限

1	`SHOW GRANTS FOR 'role_name';`

只要你创建了一个角色，系统就会自动给你一个“USAGE”权限，意思是连接登录数据库的权限。

3.5.5、回收角色的权限

1	`REVOKE privileges ON tablename FROM 'rolename';`

3.5.6、删除角色

1	`DROP ROLE role [,role2]...`

注意，如果你删除了角色，那么用户也就失去了通过这个角色所获得的所有权限。

3.5.7、给用户赋予角色

角色创建并授权后，要赋给用户并处于激活状态才能发挥作用。

1	`GRANT role [,role2,...] TO user [,user2,...];`

查询当前已激活的角色，如果角色未激活，结果将显示NONE。

1	`SELECT CURRENT_ROLE();`

3.5.8、激活角色

方式1：使用set default role命令激活角色

# 为user_name用户激活role_name角色
SET DEFAULT ROLE 'role_name'@'%' TO 'user_name'@'localhost';
# 为user_name用户激活所有已拥有的角色
SET DEFAULT ROLE ALL TO 'user_name'@'localhost';

举例：使用SET DEFAULT ROLE为下面4个用户默认激活所有已拥有的角色如下：

SET DEFAULT ROLE ALL TO 'dev1'@'localhost',
                        'read_user1'@'localhost',
                        'read_user2'@'localhost',
                        'rw_user1'@'localhost';

注意：用户需要退出重新登录，才能看到赋予的角色。

方式2：将activate_all_roles_on_login设置为ON

默认情况：

mysql> show variables like 'activate_all_roles_on_login';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| activate_all_roles_on_login | OFF   |
+-----------------------------+-------+

设置：

1	`SET GLOBAL activate_all_roles_on_login=ON;`

这条 SQL 语句的意思是，对所有角色永久激活。运行这条语句之后，用户才真正拥有了赋予角色的所有权限。

3.5.9、撤销用户的角色

1	`REVOKE role FROM user;`

例子：撤销kangshifu用户的school_read角色。（

撤销的SQL语句如下

1	`REVOKE 'school_read' FROM 'kangshifu'@'localhost';`

撤销后，执行如下查询语句，查看kangshifu用户的角色信息
1
SHOW GRANTS FOR 'kangshifu'@'localhost';

执行发现，用户kangshifu之前的school_read角色已被撤销。

3.5.10、设置强制角色(mandatory role)

方式1：服务启动前设置

1 2	`[mysqld] mandatory_roles='role1,role2@localhost,r3@%.atguigu.com'`

方式2：运行时设置

1 2	`SET PERSIST mandatory_roles = 'role1,role2@localhost,r3@%.example.com'; #系统重启后仍然有效 SET GLOBAL mandatory_roles = 'role1,role2@localhost,r3@%.example.com'; #系统重启后失效`

3.6、配置文件的使用

3.6.1、配置文件格式

与在命令行中指定启动选项不同的是，配置文件中的启动选项被划分为若干个组，每个组有一个组名，用中括号[]扩起来，像这样：

[server]
(具体的启动选项...)

[mysqld]
(具体的启动选项...)

[mysqld_safe]
(具体的启动选项...)

[client]
(具体的启动选项...)

[mysql]
(具体的启动选项...)

[mysqladmin]
(具体的启动选项...)

像这个配置文件里就定义了许多个组，组名分别是server、mysqld、mysqld_safe、client、mysql、mysqladmin。每个组下边可以定义若干个启动选项，我们以[server]组为例来看一下填写启动选项的形式(其他组中启动选项的形式是一样的)：

[server]
option1						#这是option1,该选项不需要选项值
option2=value2				 #这是option2,该选项需要选项值
...............

在配置文件中指定启动选项的语法类似于命令行语法，但是配置文件中指定的启动选项不允许加–前缀，并且每行只指定一个选项，而且=周围可以有空白字符（命令行中选项名、=、选项值之间不允许有空白字符）。另外，在配置文件中，我们可以使用#来添加注释，从#出现直到行尾的内容都属于注释内容，读取配置文件时会忽略这些注释内容。

3.6.2、启动命令与选项组

配置文件中不同的选项组是给不同的启动命令使用的。不过有两个选项组比较特别：

[server]组下边的启动选项将作用于所有的服务器程序。
client组下边的启动选项将作用于所有的客户端程序。

下面是启动命令能读取的选项组都有哪些：

启动命令	类别	能读取的组
`mysqld`	启动服务器	`[mysqld]`、`[server]`
`mysqld_safe`	启动服务器	`[mysqld]`、`[server]`、`[mysqld_safe]`
`mysql.server`	启动服务器	`[mysqld]`、`[server]`、`[mysql.server]`
`mysql`	启动客户端	`[mysql]`、`[client]`
`mysqladmin`	启动客户端	`mysqladmin`、`client`
`mysqldump`	启动客户端	`mysqldump`、`client`

比如，在/etc/mysql/my.cnf这个配置文件中添加一些内容：

1
2
3

[server]
skip-networking
default-storage-engine=MyISAM

然后直接用mysqld启动服务器程序：

mysqld

虽然在命令行没有添加启动选项，但是在程序启动的时候，就会默认的到我们上边提到的配置文件路径下查找配置文件，其中就包括/etc/my.cnf。又由于mysqld命令可以读取[server]选项组的内容，所以skip-networking和default-storage-ngine=MyISAM这两个选项是生效的。你可以把这些启动选项放在[client]组里再试试用mysqld启动服务器程序，就不生效。

3.6.3、特定MySQL版本的专用选项组

我们可以在选项组的名称后加上特定的MySQL版本号，比如对于[mysqld]选项组来说，我们可以定义一个[mysqld-5.7]的选项组，它的含义和[mysqld]一样，只不过只有版本号为5.7的mysqld程序才能使用这个选项组中的选项。

3.6.4、同一个配置文件中多个组的优先级

我们说同一个命令可以访问配置文件中的多个组，比如mysqld可以访问[mysqld]、[server]组，如果在同一个配置文件中，比如~/.my.cnf在这些组里出现了同样的配置项，比如这样：

[server]
default-storage-engine=InnoDB

[mysqld]
default-storage-engine=MyISAM

那么，将以最后一个出现的组中的启动选项为准，比方说例子中default-storage-engine既出现在[mysqld]组也出现在[server]组，因为[mysqld]组在[server]组后边，就以[mysqld]组中的配置项为准。

3.6.5、命令行和配置文件中启动选项的区别

在命令行上指定的绝大部分启动选项都可以放到配置文件中，但是有一些选项是专门为命令行设计的，比方说defaults-extra-file、defaults-file这样的选项本身就是为了指定配置文件路径的，再放在配置文件中使用就没啥意义了。

如果同一个启动选项既出现在命令行中，又出现在配置文件中，那么以命令行中的启动选项为准！比如我们在配置文件中写了：

1 2	`[server] default-storage-engine=InnoDB`

而我们的启动命令是：

1	`mysql.server start --default-storage-engine=MyISAM`

那最后default-storage-engine的值就是MyISAM。

3.7、系统变量

3.7.1、系统变量简介

MySQL服务器程序运行过程中会用到许多影响程序行为的变量，它们被称为MySQL系统变量。比如：

max_connections：允许同时连入的客户端数量

default_storage_engine：表的默认存储引擎用系统变量

query_cache_size：查询缓存的大小

MySQL服务器程序的系统变量有好几百条，我们就不一一列举了。

3.7.2、查看系统变量

查看MySQL服务器程序支持的系统变量以及它们的当前值：

# 查看所有全局变量
SHOW GLOBAL VARIABLES;
# 查看所有会话变量
SHOW SESSION VARIABLES;
# 或
SHOW VARIABLES

# 查看满足条件的部分系统变量。
SHOW GLOBAL VARIABLES LIKE '%标识符%';

# 查看满足条件的部分会话变量
SHOW SESSION VARIABLES LIKE '%标识符%';

由于系统变量实在太多了，所以通常都会带一个LIKE过滤条件来查看我们需要的系统变量的值。

mysql> SHOW VARIABLES LIKE 'default_storage_engine';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| default_storage_engine | InnoDB |
+------------------------+--------+

mysql> SHOW VARIABLES LIKE 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+

LIKE表达式后边可以跟通配符来进行模糊查询，也就是说我们可以这么写：

mysql> SHOW VARIABLES LIKE 'default%';
+-------------------------------+-----------------------+
| Variable_name                 | Value                 |
+-------------------------------+-----------------------+
| default_authentication_plugin | caching_sha2_password |
| default_collation_for_utf8mb4 | utf8mb4_0900_ai_ci    |
| default_password_lifetime     | 0                     |
| default_storage_engine        | InnoDB                |
| default_table_encryption      | OFF                   |
| default_tmp_storage_engine    | InnoDB                |
| default_week_format           | 0                     |
+-------------------------------+-----------------------+

这样就查出了所有以default开头的系统变量的值。

3.7.3、设置系统变量

3.7.3.1、通过启动选项设置

大部分的系统变量都可以通过启动服务器时传送启动选项的方式来进行设置。如何填写启动选项我们总结一下，主要是两种方式：

通过命令行添加启动选项
比方说我们在启动服务器程序时用这个命令：
1
mysqld --default-storage-engine=MyISAM --max-connections=10
通过配置文件添加启动选项
我们可以这样填写配置文件：
1
2
3
[server] default-storage-engine=MyISAM max-connections=10
当使用上边两种方式中的任意一种启动服务器程序后，我们再来查看一下系统变量的值：

mysql> SHOW VARIABLES LIKE 'default_storage_engine';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| default_storage_engine | MyISAM |
+------------------------+--------+

mysql> SHOW VARIABLES LIKE 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 10    |
+-----------------+-------+

可以看到default_storage_engine和max_connections这两个系统变量的值已经被修改了。有一点需要注意的是，对于启动选项来说，如果启动选项名由多个单词组成，各个单词之间用短划线-或者下划线_连接起来都可以，但是它对应的系统变量的单词之间必须使用下划线_连接起来。

3.7.3.2、服务器程序运行过程中设置

对于大部分系统变量来说，它们的值可以在服务器程序运行过程中进行动态修改而无需停止并重启服务器。但是，系统变量有作用范围之分。

设置不同作用范围的系统变量

多个客户端程序可以同时连接到一个服务器程序。对于同一个系统变量，我们有时想让不同的客户端有不同的值。比方说客户端A,他想让当前客户端对应的默认存储引擎为InnoDB,所以他可以把系统变量default_storage_engine的值设置为InnoDB;客户端B,他想让当前客户端对应的默认存储引擎为MyISAM,所以他可以把系统变量default_storage_engine的值设置为MyISAM。这样两个客户端拥有不同的默认存储引擎，使用时互不影响，十分方便。但是这样各个客户端都私有一份系统变量会产生这么两个问题：

有一些系统变量并不是针对单个客户端的，比如允许同时连接到服务器的客户端数量max_connections,查询缓存的大小query_cache_size,这些公有的系统变量让某个客户端私有显然不合适。
一个新连接到服务器的客户端对应的系统变量的值该怎么设置？

为了解决这两个问题，MySQL提出了系统变量作用范围的概念，具体来说作用范围分为这两种：

GLOBAL:全局变量，影响服务器的整体操作。
SESSION:会话变量，影响某个客户端连接的操作。（注：SESSION有个别名叫LOCAL)

在服务器启动时，会将每个全局变量初始化为其默认值（可以通过命令行或选项文件中指定的选项更改这些默认值)。然后服务器还为每个连接的客户端维护一组会话变量，客户端的会话变量在连接时使用相应全局变量的当前值初始化。

以default_storage_engine举例，在服务器启动时会初始化一个名为default_storage_engine,作用范围为GLOBAL的系统变量。之后每当有一个客户端连接到该服务器时，服务器都会单独为该客户端分配一个名为default_storage_engine,作用范围为SESSION的系统变量，该作用范围为SESSION的系统变量值按照当前作用范围为GLOBAL的同名系统变量值进行初始化。

很显然，通过启动选项设置的系统变量的作用范围都是GLOBAL的，也就是对所有客户端都有效的，因为在系统启动的时候还没有客户端程序连接进来呢。了解了系统变量的GLOBAL和SESSION作用范围之后，我们再看一下在服务器程序运行期间通过客户端程序设置系统变量的语法：

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

或者写成这样也行：

1	`SET [@@(GLOBAL\|SESSION).]var_name = XXX;`

比如，服务器运行过程中把作用范围为GLOBAL的系统变量default_storage_engine的值修改为MyISAM,也就是想让之后新连接到服务器的客户端都用MyISAM作为默认的存储引擎，那我们可以选择下边两条语句中的任意一条来进行设置：

# 方式一：
SET GLOBAL default_storage_engine MyISAM;
# 方式二：
SET @@GLOBAL.default_storage_engine = MyISAM;

如果只想对本客户端生效，也可以选择下边三条语句中的任意一条来进行设置：

# 方式一：
SET SESSION default_storage_engine = MyISAM;
# 方式二：
SET @@SESSION.default_storage_engine = MyISAM;
# 方式二：
SET default_storage_engine MyISAM;

从上边的方式三可以看出，如果在设置系统变量的语句中省略了作用范围，默认的作用范围就是SESSI0N。也就是说SET 系统变量名 = 值和SET SESSION 系统变里名 = 值是等价的。

查看不同作用范围的系统变量

既然系统变量有作用范围之分，我们的SHOW VARIABLES语句查看的是什么作用范围的系统变量呢？

答：默认查看的是SESSION作用范围的系统变量。

我们也可以在查看系统变量的语句上加上要查看哪个作用范围的系统变量：

1	`SHOW [GLOBAL\|SESSION] VARIABLES [LIKE 匹配的模式];`

下边我们演示一下完整的设置并查看系统变量的过程：

mysql> SHOW SESSION VARIABLES LIKE 'default_storage_engine';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| default_storage_engine | InnoDB |
+------------------------+--------+

mysql> SHOW GLOBAL VARIABLES LIKE 'default_storage_engine';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| default_storage_engine | InnoDB |
+------------------------+--------+

mysql> SET SESSION default_storage_engine = MyISAM;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW SESSION VARIABLES LIKE 'default_storage_engine';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| default_storage_engine | MyISAM |
+------------------------+--------+

mysql> SHOW GLOBAL VARIABLES LIKE 'default_storage_engine';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| default_storage_engine | InnoDB |
+------------------------+--------+

可以看到，最初default_storage_engine的系统变量无论是在GLOBAL作用范围上还是在SESSI0N作用范围上的值都是InnoDB,我们在SESSION作用范围把它的值设置为MyISAM之后，可以看到GLOBAL作用范围的值并没有改变。

小贴士：如果某个客户端改变了某个系统变量在GLOBAL作用范围的值，并不会影响该系统变量在当前已经连接的客户端作用范围为SESSION的值，只会影响后续连入的客户端在作用范围为SESSION的值。

注意事项

并不是所有系统变量都具有GLOBAL和SESSION的作用范围。

有一些系统变量只具有GL0BAL作用范围，比方说max_connections,表示服务器程序支持同时最多有多少个客户端程序进行连接。
有一些系统变量只具有SESSION作用范围，比如insert_id,表示在对某个包含AUTO_INCREMENT列的表进行插入时，该列初始的值。
有一些系统变量的值既具有GLOBAL作用范围，也具有SESSION作用范围，比如我们前边用到的default_storage_engine,而目其实大部分的系统变量都是这样的
有些系统变量是只读的，并不能设置值。

比方说version,表示当前MySQL的版本，我们客户端是不能设置它的值的，只能在SHOW VARIABLES语句
里查看。

4、逻辑架构

4.1、逻辑架构剖析

4.1.1、服务器处理客户端请求

首先MySQL是典型的C/S架构，即Client/Serler架构，服务器端程序使用的mysqld。

不论客户端进程和服务器进程是采用哪种方式进行通信，最后实现的效果都是：客户端进程向服务器进程发送一段文本(SQL语句)，服务器进程处理后再向客户端进程发送一段文本（处理结果）。

那服务器进程对客户端进程发送的请求做了什么处理，才能产生最后的处理结果呢？这里以查询请求为例展示：

MySQL逻辑架构(简)

下面具体展开来看一下：

MySQL逻辑架构

4.1.1、Connectors

Connectors,指的是不同语言中与SQL的交互。MySQL首先是一个网络程序，在TCP之上定义了自己的应用层协议。所以要使用MySQL,我们可以编写代码，跟MySQL Server建立TCP连接，之后按照其定义好的协议进行交互。或者比较方便的办法是调用SDK,比如Native C API、JDBC、PHP等各语言MySQL Connector,或者通过ODBC。但通过SDK来访问MySQL,本质上还是在TCP连接上通过MySQL协议跟MySQL进行交互。

接下来的MySQL Server结构可以分为如下的三层：

4.1.2、第1层：连接层

系统（客户端）访问MySQL服务器前，做的第一件事就是建立TCP连接。

经过三次握手建立连接成功后，MySQL服务器对TCP传输过来的账号密码做身份认证、权限获取。

用户名或密码不对，会收到一个Access denied for user错误，客户端程序结束执行
用户名密码认证通过，会从权限表查出账号拥有的权限与连接关联，之后的权限判断逻辑，都将依赖于此时读到的权限

接着我们来思考一个问题

一个系统只会和MySQL服务器建立一个连接吗？只能有一个系统和MySQL服务器建立连接吗？

当然不是，多个系统都可以和MySQL服务器建立连接，每个系统建立的连接肯定不止一个。所以，为了解决TCP无限创建与TCP频繁创建销毁带来的资源耗尽、性能下降问题。MySQL服务器里有专门的TCP连接池限制连接数采用长连接模式复用TCP连接，来解决上述问题。

TCP连接收到请求后，必须要分配给一个线程专门与这个客户端的交互。所以还会有个线程池，去走后面的流程。每一个连接从线程池中获取线程，省去了创建和销毁线程的开销。

这些内容我们都归纳到MySQL的连接管理组件中。

所以连接管理的职责是负责认证、管理连接、获取权限信息。

4.1.3、第2层：服务层

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

在该层，服务器会解析查询并创建相应的内部解析树，并对其完成相应的优化：如确定查询表的顺序，是否利用索引等，最后生成相应的执行操作。

如果是SELECT语句，服务器还会查询内部的缓存。如果缓存空间足够大，这样在解决大量读操作的环境中能够很好的提升系统的性能。

SQL Interface: SQL接口
- 接收用户的SQL命令，并且返回用户需要查询的结果。比如SELECT … FROM就是调用SQLInterface
- MySQL支持DML（数据操作语言）、DDL（数据定义语言）、存储过程、视图、触发器、自定义函数等多种SQL语言接口
Parser: 解析器
- 在解析器中对SQL语句进行语法分析、语义分析。将SQL语句分解成数据结构，并将这个结构传递到后续步骤，以后SQL语句的传递和处理就是基于这个结构的。如果在分解构成中遇到错误，那么就说明这个SQL语句是不合理的。
- 在SQL命令传递到解析器的时候会被解析器验证和解析，并为其创建语法树，并根据数据字典丰富查询语法树，会验证该客户端是否具有执行该查询的权限。创建好语法树后，MySQL还会对SQl查询进行语法上的优化，进行查询重写。
Optimizer: 查询优化器
- SQL语句在语法解析之后、查询之前会使用查询优化器确定 SQL 语句的执行路径，生成一个执行计划。
- 这个执行计划表明应该使用哪些索引进行查询（全表检索还是使用索引检索），表之间的连接顺序如何，最后会按照执行计划中的步骤调用存储引擎提供的方法来真正的执行查询，并将查询结果返回给用户。
- 它使用选取-投影-连接策略进行查询。例如：
  1
  SELECT id,name FROM student WHERE gender = '男';
  这个SELECT查询先根据WHERE语句进行选取，而不是将表全部查询出来以后再进行gender过滤。这个SELECT查询先根据id和name进行属性投影，而不是将属性全部取出以后再进行过滤，将这两个查询条件连接起来生成最终查询结果。
Caches & Buffers：查询缓存组件
- MySQL内部维持着一些Cache和Buffer，比如Query Cache用来缓存一条SELECT语句的执行结果，如果能够在其中找到对应的查询结果，那么就不必再进行查询解析、优化和执行的整个过程了，直接将结果反馈给客户端。
- 这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等。
- 这个查询缓存可以在不同客户端之间共享。
- 从MySQL 5.7.20开始，不推荐使用查询缓存，并在MySQL 8.0中删除。

组件名	解释
`Management Serveices & Utilities`	系统管理和控制工具
`SQL Interface`	SQL 接口。接受用户的 SQL 命令，并且返回用户需要查询的结果。比如 select from 就是调用 SQL Interface。
`Parser`	SQL 解析器。SQL 命令传递到解析器的时候会被解析器验证和解析。
`Optimizer`	SQL 查询优化器。SQL 语句在查询之前会使用查询优化器对查询进行优化，比如有 where 条件时，优化器来决定先投影还是先过滤。
`Cache & Buffer`	SQL 查询缓存。如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据。这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key 缓存，权限缓存等

4.1.4、第 3 层：引擎层

和其它数据库相比，MySQL有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用，主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。同时开源的MySQL还允许开发人员设置自己的存储引擎。

这种高效的模块化架构为那些希望专门针对特定应用程序需求（例如数据仓库、事务处理或高可用性情况）的人提供了巨大的好处，同时享受使用一组独立于任何接口和服务的优势存储引擎。

插件式存储引擎层（Storage Engines),真正的负责了MySQLI中数的存储和提取，对物理服务器级别维护的底层数据执行操作，服务器通过AP与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取。

MySQL 8.0.29默认支持的存储引擎如下：

4.1.5、存储层

所有的数据，数据库、表的定义，表的每一行的内容，索引，都是存在文件系统上，以文件的方式存在的，并完成与存储引擎的交互。当然有些存储引擎比如InnoDB,也支持不使用文件系统直接管理裸设备，但现代文件系统的实现使得这样做没有必要了。在文件系统之下，可以使用本地磁盘，可以使用DAS、NAS、SAN等各种存储系统。

4. 1.6、小结

MySQL架构图本节开篇所示。下面为了熟悉SQL执行流程方便，我们可以简化如下：

简化为三层结构：

连接层：客户端和服务器端建立连接，客户端发送 SQL 至服务器端；
SQL 层（服务层）：对 SQL 语句进行查询处理；与数据库文件的存储方式无关；
存储引擎层：与数据库文件打交道，负责数据的存储和读取。
4.2. SQL执行流程

4.2.1 MySQL 中的 SQL执行流程

MySQL执行流程

MySQL的查询流程：

查询缓存 ：Server 如果在查询缓存中发现了这条 SQL 语句，就会直接将结果返回给客户端；如果没有，就进入到解析器阶段。需要说明的是，因为查询缓存往往效率不高，所以在 MySQL8.0 之后就抛弃了这个功能。

MySQL拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以key-value对的形式，被直接缓存在内存中。key是查询的语句，value是查询的结果。如果你的查询能够直接在这个缓存中找到key,那么这个value就会被直接返回给客户端。如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。所以，如果查询命中缓存，MySQL不需要执行后面的复杂操作，就可以直接返回结果，这个效率会很高。

大多数情况查询缓存就是个鸡肋，为什么呢？

查询缓存是提前把查询结果缓存起来，这样下次不需要执行就可以直接拿到结果。需要说明的是，在MySQL 中的查询缓存，不是缓存查询计划，而是查询对应的结果。这就意味着查询匹配的鲁棒性大大降低，只有相同的查询操作才会命中查询缓存。两个查询请求在任何字符上的不同（例如：空格、注释、大小写），都会导致缓存不会命中。因此 MySQL 的查询缓存命中率不高。

同时，如果查询请求中包含某些系统函数、用户自定义变量和函数、一些系统表，如 mysql 、information_schema、 performance_schema 数据库中的表，那这个请求就不会被缓存。以某些系统函数举例，可能同样的函数的两次调用会产生不一样的结果，比如函数NOW，每次调用都会产生最新的当前时间，如果在一个查询请求中调用了这个函数，那即使查询请求的文本信息都一样，那不同时间的两次查询也应该得到不同的结果，如果在第一次查询时就缓存了，那第二次查询的时候直接使用第一次查询的结果就是错误的！

此外，既然是缓存，那就有它缓存失效的时候。MySQL的缓存系统会监测涉及到的每张表，只要该表的结构或者数据被修改，如对该表使用了INSERT、 UPDATE、DELETE、TRUNCATE TABLE、ALTER TABLE、DROP TABLE或 DROP DATABASE语句，那使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除！对于更新压力大的数据库来说，查询缓存的命中率会非常低。

总之，因为查询缓存往往弊大于利，查询缓存的失效非常频繁。

一般建议大家在静态表里使用查询缓存，什么叫静态表呢？就是一般我们极少更新的表。比如，一个系统配置表、字典表，这张表上的查询才适合使用查询缓存。好在MySQL也提供了这种“按需使用”的方式。你可以将my.cnf参数query_cache_type设置成DEMAND,代表当sql语句中有SQL_CACHE关键词时才缓存。比如：

1 2	`#query_cache_type有3个值 0代表关闭查询缓存OFF,1代表开启ON,2(DEMAND) query_cache_type=2`

这样对于默认的SQL语句都不使用查询缓存。而对于你确定要使用查询缓存的语句，可以用SQL_CACHE显式指定，像下面这个语句一样：

1	`select SQL_CACHE from test where ID=5`

查看当前mysq实例是否开启缓存机制

# MySQL5.7中
mysql> show variables like 'query_cache_type';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| query_cache_type | OFF   |
+------------------+-------+

# MySQL8.0中
mysql> show global variables like 'query_cache_type';
Empty set (0.00 sec)

监控查询缓存的命中率(MySQL 5.7)：

mysql> show status like '%Qcache%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| Qcache_free_blocks      | 1       |
| Qcache_free_memory      | 1031832 |
| Qcache_hits             | 0       |
| Qcache_inserts          | 0       |
| Qcache_lowmem_prunes    | 0       |
| Qcache_not_cached       | 1       |
| Qcache_queries_in_cache | 0       |
| Qcache_total_blocks     | 1       |
+-------------------------+---------+

Qcache_free_blocks:表示查询缓存中还有多少剩余的blocks,如果该值显示较大，则说明查询缓存中的内存碎片过多了，可能在一定的时间进行整理。
Qcache_free_memory:查询缓存的内存大小，通过这个参数可以很清晰的知道当前系统的查询内存是否够用，是多了，还是不够用，DBA可以根据实际情况做出调整。
Qcache_hits:表示有多少次命中缓存。我们主要可以通过该值来验证我们的查询缓存的效果。数字越大，缓存效果越理想。
Qcache_inserts:表示多少次未命中然后插入，意思是新来的SQL请求在缓存中未找到，不得不执行查询处理执行查询处理后把结果insert?到查询缓存中。这样的情况的次数越多，表示查询缓存应用到的比较少，效果也就不理想。当然系统刚启动后，查询缓存是空的，这很正常。
Qcache_lowmem_prunes:该参数记录有多少条查询因为内存不足而被移除出查询缓存。通过这个值，用户可以适
当的调整缓存大小。
Qcache_not_cached:表示因为query_cache_type的设置而没有被缓存的查询数量。
Qcache_queries_in_cache:当前缓存中缓存的查询数量。
Qcache_total_blocks:当前缓存的block数量。

解析器 ：在解析器中对 SQL 语句进行语法分析、语义分析。

如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL需要知道你要做什么，因此需要对SQL语句做解析。SQL语句的分析分为词法分析与语法分析。

分析器先做“词法分析”。你输入的是由多个字符串和空格组成的一条SQL语句，MySQL需要识别出里面的字符串分别是什么，代表什么。

MySQL从你输入的”select”这个关键字识别出来，这是一个查询语句。它也要把字符串“T”识别成“表名T”,把字符串“ID”识别成“列ID”。

接着，要做“语法分析”。根据词法分析的结果，语法分析器（比如：Biso)会根据语法规则，判断你输入的这个SQL语句是否满足MySQL语法

如果你的语句不对，就会收到“You have an error in your SQL syntax’”的错误提醒，比如下面这个语句from写成了”rom”。

#语句：
select fro test where id=1;

#错误：
ERROR 1064 (42000):You have an error in your SQL syntax;check the manual that corresponds to
your MySQL server version for the right syntax to use near fro test where id=1'at line 1

如果SQL语句正确，则会生成一个这样的语法树：

MySQL语法树

下图是SQL词法分析的步骤过程

词法分析过程

至此我们解析器的工作任务也基本圆满了。接下来进入到优化器。

优化器：在优化器中会确定SQL语句的执行路径，比如是根据全表检索，还是根据索引检索等。

经过了解析器，MySQL就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。一条查询可以有很多种执行方式，最后都返回相同的结果。优化器的作用就是找到这其中最好的执行计划。

比如：优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（心oi)的时候，决定各个表的连接顺序，还有表达式简化、子查询转为连接、外连接转为内连接等。

举例：如下语句是执行两个表的join:
1
select from test1 join test2 using(ID) where test1.name='zhangwei'and test2.name='mysql高级课程';
方案1：可以先从表test1里面取出name=’zhangwei’的记录的ID值，再根据ID值关联到表test2,再判断test2里面name的值是否等于’mysql高级课程’。

方案2：可以先从表test2里面取出name=’mysq1高级课程’的记录的ID值，再根据ID值关联到test1,再判断test1里面name的值是否等于zhangwei。

这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。优化器阶段后，这个语句的执行方案就确定下来了，然后进入执行器阶段。

如果你还有一些疑问，比如优化器是怎么选择索引的，有没有可能选择错等。后面讲到索引我们再谈

在查询优化器中，可以分为逻辑查询优化阶段和物理查询优化阶段。

逻辑查询优化就是通过改变SQL语句的内容来使得SQL查询更高效，同时为物理查询优化提供更多的候选执行计划。通常采用的方式是对SQL语句进行等价变换，对查询进行重写，而查询重写的数学基础就是关系代数。对条件表达式进行等价谓词重写、条件简化，对视图进行重写，对子查询进行优化，对连接语义进行了外连接消除、嵌套连接消除等。

物理查询优化是基于关系代数进行的查询重写，而关系代数的每一步都对应着物理计算，这些物理计算往往存在多种算法，因此需要计算各种物理路径的代价，从中选择代价最小的作为执行计划。在这个阶段里，对于单表和多表连接的操作，需要高效地使用索引，提升查询效率。
执行器：截止到现在，还没有真正去读写真实的表，仅仅只是产出了一个执行计划。于是就进入了执行器阶段。

在执行之前需要判断该用户是否具备权限。如果没有，就会返回权限错误。如果具备权限，就执行SQL查询并返回结果。在MySQL8.0以下的版本，如果设置了查询缓存，这时会将查询结果进行缓存。
1
select * from test where id = 1;
如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，调用存储引擎API对表进行的读写。存储引擎API只是抽象接口，下面还有个存储引擎层，具体实现还是要看表选择的存储引擎。

至此，这个语句就执行完成了。对于有索引的表，执行的逻辑也差不多。

SQL 语句在 MySQL 中的流程是： SQL语句→查询缓存→解析器→优化器→执行器 。

4.2.2、MySQL 8 中SQL执行原理

既然一条SQL语句会经历不同的模块，那我们就来看下，在不同的模块中，SQL执行所使用的资源（时间）是怎样的。如何在MySQL中对一条SQL语句的执行时间进行分析。

4.2.2.1、确认profiling 是否开启

了解查询语句底层执行的过程：select @@profiling;或者show variables like'%profiling%';查看是否开启计划。开启它可以让MySQL收集在SQL执行时所使用的资源情况，命令如下：

mysql> select @@profiling;
+-------------+
| @@profiling |
+-------------+
|           0 |
+-------------+

mysql> show variables like'%profiling%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| have_profiling         | YES   |
| profiling              | OFF   |
| profiling_history_size | 15    |
+------------------------+-------+

profiling=0 代表关闭，我们需要把profiling打开，即设置为1：

1	`set profiling = 1;`

Profiling功能由MySQL会话变量：profiling控制。默认是OFF(关闭状态)

4.2.2.2、多次执行相同SQL查询

然后我们执行一个 SQL 查询（你可以执行任何一个 SQL 查询）

4.2.2.3、查看profiles

查看当前会话所产生的所有 profiles：

1	`mysql> select @@profiling;`

1	`mysql> show variables like 'profiling';`

1	`mysql> set profiling= 1 ;`

1	`mysql> select * from employees;`

# 显示最近的几次查询
mysql> show profiles;
+----------+------------+-------------------------+
| Query_ID | Duration   | Query                   |
+----------+------------+-------------------------+
|        1 | 0.00014425 | set profiling = 1       |
|        2 | 0.00029300 | select @@profiling      |
|        3 | 0.00109900 | show databases          |
|        4 | 0.00022225 | SELECT DATABASE()       |
|        5 | 0.00103175 | show databases          |
|        6 | 0.00198500 | show tables             |
|        7 | 0.00133275 | show tables             |
|        8 | 0.00063225 | select * from employees |
|        9 | 0.00043325 | select * from employees |
|       10 | 0.00039050 | select * from employees |
|       11 | 0.00052025 | select * from employees |
+----------+------------+-------------------------+

# 默认查询最后一次的执行过程(show profiles返回的Query_ID为11)
mysql> show profile;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000074 |
| Executing hook on transaction  | 0.000005 |
| starting                       | 0.000008 |
| checking permissions           | 0.000007 |
| Opening tables                 | 0.000039 |
| init                           | 0.000006 |
| System lock                    | 0.000009 |
| optimizing                     | 0.000004 |
| statistics                     | 0.000018 |
| preparing                      | 0.000017 |
| executing                      | 0.000243 |
| end                            | 0.000008 |
| query end                      | 0.000004 |
| waiting for handler commit     | 0.000009 |
| closing tables                 | 0.000009 |
| freeing items                  | 0.000050 |
| cleaning up                    | 0.000013 |
+--------------------------------+----------+

# 查询Query_ID为8的执行过程
mysql> show profile for query 8;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000094 |
| Executing hook on transaction  | 0.000008 |
| starting                       | 0.000010 |
| checking permissions           | 0.000008 |
| Opening tables                 | 0.000127 |
| init                           | 0.000011 |
| System lock                    | 0.000010 |
| optimizing                     | 0.000005 |
| statistics                     | 0.000024 |
| preparing                      | 0.000021 |
| executing                      | 0.000217 |
| end                            | 0.000005 |
| query end                      | 0.000004 |
| waiting for handler commit     | 0.000009 |
| closing tables                 | 0.000008 |
| freeing items                  | 0.000052 |
| cleaning up                    | 0.000021 |
+--------------------------------+----------+

4.2.2.4、查看profile

显示执行计划，查看程序的执行步骤：

1 2	`# 查看全部的执行计划 mysql> show profiles;`

1 2	`# 查看最近一次的执行计划 mysql> show profile;`

当然你也可以查询指定的 Query_ID，比如：

mysql> show profile for query 13;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000078 |
| Executing hook on transaction  | 0.000045 |
| starting                       | 0.000014 |
| checking permissions           | 0.000008 |
| Opening tables                 | 0.000051 |
| init                           | 0.000008 |
| System lock                    | 0.000011 |
| optimizing                     | 0.000004 |
| statistics                     | 0.000022 |
| preparing                      | 0.000029 |
| executing                      | 0.000246 |
| end                            | 0.000007 |
| query end                      | 0.000004 |
| waiting for handler commit     | 0.000011 |
| closing tables                 | 0.000011 |
| freeing items                  | 0.000059 |
| cleaning up                    | 0.000015 |
+--------------------------------+----------+

查询 SQL 的执行时间结果和上面是一样的。

此外，还可以查询更丰富的内容：

1	`mysql> show profile cpu,block io for query 13;`

继续：

1	`mysql> show profile cpu,block io for query 11;`

除了查看cpu、io阻塞等参数情况，还可以查询下列参数的利用情况。

Syntax:
SHOW PROFILE [type [, type] ... ]
	[FOR QUERY n]
	[LIMIT row_count [OFFSET offset]]

type: {
	| ALL -- 显示所有参数的开销信息
	| BLOCK IO -- 显示IO的相关开销
	| CONTEXT SWITCHES -- 上下文切换相关开销
	| CPU -- 显示CPU相关开销信息
	| IPC -- 显示发送和接收相关开销信息
	| MEMORY -- 显示内存相关开销信息
	| PAGE FAULTS -- 显示页面错误相关开销信息
	| SOURCE -- 显示和Source_function,Source_file,Source_line 相关的开销信息
	| SWAPS -- 显示交换次数相关的开销信息
}

发现两次查询当前情况都一致，说明没有缓存。

在 8.0 版本之后，MySQL 不再支持缓存的查询。一旦数据表有更新，缓存都将清空，因此只有数据表是静态的时候，或者数据表很少发生变化时，使用缓存查询才有价值，否则如果数据表经常更新，反而增加了 SQL 的查询时间。

4.2.3、MySQL 5. 7 中SQL执行原理

上述操作在MySQL5.7中测试，发现前后两次相同的sql语句，执行的查询过程仍然是相同的。不是会使用缓存吗？这里我们需要显式开启查询缓存模式。在MySQL5.7中如下设置：

4.2.3.1、配置文件中开启查询缓存

在/etc/my.cnf 中新增一行：

1	`query_cache_type = 1`

注意：

同样的开启缓存的配置信息如果在MySQL8中添加。重启服务时会报错：

vim /etc/my.cnf
systemctl restart mysqld;
# 错误提示
Job for mysqld.service failed because the control process exited with error code.See "systemctl status mysqld.service"and "journalctl -xe"for details.

4.2.3.2、重启mysql服务

1	`systemctl restart mysqld`

4.2.3.3、开启查询执行计划

由于重启过服务，需要重新执行如下指令，开启profiling

1	`mysql> set profiling = 1;`

4.2.3.4、执行语句两次：

1	`mysql> select * from locations;`

4.2.3.5、查看profiles

4.2.3.6、查看profile

显示执行计划，查看程序的执行步骤：

1	`mysql> show profile for query 1;`

1	`mysql> show profile for query 2;`

结论不言而喻。执行编号 2 时，比执行编号 1 时少了很多信息，从截图中可以看出查询语句直接从缓存中获取数据。

4.2.4、SQL语法顺序

随着MySQL版本的更新换代，其优化器也在不断的升级，优化器会分析不同执行顺序产生的性能消耗不同而动态调整执行顺序。

4.2.5、Oracle中的SQL执行流程(了解)

Oracle中采用了共享池来判断 SQL 语句是否存在缓存和执行计划，通过这一步骤我们可以知道应该采用硬解析还是软解析。

我们先来看下 SQL在 Oracle中的执行过程：

Oracle执行过程

从上面这张图中可以看出，SQL 语句在 Oracle 中经历了以下的几个步骤。

语法检查： 检查 SQL 拼写是否正确，如果不正确，Oracle 会报语法错误。
语义检查： 检查 SQL 中的访问对象是否存在。比如我们在写 SELECT 语句的时候，列名写错了，系统就会提示错误。语法检查和语义检查的作用是保证 SQL 语句没有错误。
权限检查： 看用户是否具备访问该数据的权限。
共享池检查： 共享池（Shared Pool）是一块内存池， 最主要的作用是缓存 SQL 语句和该语句的执行计划。Oracle 通过检查共享池是否存在SQL语句的执行计划，来判断进行软解析，还是硬解析。那软解析和硬解析又该怎么理解呢？

在共享池中，Oracle首先对SQL语句进行Hash运算，然后根据Hash值在库缓存（Library Cache）中查找，如果存在SQL语句的执行计划，就直接拿来执行，直接进入“执行器”的环节，这就是软解析。

如果没有找到 SQL 语句和执行计划，Oracle 就需要创建解析树进行解析，生成执行计划，进入“优化器”这个步骤，这就是硬解析。
优化器：优化器中就是要进行硬解析，也就是决定怎么做，比如创建解析树，生成执行计划。
执行器：当有了解析树和执行计划之后，就知道了 SQL 该怎么被执行，这样就可以在执行器中执行语句了。

共享池是 Oracle 中的术语，包括了库缓存，数据字典缓冲区等。我们上面已经讲到了库缓存区，它主要缓存 SQL 语句和执行计划。而数据字典缓冲区存储的是 Oracle 中的对象定义，比如表、视图、索引等对象。当对 SQL 语句进行解析的时候，如果需要相关的数据，会从数据字典缓冲区中提取。

库缓存这一个步骤，决定了 SQL 语句是否需要进行硬解析。为了提升 SQL 的执行效率，我们应该尽量避免硬解析，因为在 SQL 的执行过程中，创建解析树，生成执行计划是很消耗资源的。

你可能会问，如何避免硬解析，尽量使用软解析呢？在 Oracle 中，绑定变量是它的一大特色。绑定变量就是在 SQL 语句中使用变量，通过不同的变量取值来改变 SQL 的执行结果。这样做的好处是能提升软解析的可能性，不足之处在于可能会导致生成的执行计划不够优化，因此是否需要绑定变量还需要视情况而定。

举个例子，我们可以使用下面的查询语句：

1	`SQL> select * from player where player_id = 10001 ;`

你也可以使用绑定变量，如：

1	`SQL> select * from player where player_id = :player_id;`

这两个查询语句的效率在 Oracle 中是完全不同的。如果你在查询 player_id = 10001 之后，还会查询10002 、 10003 之类的数据，那么每一次查询都会创建一个新的查询解析。而第二种方式使用了绑定变量，那么在第一次查询之后，在共享池中就会存在这类查询的执行计划，也就是软解析。

因此， 我们可以通过使用绑定变量来减少硬解析，减少 Oracle 的解析工作量。 但是这种方式也有缺点，使用动态 SQL 的方式，因为参数不同，会导致 SQL 的执行效率不同，同时 SQL 优化也会比较困难。

Oracle的架构图：

Oracle架构图

简图：

Oracle简图

小结：

Oracle 和 MySQL 在进行 SQL 的查询上面有软件实现层面的差异。Oracle 提出了共享池的概念，通过共享池来判断是进行软解析，还是硬解析。

4.3、数据库缓冲池(Buffer Pool)

InnoDB存储引擎是以页为单位来管理存储空间的，我们进行的增删改查操作其实本质上都是在访问页面（包括读页面、写页面、创建新页面等操作）。而磁盘 I/O 需要消耗的时间很多，而在内存中进行操作，效率则会高很多，为了能让数据表或者索引中的数据随时被我们所用，DBMS会申请占用内存来作为数据缓冲池，在真正访问页面之前，需要把在磁盘上的页缓存到内存中的Buffer Pool之后才可以访问。

这样做的好处是可以让磁盘活动最小化，从而减少与磁盘直接进行I/O的时间。要知道，这种策略对提升SQL语句的查询性能来说至关重要。如果索引的数据在缓冲池里，那么访问的成本就会降低很多。

4.3.1、缓冲池 vs 查询缓存

4.3.1.1、缓冲池（Buffer Pool）

首先我们需要了解在 InnoDB 存储引擎中，缓冲池都包括了哪些。

在 InnoDB 存储引擎中有一部分数据会放到内存中，缓冲池则占了这部分内存的大部分，它用来存储各种
数据的缓存，如下图所示：

从图中，你能看到 InnoDB 缓冲池包括了数据页、索引页、插入缓冲、锁信息、自适应 Hash 和数据字典信息等。

缓存池的重要性：

对于使用InnoDB作为存储引擎的表来说，不管是用于存储用户数据的索引（包括聚簇索引和二级索引），还是各种系统数据，都是以页的形式存放在表空间中的，而所谓的表空间只不过是InnoDB对文件系统上一个或几个实际文件的抽象，也就是说我们的数据说到底还是存储在磁盘上的。但是各位也都知道，磁盘的速度慢的跟乌龟一样，怎么能配得上“快如风，疾如电"的CPU呢？这里，缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟。所以InnoDB存储引擎在处理客户端的请求时，当需要访问某个页的数据时，就会把完整的页的数据全部加载到内存中，也就是说即使我们只需要访问一个页的一条记录，那也需要先把整个页的数据加载到内存中。将整个页加载到内存中后就可以进行读写访问了，在进行完读写访问之后并不着急把该页对应的内存空间释放掉，而是将其缓存起来，这样将来有请求再次访问该页面时，就可以省去磁盘IO的开销了。

缓存原则：

“ 位置 * 频次 ”这个原则，可以帮我们对 I/O 访问效率进行优化。

首先，位置决定效率，提供缓冲池就是为了在内存中可以直接访问数据。

其次，频次决定优先级顺序。因为缓冲池的大小是有限的，比如磁盘有200G，但是内存只有16G，缓冲池大小只有1G，就无法将所有数据都加载到缓冲池里，这时就涉及到优先级顺序，会优先对使用频次高的热数据进行加载 。

缓冲池的预读特性:

了解了缓冲池的作用之后，我们还需要了解缓冲池的另一个特性：预读。

缓冲池的作用就是提升 I/O 效率，而我们进行读取数据的时候存在一个“局部性原理”，也就是说我们使用了一些数据，大概率还会使用它周围的一些数据，因此采用“预读”的机制提前加载，可以减少未来可能的磁盘 I/O 操作。

4.3.1.2、查询缓存

那么什么是查询缓存呢？

查询缓存是提前把查询结果缓存起来，这样下次不需要执行就可以直接拿到结果。需要说明的是，在MySQL中的查询缓存，不是缓存查询计划，而是查询对应的结果。因为命中条件苛刻，而且只要数据表发生变化，查询缓存就会失效，因此命中率低。

缓冲池服务于数据库整体的/O操作，它们的共同点都是通过缓存的机制来提升效率。

4.3.2、缓冲池如何读取数据

缓冲池管理器会尽量将经常使用的数据保存起来，在数据库进行页面读操作的时候，首先会判断该页面是否在缓冲池中，如果存在就直接读取，如果不存在，就会通过内存或磁盘将页面存放到缓冲池中再进行读取。

缓存在数据库中的结构和作用如下图所示：

如果我们执行 SQL 语句的时候更新了缓存池中的数据，那么这些数据会马上同步到磁盘上吗？

实际上，当我们对数据库中的记录进行修改的时候，首先会修改缓冲池中页里面的记录信息，然后数据库会以一定的频率刷新到磁盘中。注意并不是每次发生更新操作，都会立即进行磁盘回写。缓冲池会采用一种叫做 checkpoint 的机制 将数据回写到磁盘上，这样做的好处就是提升了数据库的整体性能。

比如，当缓冲池不够用时，需要释放掉一些不常用的页，此时就可以强行采用checkpoint的方式，将不常用的脏页回写到磁盘上，然后再从缓存池中将这些页释放掉。这里的脏页 (dirty page) 指的是缓冲池中被修改过的页，与磁盘上的数据页不一致。

4.3.3、查看/设置缓冲池的大小

如果你使用的是 MySQL MyISAM 存储引擎，它只缓存索引，不缓存数据，对应的键缓存参数为key_buffer_size，你可以用它进行查看。

如果你使用的是 InnoDB 存储引擎，可以通过查看 innodb_buffer_pool_size 变量来查看缓冲池的大小。命令如下：

show variables like 'innodb_buffer_pool_size';

+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+

你能看到此时 InnoDB 的缓冲池大小只有134217728/1024/1024=128MB。我们可以修改缓冲池大小，比如改为256MB，方法如下：

1	`set global innodb_buffer_pool_size = 268435456;`

或者：

1 2	`[server] innodb_buffer_pool_size = 268435456`

4.3.4、多个Buffer Pool实例

Buffer Poolz本质是:InnoDBI向操作系统申请的一块连续的内存空间，在多线程环境下，访问Buffer Pool中的数据都需要加锁处理。在Buffer Pool特别大而且多线程并发访问特别高的情况下，单一的Buffer Pooli可能会影响请求的处理速度。所以在Buffer Pool特别大的时候，我们可以把它们拆分成若千个小的Buffer Pool,每个Buffer Pool都称为一个实例，它们都是独立的，独立的去申请内存空间，独立的管理各种链表。所以在多线程并发访问时并不会相互影响，从而提高并发处理能力。

我们可以在服务器启动的时候通过设置innodb_buffer_pool_instances的值来修改Buffer Pool3实例的个数，比方说这样：

1 2	`[server] innodb_buffer_pool_instances = 2`

这样就表明我们要创建2个 Buffer Pool 实例。

我们看下如何查看缓冲池的个数，使用命令：

show variables like 'innodb_buffer_pool_instances';

+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| innodb_buffer_pool_instances | 1     |
+------------------------------+-------+

那每个Buffer Pool实例实际占多少内存空间呢？其实使用这个公式算出来的：

1	`innodb_buffer_pool_size/innodb_buffer_pool_instances`

也就是总共的大小除以实例的个数，结果就是每个Buffer Pool实例占用的大小。

不过也不是说 Buffer Pool 实例创建的越多越好，分别管理各个Buffer Pool也是需要性能开销的，InnDB规定：当innodb_buffer_pool_size的值小于1G的时候设置多个实例是无效的，InnoDB会默认把innodb_buffer_pool_instances的值修改为1。而我们鼓励在 Buffer Pool 大于等于1G的时候设置多个 Buffer Pool 实例。

4.3.5、引申问题

Buffer Pool是MySQL内存结构中十分核心的一个组成，你可以先把它想象成一个黑盒子。

黑盒下的更新数据流程

当我们查询数据的时候，会先去 Buffer Pool 中查询。如果 Buffer Pool 中不存在，存储引擎会先将数据从磁盘加载到 Buffer Pool 中，然后将数据返回给客户端；同理，当我们更新某个数据的时候，如果这个数据不存在于 Buffer Pool，同样会先数据加载进来，然后修改内存的数据。被修改的数据会在之后统一刷入磁盘。

这个过程看似没啥问题，实则是有问题的。假设我们修改Buffer Pool中的数据成功，但是还没来得及将数据刷入磁盘MySQL就挂了怎么办？按照上图的逻辑，此时更新之后的数据只存在于Buffer Pool中，如果此时MySQL宕机了，这部分数据将会永久地丢失；

再者，我更新到一半突然发生错误了，想要回滚到更新之前的版本，该怎么办？连数据持久化的保证、事务回滚都做不到还谈什么崩溃恢复？

答案：Redo Log & Undo Log

5、存储引擎

为了管理方便，人们把连接管理、查询缓存、语法解析、查询优化这些并不涉及真实数据存储的功能划分为MySQL Server的功能，把真实存取数据的功能划分为存储引擎的功能。所以在MySQL Server完成了查询优化后，只需按照生成的执行计划调用底层存储引擎提供的AP1,获取到数据后返回给客户端就好了。

MySQL中提到了存储引擎的概念。简而言之，存储引擎就是指表的类型。其实存储引擎以前叫做表处理器，后来改名为存储引擎，它的功能就是接收上层传下来的指令，然后对表中的数据进行提取或写入操作。

5.1、查看存储引擎

查看MYSQL提供了什么存储引擎
1
show engines;
查询结果显示，MySQL8支持9种存储引擎，分别为MEMORY、MRG_MYISAM、CSV、FEDERATED、PERFORMANCE_SCHEMA、MyISAM、InnoDB、BLACKHOLE和ARCHIVE。
- Engine参数表示存储引擎名称。
- Support参数表示MySQL数据库管理系统是否支持该存储引擎：YES表示支持，NO表示不支持。
- DEFAULT表示系统默认支持的存储引擎。
- Comment参数表示对存储引擎的评论。
- Transactions参数表示存储引擎是否支持事务：YES表示支持，NO表示不支持。
- XA参数表示存储引擎所支持的分布式是否符合XA规范：YES表示支持，NO表示不支持。代表着该存储引擎是否支持分布式事务。
- Savepoints参数表示存储引擎是否支持事务处理的保存点：YES表示支持，NO表示不支持。也就是说，该存储引擎是否支持部分事务回滚。
1
show engines \G;

5.2、设置系统默认存储引擎

查看默认的存储引擎

1
2
3

show variables like '%storage_engine%';
#或
SELECT @@default_storage_engine;

修改默认的存储引擎

如果在创建表的语句中没有显式指定表的存储引擎的话，那就会默认使用 InnoDB 为表的存储引擎。如果我们想改变表的默认存储引擎的话，可以这样写启动服务器的命令行：
1
SET DEFAULT_STORAGE_ENGINE=MyISAM;
或者修改my.cnf文件：
1
2
3
default-storage-engine=MyISAM # 重启服务 systemctl restart mysqld.service

5.3、设置表的存储引擎

存储引擎是负责对表中的数据进行提取和写入工作的，我们可以为不同的表设置不同的存储引擎 ，也就是说不同的表可以有不同的物理存储结构，不同的提取和写入方式。

5.3.1、创建表时指定存储引擎

我们之前创建表的语句都没有指定表的存储引擎，那就会使用默认的存储引擎 InnoDB 。如果我们想显式的指定一下表的存储引擎，那可以这么写：

1 2	`mysql> CREATE TABLE engine_demo_table(i int)ENGINE MyISAM; Query OK,0 rows affected (0.02 sec)`

5.3.2、修改表的存储引擎

如果表已经建好了，我们也可以使用下边这个语句来修改表的存储引擎：

1	`ALTER TABLE 表名 ENGINE = 存储引擎名称；`

比如我们修改一下engine_demo_table表的存储引擎：

1
2
3

mysql> ALTER TABLE engine_demo_table ENGINE InnoDB;
Query OK,0 rows affected (0.05 sec)
Records:0 Duplicates:0 Warnings:0

这时我们再查看一下engine_demo_table的表结构：

mysql> SHOW CREATE TABLE engine_demo_table \G;
*************************** 1. row ***************************
       Table: engine_demo_table
Create Table: CREATE TABLE `engine_demo_table` (
  `i` int DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci
1 row in set (0.00 sec)

可以看到该表的存储引擎已经改为InnoDB了。

5.4、引擎介绍

5.4.1、InnoDB 引擎：具备外键支持功能的事务存储引擎

MySQL从3.23.34a开始就包含InnoDB存储引擎。 大于等于5.5之后，默认采用InnoDB引擎 。
InnoDB是MySQL的默认事务型引擎，它被设计用来处理大量的短期(short-lived)事务。可以确保事务的完整提交(Commit)和回滚(Rollback)。
除了增加和查询外，还需要更新、删除操作，那么，应优先选择InnoDB存储引擎。
除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑InnoDB引擎。
数据文件结构：
- 表名.frm存储表结构（MySQL8.0时，合并在表名.ibd中）
- 表名.ibd存储数据和索引
InnoDB是为处理巨大数据量的最大性能设计
- 在以前的版本中，字典数据以元数据文件、非事务表等来存储。现在这些元数据文件被删除了。比如：.frm， .par，.trn，.isl，.db.opt等都在MySQL8.0中不存在了。
对比MyISAM的存储引擎，InnoDB写的处理效率差一些，并且会占用更多的磁盘空间以保存数据和索引。
MyISAM只缓存索引，不缓存真实数据；InnoDB不仅缓存索引还要缓存真实数据，对内存要求较高，而且内存大小对性能有决定性的影响。

5.4.2、MyISAM 引擎：主要的非事务处理存储引擎

MyISAM提供了大量的特性，包括全文索引、压缩、空间函数(GIS)等，但MyISAM不支持事务、行级锁、外键 ，有一个毫无疑问的缺陷就是崩溃后无法安全恢复 。
5.5之前默认的存储引擎
优势是访问的速度快，对事务完整性没有要求或者以SELECT、INSERT为主的应用
针对数据统计有额外的常数存储。故而 count(*) 的查询效率很高数据文件结构：
- 表名.frm 存储表结构
- 表名.MYD存储数据 (MYData)
- 表名.MYI存储索引 (MYIndex)
应用场景：只读应用或者以读为主的业务

5.4.3、Archive引擎：用于数据存档

archive是归档的意思，仅仅支持插入和查询两种功能（行被插入后不能再修改）
在MySQL5.5以后支持索引功能
拥有很好的压缩机制，使用zlib压缩库，在记录请求的时候实时的进行压缩，经常被用来作为仓库使用
创建ARCHIVE表时，存储擎会创建名称以表名开头的文件。数据文件的扩展名为.ARZ
根据英文的测试结论来看，同样数据量下，Archive表比MyISAM表要小大约75%，比支持事务处理的InnoDB表小大约83%
ARCHIVE存储引擎采用了行级锁。该ARCHIVE引擎支持AUTO_INCREMENT列属性。AUTO_INCREMENT列可以具有唯一索引或非唯一索引。尝试在任何其他列上创建索引会导致错误
Archive表适合日志和数据采集（档案）类应用；适合存储大量的独立的作为历史记录的数据。拥有很高的插入速度，但是对查询的支持较差
下表展示了ARCHIVE 存储引擎功能

特征	支持
B树索引	不支持
`备份/时间点恢复`(在服务器中实现，而不是在存储引擎中)	支持
集群数据库支持	不支持
聚集索引	不支持
`压缩数据`	支持
数据缓存	不支持
加密数据（加密功能在服务器中实现）	支持
外键支持	不支持
全文检索索引	不支持
地理空间数据类型支持	支持
地理空间索引支持	不支持
哈希索引	不支持
索引缓存	不支持
`锁粒度`	行锁
MVCC	不支持
存储限制	没有任何限制
交易	不支持
`更新数据字典的统计信息`	支持

4.4.4、Blackhole引擎：丢弃写操作，读操作会返回空内容

Blackhole引擎没有实现任何存储机制，它会丢弃所有插入的数据，不做任何保存。
但服务器会记录Blackhole表的日志，所以可以用于复制数据到备库，或者简单地记录到日志。但这种应用方式会碰到很多问题，因此并不推荐。

4.4.5、CSV 引擎：存储数据时，以逗号分隔各个数据项

CSV引擎可以将普通的CSV文件作为MySQL的表来处理，但不支持索引
CSV引擎可以作为一种数据交换的机制，非常有用
CSV存储的数据直接可以在操作系统里，用文本编辑器，或者excel读取。
对于数据的快速导入、导出是有明显优势的。

创建CSV表时，服务器会创建一个纯文本数据文件，其名称以表名开头并带有.CSV扩展名。当你将数据存储到表中时，存储引擎将其以逗号分隔值格式保存到数据文件中。

使用案例如下:

CREATE TABLE test (id INT NOT NULL,c CHAR(10) NOT NULL) ENGINE = CSV;

INSERT INTO test VALUES(1, 'record one'),(2, 'record two');

mysql> select * from test;
+----+------------+
| id | c          |
+----+------------+
|  1 | record one |
|  2 | record two |
+----+------------+

创建CSV表还会创建相应的元文件，用于存储表的状态和表中存在的行数。此文件的名称与表的名称相同，后缀
为CSM。如图所示：

1
2
3

[root@mysql150 test_db]# cat test.CSV
1,"record one"
2,"record two"

5.4.6、Memory引擎：置于内存的表

概述：

Memory采用的逻辑介质是内存，响应速度很快，但是当mysqld守护进程崩溃的时候数据会丢失。另外，要求存储的数据是数据长度不变的格式，比如，Blob和Txt类型的数据不可用（长度不固定的）

主要特征：

Memoryl同时支持哈希(HASH)索引和B+树索引。
- 哈希索引相等的比较快，但是对于范围的比较慢很多
- 默认使用哈希(HASH)索引，其速度要比使用B型树(BTREE)索引快
- 如果希望使用B树索引，可以在创建索引时选择使用。
Memory表至少比MyISAM表要快一个数量级
MEMORY表的大小是受到限制的，表的大小主要取决于两个参数，分别是max_rows和max_heap_table_size。其中，max_rows可以在创建表时指定；max_heap_.table_size的大小默认为16MB,可以按需要进行扩大。
数据文件与索引文件分开存储
- 每个基于MEMORY存储引擎的表实际对应一个磁盘文件，该文件的文件名与表名相同，类型为frm类型，该文件中只存储表的结构，而其数据文件都是存储在内存中的
- 这样有利于数据的快速处理，提供整个表的处理效率。
缺点：其数据易丢失，生命周期短。基于这个缺陷，选择MEMORY存储引擎时需要特别小心。

使用Memory存储引擎的场景：

目标数据比较小，而且非常频繁的进行访问，在内存中存放数据，如果太大的数据会造成内存溢出。可以通过参数 max_heap_table_size 控制Memory表的大小，限制Memory表的最大的大小。
如果数据是临时的，而且必须立即可用得到，那么就可以放在内存中。
存储在Memory表中的数据如果突然间丢失的话也没有太大的关系

5.4.7、Federated 引擎：访问远程表

Federated引擎是访问其他MySQL服务器的一个 代理 ，尽管该引擎看起来提供了一种很好的跨服务器的灵活性 ，但也经常带来问题，因此默认是禁用的

5.4.8、Merge引擎：管理多个MyISAM表构成的表集合

5.4.9、NDB引擎：MySQL集群专用存储引擎

也叫做 NDB Cluster 存储引擎，主要用于MySQL Cluster 分布式集群环境，类似于 Oracle的RAC集群。

5.4.10、引擎对比

MySQL中同一个数据库，不同的表可以选择不同的存储引擎。如下表对常用存储引擎做出了对比。

特点	MylSAM	InnoDB	MEMORY	MERGE	NDB
存储限制	有	64TB	有	没有	有
`事务安全`		支持
`锁机制`	表锁，即使操作一条记录也会锁住整个表，不适合高并发的操作	行锁，操作时只锁某一行，不对其它行有影响，适合高并发的操作	表锁	行锁	表锁
B树索引	支持	支持	支持	支持	支持
哈希索引			支持		支持
全文索引	支持
集群索引		支持
数据缓存		支持	支持		支持
`索引缓存`	只缓存索引，不缓存真实数据	只缓存索引，还缓存真实数据，对内存要求较高，而且内存大小对性能有绝对性的影响	支持	支持	支持
数据可压缩	支持
空间使用	低	高	N/A	低	低
内存使用	低	高	中等	低	高
批量插入的速度	高	低	高	高	高
`支持外键`		支持

我们最常用的就是InnoDB和MyISAM，有时会提一下Memory 。其中InnoDB是MySQL默认的存储引擎。

5.5、MyISAM和InnoDB

很多人对InnoDB和MylSAM的取舍存在疑问，到底选择哪个比较好呢？

MySQL5.5之前的默认存储引擎是MyISAM,5.5之后改为了InnoDB

首先对于InnoDB存储引擎，提供了良好的事务管理、崩溃修复能力和并发控制。因为InnoDB存储引擎支持事务，所以对于要求事务完整性的场合需要选择IoDB,比如数据操作除了插入和查询以外还包含有很多更新、删除操作，像财务系统等对数据准确性要求较高的系统。缺点是其读写效率稍差，占用的数据空间相对比较大。

其次对于MyISAM存储引擎，如果是小型应用，系统以读操作和插入操作为主，只有很少的更新、删除操作，并且对事务的要求没有那么高，则可以选择这个存储引擎。MylSAM存储引擎的优势在于占用空间小，处理速度快；缺点是不支持事务的完整性和并发性。

这两种引擎各有特点，当然你也可以在MySQL中，针对不同的数据表，可以选择不同的存储引擎。|

对比项	MyISAM	InnoDB
外键	不支持	支持
事务	不支持	支持
行表锁	表锁，即使操作一条记录也会锁住整个表，不适合高并发的操作	行锁，操作时只锁某一行，不对其它行有影响，适合高并发的操作
缓存	不仅缓存索引还要缓存真实数据，对内存要求较高，而且内存大小对性能有决定性的影响	只缓存索引，不缓存真实数据
自带系统表使用	Y	N
关注点	性能：节省资源、消耗少、简单业务	事务：并发写、事务、更大资源
默认安装	Y	Y
默认使用	N	Y

5.6、阿里巴巴、淘宝用哪个

产品	价格	目标	主要功能	是否可投入生产？
Percona Server	免费	提供 XtraDB 存储引擎的包装器和其他分析工具	XtraDB	是
MariaDB	免费	扩展 MySQL 以包含 XtraDB 和其他性能改进	XtraDB	是
Drizzle	免费	提供比 MySQL 更强大的可扩展性和性能改进	高可用性	是

Percona为MySQL数据库服务器进行了改进，在功能和性能上较MySQL有很显著的提升。
该版本提升了在高负载情况下的InnoDB的性能、为DBA提供一些非常有用的性能诊断工具；另外有更多的参数和命令来控制服务器行为。
该公司新建了一款存储引擎叫Xtradb完全可以替代Innodb,并且在性能和并发上做得更好
阿里巴巴大部分mysq数据库其实使用的perconal的原型加以修改。

知识补充：

1、InnoDB表的优势

InnoDB存储引擎在实际应用中拥有诸多优势，比如操作便利、提高了数据库的性能、维护成本低等。如果由于硬件或软件的原因导致服务器崩溃，那么在重启服务器之后不需要进行额外的操作。InnoDB崩溃恢复功能自动将之前提交的内容定型，然后撤销没有提交的进程，重启之后继续从崩溃点开始执行。

InnoDB存储引擎在主内存中维护缓冲池，高频率使用的数据将在内存中直接被处理。这种缓存方式应用于多种信息，加速了处理进程。

在专用服务器上，物理内存中高达80%的部分被应用于缓冲池。如果需要将数据插入不同的表中，可以设置外键加强数据的完整性。更新或者删除数据，关联数据将会被自动更新或删除。如果试图将数据插入从表，但在主表中没有对应的数据，插入的数据将被自动移除。如果磁盘或内存中的数据出现崩溃，在使用脏数据之前，校验和机制会发出警告。当每个表的主键都设置合理时，与这些列有关的操作会被自动优化。插入、更新和删除操作通过做改变缓冲自动机制进行优化。InnoDB不仅支持当前读写，也会缓冲改变的数据到数据流磁盘

InnoDB的性能优势不只存在于长时运行查询的大型表。在同一列多次被查询时，自适应哈希索引会提高查询的速度。使用InnoDB可以压缩表和相关的索引，可以在不影响性能和可用性的情况下创建或删除索引。对于大型文本和BLOB数据，使用动态行形式，这种存储布局更高效。通过查询INFORMATION_SCHEMA库中的表可以监控存储引擎的内部工作。在同一个语句中，InnoDB表可以与其他存储引擎表混用。即使有些操作系统限制文件大小为2GB，InnoDB仍然可以处理。当处理大数据量时，InnoDB兼顾CPU，以达到最大性能

2、InnoDB和ACID模型

ACID模型是一系列数据库设计规则，这些规则着重强调可靠性，而可靠性对于商业数据和任务关键型应用非常重要。MySQL包含类似InnoDB存储引擎的组件，与ACID模型紧密相连，这样出现意外时，数据不会崩溃，结果不会失真。如果依赖ACID模型，可以不使用一致性检查和崩溃恢复机制。如果拥有额外的软件保护，极可靠的硬件或者应用可以容忍一小部分的数据丢失和不一致，可以将MySQL设置调整为只依赖部分ACID特性，以达到更高的性能。下面讲解InnoDB存储引擎与ACID模型相同作用的四个方面。

原子方面ACID的原子方面主要涉及InnoDB事务，与MySQL相关的特性主要包括：
- 自动提交设置
- COMMIT语句
- ROLLBACK语句
- 操作INFORMATION_SCHEMA库中的表数据
一致性方面ACID模型的一致性主要涉及保护数据不崩溃的内部InnoDB处理过程，与MySQL相关的特性主要包括：
- InnoDB双写缓存
- InnoDB崩溃恢复
隔离方面 隔离是应用于事务的级别，与MySQL相关的特性主要包括：
- 自动提交设置
- SET ISOLATION LEVEL语句
- InnoDB锁的低级别信息
耐久性方面 ACID模型的耐久性主要涉及与硬件配置相互影响的MySQL软件特性。由于硬件复杂多样化，耐久性方面没有具体的规则可循。与MySQL相关的特性有：

InnoDB双写缓存，通过innodb_doublewrite配置项配置
配置项innodb_flush_log_at_trx_commit
配置项sync_binlog
配置项innodb_file_per_table
存储设备的写入缓存
存储设备的备用电池缓存
运行MySQL的操作系统
持续的电力供应
备份策略
对分布式或托管的应用，最主要的在于硬件设备的地点以及网络情况

3、InnoDB架构

缓冲池 缓冲池是主内存中的一部分空间，用来缓存已使用的表和索引数据。缓冲池使得经常被使用的数据能够直接在内存中获得，从而提高速度
更改缓存 更改缓存是一个特殊的数据结构，当受影响的索引页不在缓存中时，更改缓存会缓存辅助索引页的更改。索引页被其他读取操作时会加载到缓存池，缓存的更改内容就会被合并。不同于集群索引，辅助索引并非独一无二的。当系统大部分闲置时，清除操作会定期运行，将更新的索引页刷入磁盘。更新缓存合并期间，可能会大大降低查询的性能。在内存中，更新缓存占用一部分InnoDB缓冲池。在磁盘中，更新缓存是系统表空间的一部分。更新缓存的数据类型由innodb_change_buffering配置项管理
自适应哈希索引 自适应哈希索引将负载和足够的内存结合起来，使得InnoDB像内存数据库一样运行，不需要降低事务上的性能或可靠性。这个特性通过innodb_adaptive_hash_index选项配置，或者通过--skip-innodb_adaptive_hash_index命令行在服务启动时关闭
重做日志缓存 重做日志缓存存放要放入重做日志的数据。重做日志缓存大小通过innodb_log_buffer_size配置项配置。重做日志缓存会定期地将日志文件刷入磁盘。大型的重做日志缓存使得大型事务能够正常运行而不需要写入磁盘
系统表空间 系统表空间包括InnoDB数据字典、双写缓存、更新缓存和撤销日志，同时也包括表和索引数据。多表共享，系统表空间被视为共享表空间
双写缓存 双写缓存位于系统表空间中，用于写入从缓存池刷新的数据页。只有在刷新并写入双写缓存后，InnoDB才会将数据页写入合适的位置
撤销日志 撤销日志是一系列与事务相关的撤销记录的集合，包含如何撤销事务最近的更改。如果其他事务要查询原始数据，可以从撤销日志记录中追溯未更改的数据。撤销日志存在于撤销日志片段中，这些片段包含于回滚片段中
每个表一个文件的表空间 每个表一个文件的表空间是指每个单独的表空间创建在自身的数据文件中，而不是系统表空间中。这个功能通过innodb_file_per_table配置项开启。每个表空间由一个单独的.ibd数据文件代表，该文件默认被创建在数据库目录中
通用表空间 使用CREATE TABLESPACE语法创建共享的InnoDB表空间。通用表空间可以创建在MySQL数据目录之外能够管理多个表并支持所有行格式的表
撤销表空间 撤销表空间由一个或多个包含撤销日志的文件组成。撤销表空间的数量由innodb_undo_tablespaces配置项配置
临时表空间 用户创建的临时表空间和基于磁盘的内部临时表都创建于临时表空间。innodb_temp_data_file_path配置项定义了相关的路径、名称、大小和属性。如果该值为空，默认会在innodb_data_home_dir变量指定的目录下创建一个自动扩展的数据文件
重做日志 重做日志是基于磁盘的数据结构，在崩溃恢复期间使用，用来纠正数据。正常操作期间，重做日志会将请求数据进行编码，这些请求会改变InnoDB表数据。遇到意外崩溃后，未完成的更改会自动在初始化期间重新进行

SQL

#java

MySQL架构篇

https://xiaoyu72.com/articles/66b7f10d/

Author

XiaoYu

Posted on

July 20, 2022

Updated on

August 28, 2023

Licensed under

MySQL索引及调优篇 Previous

MySQL8其它新特性 Next

MySQL架构篇

1、Linux下MySQL的安装与使用

1.1、安装前说明

1.1.1、查看是否安装过MySQL

1.1.2、MySQL的卸载

1.2、MySQL的Linux版安装

1.2.1、MySQL的四大版本

1.2.2、MySQL下载

1.2.3、CentOS7下检查MySQL依赖

1.2.4、CentOS7下MySQL安装过程

1.2.5、查看MySQL版本

1.2.6、服务的初始化

1.2.7、启动MySQL，查看状态

1.2.8、查看MySQL服务是否自启动

1.3、MySQL登录

1.3.1、首次登录

1.3.2、修改密码

1.3.3、设置远程登录

1.4、Linux下修改配置

1.5、字符集的相关操作

1.5.1、各级别的字符集

1.5.2、字符集与比较规则

1.5.2.1、utf8与utf8mb4

1.5.2.2、比较规则

1.5.3、请求到响应过程中字符集的变化

1.6、SQL大小写规范问题

1.6.1、Linux和Windows平台的区别

1.6.2、Linux下大小写规则设置

1.6.3、SQL编写建议

1.7、sql_model的合理设计

1.7.1、介绍

1.7.2、宽松模式Vs严格模式

1.7.3、模式查看和设置

1.7.4、sql_mode常用值

2、MySQL的数据目录

2.1、MySQL8的主要目录结构

2.1.1、数据库文件的存放路径

2.1.2、相关命令目录

2.1.3、配置文件目录

2.2、数据库和文件系统的关系

2.2.1、查看默认数据库

2.2.2、数据库在文件系统中的表示

2.2.3、表在文件系统中的表示

2.2.3.1、InnoDB存储引擎模式

1.表结构

2.表中数据和索引

3.疑问

2.2.3.2、MyISAM存储引擎模式

1.表结构

2.表中数据和索引

2.2.4、小结

2.2.5、视图在文件系统中的表示

2.2.6、其他的文件

3、用户与权限管理

3.1、用户管理

3.1.1、登录MySQL服务器

3.1.2、创建用户

3.1.3、修改用户

3.1.4、删除用户

3.1.5、设置当前用户密码

3.1.6、修改其它用户密码

3.1.7、MySQL8密码管理

3.1.7.1、密码过期策略

3.1.7.2、密码重用策略

3.2、权限管理

3.2.1、权限列表

3.2.2、授予权限的原则

3.2.3、授予权限

3.2.4、 查看权限

3.2.5、 收回权限

3.3、权限表

3.3.1、user表

3.3.2、db表

3.3.3、 tables_priv表和columns_priv表

3.3.4、procs_priv表

3.4、访问控制

3.4.1、连接核实阶段

3.4.2、请求核实阶段

3.5、角色管理

3.5.1、角色的理解

3.2.4、查看权限

3.2.5、收回权限

4.2.2.2、多次执行相同SQL查询