文章目录
- MySQL高级
- 一 Linux下MySQL的安装与使用
- 1. 安装前说明
- 2. MySQL的Linux版安装
- 3. MySQL登录
- 4. Linux下修改配置
- 5. 字符集的相关操作
- 5.1、各级别的字符集
- 5.2、请求到响应过程中字符集的变化
- 二 MySQL的数据目录
- 三 用户与权限管理
- 四、逻辑架构
- 4.1、逻辑架构剖析
- 4.1.1、服务器处理客户端请求
- 4.1.2、Connectors
- 4.1.3、第1层：连接层
- 4.1.4、第2层：服务层
- 4.1.5、第3层：引擎层
- 4.1.6、存储层
- 4.1.7、小结
- 4.2、SQL执行流程
- 4.2.1、MySQL 中的 SQL执行流程
- 4.2.2、MySQL8中SQL执行原理
- 4.2.3、MySQL5.7中SQL执行原理
- 4.2.4、SQL语法顺序
- 4.2.5、Oracle中的SQL执行流程(了解)
- 4.3、数据库缓冲池(buffer pool)
- 4.3.1、缓冲池vs查询缓存
- 4.3.2、缓冲池如何读取数据
- 4.3.3、查看/设置缓冲池的大小
- 4.3.4、多个Buffer Pool实例
- 4.3.5、引申问题
- 五、存储引擎
- 5.1、查看存储引擎
- 5.2、设置系统默认的存储引擎
- 5.3、设置表的存储引擎
- 5.4、引擎介绍
- 5.4.1、InnoDB 引擎：具备外键支持功能的事务存储引擎
- 5.4.2、MyISAM引擎：主要的非事务处理存储引擎
- 5.4.3、Archive 引擎：用于数据存档
- 5.4.4、Blackhole 引擎：丢弃写操作，读操作会返回空内容
- 5.4.5、CSV 引擎：存储数据时，以逗号分隔各个数据项
- 5.4.6、Memory 引擎：置于内存的表
- 5.4.7、Federated 引擎：访问远程表
- 5.4.8、Merge引擎：管理多个MyISAM表构成的表集合
- 5.4.9、NDB引擎：MySQL集群专用存储引擎
- 5.5、MyISAM和InnoDB
- 六、索引的数据结构
- 6.1、为什么使用索引
- 6.2、索引及其优缺点
- 6.2.1 、索引概述
- 6.2.2、优点
- 6.2.3、缺点
- 6.3、InnoDB中索引的推演
- 6.3.1、索引之前的查找
- 6.3.2、设计索引
- 6.3.2.1、一个简单的索引设计方案
- 6.3.2.2、InnoDB中的索引方案
- 6.3.3、常见索引概念
- 6.3.4、InnoDB的B+树索引的注意事项
- 6.4、MyISAM中的索引方案
- 6.4.1、MyISAM索引的原理
- 6.4.2、MyISAM与 InnoDB对比
- 6.5、索引的代价
- 6.6、MySQL数据结构选择的合理性
- 6.6.1、全表遍历
- 6.6.2、Hash结构
- 6.6.3、二叉搜索树
- 6.6.4、AVL树
- 6.6.5、B-Tree
- 6.6.6、B+Tree
- 6.6.7、R树
- 6.6.8、小结
- 七、InnoDB数据存储结构
- 7.1、数据库的存储结构：页
- 7.1.1、磁盘与内存交互基本单位：页
- 7.1.2、页结构概述
- 7.1.3、页的大小
- 7.1.4、页的上层结构
- 7.2、页的内部结构
- 7.2.1、第1部分：文件头部和文件尾部
- 7.2.1.1、File Header(文件头)
- 7.2.1.2、File Trailer（文件尾部）
- 7.2.2、第2部分：空闲空间、用户记录和最小最大记录
- 7.2.2.1、Free Space (空闲空间)
- 7.2.2.2、User Records (用户记录)
- 7.2.2.3、Infimum + Supremum（最小最大记录）
- 7.2.3、第3部分：页目录和页面头部
- 7.2.3.1、Page Directory（页目录）
- 7.2.3.2、Page Header（页面头部）
- 从数据页的角度看B+树如何查询
- 7.3、InnoDB行格式（或记录格式）
- 7.3.1、指定行格式的语法
- 7.3.2、COMPACT行格式
- 7.3.2.1、变长字段长度列表
- 7.3.2.2、NULL值列表
- 7.3.2.3、记录头信息（5字节）
- 7.3.2.4、记录的真实数据
- 7.3.3、Dynamic和Compressed行格式
- 行溢出
- 7.3.4、Redundant行格式
- 7.4、区、段和碎片区
- 7.4.1、为什么要有区？
- 7.4.2、为什么要有段？
- 7.4.3、为什么要有碎片区？
- 7.4.4、区的分类
- 7.5、表空间
- 7.5.1、独立表空间
- 7.5.2、系统表空间
- 八、索引的创建与设计原则
- 8.1、索引的声明与使用
- 8.1.1、索引的分类
- 8.1.2、创建索引
- 1. 创建表的时候创建索引
- 2. 在已经存在的表上创建索引
- 8. 1.3、删除索引
- 8.2、MySQL8.0索引新特性
- 8.2.1、支持降序索引
- 8.2.2、隐藏索引
- 8.3、索引的设计原则
- 8.3.1、哪些情况适合创建索引
- 8.3.2、限制索引的数目
- 8.3.3、哪些情况不适合创建索引
- 九、性能分析工具的使用
- 9.1、数据库服务器的优化步骤
- 9.2、查看系统性能参数
- 9.3、统计SQL的查询成本：last_query_cost
- 9.4、定位执行慢的SQL：慢查询日志
- 9.4.1、开启慢查询日志参数
- 9.4.2、查看慢查询数目
- 9.4.3、慢查询日志分析工具：mysqldumpslow
- 9.4.4、关闭慢查询日志
- 9.4.5、删除慢查询日志
- 9.5、查看SQL执行成本：SHOW PROFILE
- 9.6、分析查询语句：EXPLAIN
- 9.6.1、基本语法
- 9.6.2、EXPLAIN各列作用
- 9.7、EXPLAIN的进一步使用
- 9.7.1、EXPLAIN四种输出格式
- 9.7.2、SHOW WARNINGS的使用
- 9.8、分析优化器执行计划：trace
- 9.9、MySQL监控分析视图-sys schema
- 9.9.1、Sys schema视图摘要
- 9.9.2、Sys schema视图使用场景
- 十、索引优化与查询优化
- 10.1、索引失效案例
- 10.2、关联查询优化
- 10.2.1、Simple Nested-Loop Join（简单嵌套循环连接）
- 10.2.2、Index Nested-Loop Join（索引嵌套循环连接）
- 10.2.3、Block Nested-Loop Join（块嵌套循环连接）
- 10.2.4、Hash Join
- 10.3、子查询优化
- 10.4、排序优化
- 10.5、GROUP BY优化
- 10.6、优化分页查询
- 10.7、优先考虑覆盖索引
- 7.1、什么是覆盖索引？
- 7.2、覆盖索引的利弊
- 10.8、索引条件下推
- 10.8.1、使用前后的扫描过程
- 10.8.2、ICP的开启/关闭
- 10.8.3、ICP的使用条件
- 10.9、其它查询优化策略
- 10.9.1、EXISTS、和IN的区分
- 10.9.2、COUNT(\*)与COUNT(具体字段)效率
- 9.3、关于SELECT(\*)
- 9.4、LIMIT 1对优化的影响
- 9.5、多使用COMMIT
- 十一、数据库的设计规范
- 11.1、范 式
- 11.1.1、范式简介
- 11.1.2、范式都包括哪些
- 11.1.3、键和相关属性的概念
- 11.1.4、第一范式(1st NF)
- 11.1.5、第二范式(2nd NF)
- 11.1.6、第三范式(3rd NF)
- 11.1.7、小结
- 11.2. 反范式化
- 2.1、概述
- 2.2、反范式的新问题
- 2.3、反范式的适用场景
- 11.3、BCNF(巴斯范式)
- 11.4、ER模型
- 4.1、ER 模型包括那些要素？
- 4.2、关系的类型
- 5. 数据表的设计原则
- 6. 数据库对象编写建议
- 6.1、关于库
- 6.2、关于表、列
- 6.3、关于索引
- 6.4、SQL编写
- 十二、数据库其它调优策略
- 12.1、数据库调优的措施
- 12.1.1、调优的目标
- 12.1.2、如何定位调优问题
- 12.1.3、调优的维度和步骤
- 12.2、优化MySQL服务器
- 12.2.1、优化服务器硬件
- 12.2.2、优化MySQL的参数
- 12.3、优化数据库结构
- 3.1、拆分表：冷热数据分离
- 3.2、增加中间表
- 3.3、增加冗余字段
- 3.4、优化数据类型
- 3.5、优化插入记录的速度
- 3.6、使用非空约束
- 3.7、分析表、检查表与优化表
- 12.4、大表优化
- 限定查询的范围
- 读写分离
- 垂直拆分
- 水平拆分
- 12.5、其他调优策略
- 十三、事务基础知识
- 13.1、数据库事务概述
- 13.1.1、基本概念
- 13.1.2、事务的ACID特性
- 13.1.3、事务的状态
- 13.2、如何使用事务
- 13.2.1、显式事务
- 13.2.2、隐式事务
- 13.2.3、隐式提交数据的情况
- 13.3、事务隔离级别
- 13.3.1、数据并发问题
- 13.3.2、SQL中的四种隔离级别
- 13.3.3、MySQL的隔离级别
- 13.3.4、如何设置事务的隔离级别
- 十四、MySQL事务日志
- 14.1、redo日志
- 14.1.1、为什么需要REDO日志
- 14.1.2、REDO日志的好处、特点
- 14.1.3、redo的组成
- 14.1.4、redo的整体流程
- 14.1.5、redo log的刷盘策略
- 14.1.6、不同刷盘策略演示
- 1.7 写入redo log buffer过程
- 1.8 redo log file
- 14.1.9、小结
- 14.2、Undo日志
- 14.2.1、如何理解Undo日志
- 14.2.2、Undo日志的作用
- 14.2.3、undo的存储结构
- 14.2.4、undo的类型
- 14.2.5、undo log的生命周期
- 1. 简要生成过程
- 2. 详细生成过程
- 3. undo log是如何回滚的
- 4. undo log的删除
- 14.2.6、小结
- 十五、锁
- 15.1、概述
- 15.2、MySQL并发事务访问相同记录
- 15.2.1、读-读情况
- 15.2.2、写-写情况
- 15.2.3、读-写或写-读情况
- 15.2.4、并发问题的解决方案
- 15.3、锁的不同角度分类
- 3.1、从数据操作的类型划分：读锁、写锁
- 3.2、从数据操作的粒度划分：表级锁、页级锁、行锁
- 3.3、从对待锁的态度划分:乐观锁、悲观锁
- 3.4、按加锁的方式划分：显式锁、隐式锁
- 3.5、其它锁之：全局锁
- 3.6、其它锁之：死锁
- 15.4、锁的内存结构
- 15.5、锁监控
- 十六、多版本并发控制
- 16.1、什么是MVCC
- 16.2、快照读与当前读
- 16.2.1、快照读
- 16.2.2、当前读
- 16.3、复习
- 16.3.1、再谈隔离级别
- 16.3.2、隐藏字段、Undo Log版本链
- 16.4、MVCC实现原理之ReadView
- 16.4.1、什么是ReadView
- 16.4.2、设计思路
- 16.4.3、ReadView的规则
- 16.4.4、MVCC整体操作流程
- 14.5、举例说明
- 14.5.1、READ COMMITTED隔离级别下
- 14.5.2、REPEATABLE READ隔离级别下
- 14.5.3、如何解决幻读
- 6. 总结
- 十七、其它数据库日志
- 17.1、MySQL支持的日志
- 1.1、日志类型
- 1.2、日志的弊端
- 17.2、通用查询日志(general query log)
- 2.1、查看当前状态
- 2.2、启动日志
- 2.3、停止日志
- 17.3、错误日志(error log)
- 3.1、启动日志
- 3.2、查看日志
- 3.3、删除\刷新日志
- 17.4、二进制日志(bin log)
- 4.1、查看默认情况
- 4.2、日志参数设置
- 4.3、查看日志
- 4.4、使用日志恢复数据
- 4.5、删除二进制日志
- 17.5、再谈二进制日志(binlog)
- 5.1、写入机制
- 5.2、binlog与redolog对比
- 5.3、两阶段提交
- 17.6、中继日志(relay log)
- 6.1、介绍
- 6.2、恢复的典型错误
- 十八、主从复制
- 18.1、主从复制概述
- 1.1、如何提升数据库并发能力
- 1.2、主从复制的作用
- 18.2、主从复制的原理
- 2.1、原理剖析
- 2.2、复制的基本原则
- 18.3、同步数据一致性问题
- 3.1、理解主从延迟问题
- 3.2、主从延迟问题原因
- 3.3、如何减少主从延迟
- 3.4、如何解决一致性问题
- 十九、数据库备份与恢复
- 19.1、物理备份与逻辑备份
- 19.2、mysqldump实现逻辑备份
- 2.1、备份一个数据库
- 2.2、备份全部数据库
- 2.3、备份部分数据库
- 2.4、备份部分表
- 2.5、备份单表的部分数据
- 2.6、排除某些表的备份
- 2.7、只备份结构或只备份数据
- 2.8、备份中包含存储过程、函数、事件
- 19.3、mysql命令恢复数据
- 3.1、单库备份中恢复单库
- 3.2、全量备份恢复
- 3.3、从全量备份中恢复单库
- 3.4、从单库备份中恢复单表
- 19.4、表的导出与导入
- 4.1、表的导出
- 4.2、表的导入
- 19.5、数据库迁移
- 迁移方案
- 迁移注意点
- 19.6、删库了不敢跑，能干点啥?
- delete：误删行
- truncate/drop：误删库/表
- 预防使用truncate /drop误删库/表
MySQL高级
一 Linux下MySQL的安装与使用
1. 安装前说明
#### 1.1查看是否安装过MySQL
- 如果你是用rpm安装, 检查一下RPM PACKAGE：
rpm -qa | grep -i mysql # -i 忽略大小写
- 检查mysql service：
systemctl status
#### 1.2MySQL的卸载
1. 关闭mysql服务
systemctl stop
2. 查看当前 mysql安装状况
rpm -qa | grep -i mysql
# 或
yum list installed | grep mysql
3. 卸载上述命令查询出的已安装程序
yum remove mysql-xxx mysql-xxx mysql-xxx mysqk-xxxx
务必卸载干净，反复执行`rpm -qa | grep -i mysql 确认是否有卸载残留
4. 删除mysql相关文件
- 查找相关文件
find / -name mysql
- 删除上述命令查找出的相关文件
rm -rf xxx
5. 删除 **
rm -rf /etc/
2. MySQL的Linux版安装
#### 2.1 CentOS7下检查MySQL依赖
1. 检查/tmp临时目录权限（必不可少）
由于mysql安装过程中，会通过mysql用户在/tmp目录下新建tmp_db文件，所以请给/tmp较大的权限。执行 ：
chmod -R 777 /tmp
2. 安装前，检查依赖
rpm -qa|grep libaio
rpm -qa|grep net-tools
#### 2.2 CentOS7下MySQL安装过程
1. 将安装程序拷贝到/opt目录下
在mysql的安装文件目录下执行：（必须按照顺序执行）
rpm -ivh mysql-community-common-8.0.25-1.el7.x86_64.rpm
rpm -ivh mysql-community-client-plugins-8.0.25-1.el7.x86_64.rpm
rpm -ivh mysql-community-libs-8.0.25-1.el7.x86_64.rpm
rpm -ivh mysql-community-client-8.0.25-1.el7.x86_64.rpm
rpm -ivh mysql-community-server-8.0.25-1.el7.x86_64.rpm
- `rpm`是Redhat Package Manage缩写，通过RPM的管理，用户可以把源代码包装成以rpm为扩展名的文件形式，易于安装。
- `-i`, --install 安装软件包
- `-v`, --verbose 提供更多的详细信息输出
- `-h`, --hash 软件包安装的时候列出哈希标记 (和 -v 一起使用效果更好)，展示进度条
> 若存在mariadb-libs问题，则执行**yum remove mysql-libs**即可
#### 2.3、查看MySQL版本
mysql --version
#或
mysqladmin --version
#### 2.4、服务的初始化
为了保证数据库目录与文件的所有者为 mysql 登录用户，如果你是以 root 身份运行 mysql 服务，需要执行下面的命令初始化：
mysqld --initialize --user=mysql
说明： --initialize 选项默认以“安全”模式来初始化，则会为 root 用户生成一个密码并将`该密码标记为过期`，登录后你需要设置一个新的密码。生成的`临时密码`会往日志中记录一份。
查看密码：
cat /var/log/
root@localhost: 后面就是初始化的密码
#### 2.5、启动MySQL，查看状态
#加不加.service后缀都可以
启动：systemctl start
关闭：systemctl stop
重启：systemctl restart
查看状态：systemctl status
#### 2.6、查看MySQL服务是否自启动
systemctl list-unit-files|grep
- 如不是enabled可以运行如下命令设置自启动
systemctl enable
- 如果希望不进行自启动，运行如下命令设置
systemctl disable
3. MySQL登录
#### 3.1、首次登录
通过`mysql -hlocalhost -P3306 -uroot -p`进行登录，在Enter password：录入初始化密码
#### 3.2、修改密码
ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';
#### 3.3、设置远程登录
1.确认网络
1.在远程机器上使用ping ip地址`保证网络畅通`
2.在远程机器上使用telnet命令`保证端口号开放`访问
2. 关闭防火墙或开放端口
方式一：关闭防火墙
- CentOS6 ：
service iptables stop
- CentOS7：
#开启防火墙
systemctl start
#查看防火墙状态
systemctl status
#关闭防火墙
systemctl stop
#设置开机启用防火墙
systemctl enable
#设置开机禁用防火墙
systemctl disable
方式二：开放端口
- 查看开放的端口号
firewall-cmd --list-all
- 设置开放的端口号
firewall-cmd --add-service=http --permanent
firewall-cmd --add-port=3306/tcp --permanent
- 重启防火墙
firewall-cmd --reload
4. Linux下修改配置
# 修改允许远程登陆
use mysql;
select Host,User from user;
update user set host = '%' where user ='root';
flush privileges;
> `%`是个 通配符 ，如果Host=192.168.1.%，那么就表示只要是IP地址前缀为“192.168.1.”的客户端都可以连接。如果`Host=%`，表示所有IP都有连接权限。
>
> 注意：在生产环境下不能为了省事将host设置为%，这样做会存在安全问题，具体的设置可以根据生产环境的IP进行设置。
配置新连接报错：错误号码 2058，分析是 mysql 密码加密方法变了。
解决方法一： 升级远程连接工具版本
解决方法二：
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'abc123';
5. 字符集的相关操作
5.1、各级别的字符集
show variables like 'character%';
- character_set_server：服务器级别的字符集
- character_set_database：当前数据库的字符集
- character_set_client：服务器解码请求时使用的字符集
- character_set_connection：服务器处理请求时会把请求字符串从character_set_client转为character_set_connection
- character_set_results：服务器向客户端返回数据时使用的字符集
小结
- 如果
创建或修改列时没有显式的指定字符集和比较规则，则该列默认用表的字符集和比较规则 - 如果
创建表时没有显式的指定字符集和比较规则，则该表默认用数据库的字符集和比较规则 - 如果
创建数据库时没有显式的指定字符集和比较规则，则该数据库默认用服务器的字符集和比较规则
5.2、请求到响应过程中字符集的变化
二 MySQL的数据目录
### 1. MySQL8的主要目录结构
find / -name mysql
#### 1.1、数据库文件的存放路径
show variables like 'datadir'; # /var/lib/mysql/
#### 1.2、相关命令目录
相关命令目录：/usr/bin 和/usr/sbin。
#### 1.3、配置文件目录
配置文件目录：/usr/share/mysql-8.0（命令及配置文件），/etc/mysql（如）
### 2. 数据库和文件系统的关系
#### 2.1、表在文件系统中的表示
##### 2.3.1 InnoDB存储引擎模式
1. 表结构
为了保存表结构，`InnoDB`在`数据目录`下对应的数据库子目录下创建了一个专门用于`描述表结构的文件`
表名.frm
2. 表中数据和索引
2.1 系统表空间（system tablespace）
默认情况下，InnoDB会在数据目录下创建一个名为`ibdata1`、大小为`12M`的`自拓展`文件，这个文件就是对应的`系统表空间`在文件系统上的表示。
2.2 独立表空间(file-per-table tablespace)
在MySQL5.6.6以及之后的版本中，InnoDB并不会默认的把各个表的数据存储到系统表空间中，而是为`每一个表建立一个独立表空间`，也就是说我们创建了多少个表，就有多少个独立表空间。使用`独立表空间`来存储表数据的话，会在该表所属数据库对应的子目录下创建一个表示该独立表空间的文件，文件名和表名相同。
表名.ibd
> MySQL8.0中不再单独提供`表名.frm`，而是合并在`表名.ibd`文件中。
2.3 系统表空间与独立表空间的设置
我们可以自己指定使用`系统表空间`还是`独立表空间`来存储数据，这个功能由启动参数`innodb_file_per_table`控制
[server]
innodb_file_per_table=0 # 0：代表使用系统表空间； 1：代表使用独立表空间
2.4 其他类型的表空间
随着MySQL的发展，除了上述两种老牌表空间之外，现在还新提出了一些不同类型的表空间，比如通用表空间（general tablespace）、临时表空间（temporary tablespace）等。
##### 2.3.2 MyISAM存储引擎模式
1. 表结构
- 在存储表结构方面， MyISAM 和 InnoDB 一样，也是在`数据目录`下对应的数据库子目录下创建了一个专门用于描述表结构的文件
表名.frm
2. 表中数据和索引
- 在MyISAM中的索引全部都是`二级索引`，该存储引擎的`数据和索引是分开存放`的。所以在文件系统中也是使用不同的文件来存储数据文件和索引文件，同时表数据都存放在对应的数据库子目录下。
存储表结构 #MySQL8.0 改为了
存储数据 (MYData)
存储索引 (MYIndex
三 用户与权限管理
### 1. 用户管理
#### 1.1、登录MySQL服务器
启动MySQL服务后，可以通过mysql命令来登录MySQL服务器，命令如下：
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服务器。
mysql -uroot -p -hlocalhost -P3306 mysql -e "select host,user from user"
#### 1.2、创建用户
CREATE USER 用户名 [IDENTIFIED BY '密码'][,用户名 [IDENTIFIED BY '密码']];
举例：
CREATE USER zhang3 IDENTIFIED BY '123123'; # 默认host是 %
CREATE USER 'kangshifu'@'localhost' IDENTIFIED BY '123456';
#### 1.3、修改用户
UPDATE SET USER='li4' WHERE USER='wang5';
FLUSH PRIVILEGES;
#### 1.4、删除用户
方式1：使用DROP方式删除（推荐）
DROP USER user[,user]…;
举例：
DROP USER li4 ; # 默认删除host为%的用户
DROP USER 'kangshifu'@'localhost';
方式2：使用DELETE方式删除（不推荐，有残留信息）
DELETE FROM WHERE Host=’hostname’ AND User=’username’;
FLUSH PRIVILEGES;
#### 1.5、设置当前用户密码
1. 使用ALTER USER命令来修改当前用户密码
ALTER USER USER() IDENTIFIED BY 'new_password';
2. 使用SET语句来修改当前用户密码
SET PASSWORD='new_password';
#### 1.6、修改其它用户密码
1. 使用ALTER语句来修改普通用户的密码
ALTER USER user [IDENTIFIED BY '新密码']
[,user[IDENTIFIED BY '新密码']]…;
2. 使用SET命令来修改普通用户的密码
SET PASSWORD FOR 'username'@'hostname'='new_password';
### 2. 权限管理
#### 2.1、权限列表
show privileges\G
- `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服务器上的任何文件（说明用户可以读任何数据库目录下的文件，因为服务器可以访问这些文件）。
#### 2.2、授予权限的原则
权限控制主要是出于安全因素，因此需要遵循以下几个`经验原则`：
1、只授予能`满足需要的最小权限`，防止用户干坏事。比如用户只是需要查询，那就只给select权限就可以了，不要给用户赋予update、insert或者delete权限。
2、创建用户的时候`限制用户的登录主机`，一般是限制成指定IP或者内网IP段。
3、为每个用户`设置满足密码复杂度的密码`。
4、`定期清理不需要的用户`，回收权限或者删除用户。
#### 2.3、授予权限
GRANT 权限1,权限2,…权限n ON 数据库名称.表名称 TO 用户名@用户地址 [IDENTIFIED BY ‘密码口令’];
- 该权限如果发现没有该用户，则会直接新建一个用户。
- 给li4用户用本地命令行方式，授予atguigudb这个库下的所有表的插删改查的权限。
GRANT SELECT,INSERT,DELETE,UPDATE ON atguigudb.* TO li4@localhost;
- 授予通过网络方式登录的joe用户 ，对所有库所有表的全部权限，密码设为123。注意这里唯独不包括grant的权限
GRANT ALL PRIVILEGES ON *.* TO joe@'%' IDENTIFIED BY '123';
#### 2.4、查看权限
- 查看当前用户权限
SHOW GRANTS;
# 或
SHOW GRANTS FOR CURRENT_USER;
# 或
SHOW GRANTS FOR CURRENT_USER();
- 查看某用户的全局权限
SHOW GRANTS FOR 'user'@'主机地址';
#### 2.5、收回权限
注意：在将用户账户从user表删除之前，应该收回相应用户的所有权限。
- 收回权限命令
REVOKE 权限1,权限2,…权限n ON 数据库名称.表名称 FROM 用户名@用户地址;
- 举例
#收回全库全表的所有权限
REVOKE ALL PRIVILEGES ON *.* FROM joe@'%';
#收回mysql库下的所有表的插删改查权限
REVOKE SELECT,INSERT,UPDATE,DELETE ON mysql.* FROM joe@localhost;
- 注意：`须用户重新登录后才能生效`
### 3. 角色管理
#### 3.1、创建角色
CREATE ROLE 'role_name'[@'host_name'] [,'role_name'[@'host_name']]...
角色名称的命名规则和用户名类似。如果`host_name省略，默认为%`，`role_name不可省略`，不可为空。
#### 3.2、给角色赋予权限
GRANT privileges ON table_name TO 'role_name'[@'host_name'];
上述语句中privileges代表权限的名称，多个权限以逗号隔开。可使用SHOW语句查询权限名称
SHOW PRIVILEGES;
#### 3.3、查看角色的权限
SHOW GRANTS FOR 'role_name';
只要你创建了一个角色，系统就会自动给你一个“`USAGE`”权限，意思是`连接登录数据库的权限`。
#### 3.4、回收角色的权限
REVOKE privileges ON tablename FROM 'rolename';
#### 3.5、删除角色
DROP ROLE role [,role2]...
注意，`如果你删除了角色，那么用户也就失去了通过这个角色所获得的所有权限`。
#### 3.6、给用户赋予角色
角色创建并授权后，要赋给用户并处于`激活状态`才能发挥作用。
GRANT role [,role2,...] TO user [,user2,...];
查询当前已激活的角色
SELECT CURRENT_ROLE();
#### 3.7、激活角色
方式1：使用set default role 命令激活角色
SET DEFAULT ROLE ALL TO 'kangshifu'@'localhost';
方式2：将activate_all_roles_on_login设置为ON**
SET GLOBAL activate_all_roles_on_login=ON;
这条 SQL 语句的意思是，对`所有角色永久激活`。
#### 3.8、撤销用户的角色
REVOKE role FROM user;
#### 3.9、设置强制角色(mandatory role)
- 方式1：服务启动前设置
[mysqld]
mandatory_roles='role1,role2@localhost,r3@%.'
- 方式2：运行时设置
SET PERSIST mandatory_roles = 'role1,role2@localhost,r3@%.'; #系统重启后仍然有效
SET GLOBAL mandatory_roles = 'role1,role2@localhost,r3@%.'; #系统重启后失效
四、逻辑架构
4.1、逻辑架构剖析
4.1.1、服务器处理客户端请求
首先Mysql是典型的C/S架构，服务器端程序使用的 mysqld
不论客户端进程和服务器进程是采用哪种方式进行通信，最后实现的效果都是：客户端进程向服务器进程发送一段文本（SQL语句)，服务器进程处理后再向客户端进程发送一段文本(处理结果)。
那服务器进程对客户端进程发送的请求做了什么处理，才能产生最后的处理结果呢？这里以查询请求为例展示：
4.1.2、Connectors
4.1.3、第1层：连接层
系统（客户端）访问MySQL服务器前，做的第一件事就是建立TCP连接。
经过三次握手建立连接成功后，MySQL服务器对TCP传输过来的账号密码做身份认证、权限获取。
- 用户名或密码不对，会收到一个Access denied for user错误，客户端程序结束执行
- 用户名密码认证通过，会从权限表查出账号拥有的权限与连接关联，之后的权限判断逻辑，都将依赖于此时读到的权限
TCP连接收到请求后，必须要分配给一个线程专门与这个客户端的交互。所以还会有个线程池，去走后面的流程。每一个连接从连接池中获取线程，省去了创建和销毁线程的开销。
4.1.4、第2层：服务层
-
SQL Interface: SQL接口
- 接收用户的SQL命令，并且返回用户需要查询的结果。比如SELECT … FROM就是调用SQL Interface
- MySQL支持DML（数据操作语言）、DDL（数据定义语言）、存储过程、视图、触发器、自定义函数等多种SQL语言接口
-
Parser: 解析器
- 在解析器中对 SQL 语句进行语法分析、语义分析。将SQL语句分解成数据结构，并将这个结构传递到后续步骤，以后SQL语句的传递和处理就是基于这个结构的。如果在分解构成中遇到错误，那么就说明这个SQL语句是不合理的。
- 在SQL命令传递到解析器的时候会被解析器验证和解析，并为其创建
语法树，并根据数据字典丰富查询语法树，会验证该客户端是否具有执行该查询的权限。创建好语法树后，MySQL还会对SQL查询进行语法上的优化，进行查询重写。
-
Optimizer：查询优化器
- SQL语句在语法解析之后、查询之前会使用查询优化器确定 SQL 语句的执行路径，生成一个
执行计划。 - 这个执行计划表明应该
使用哪些索引进行查询（全表检索还是使用索引检索），表之间的连接顺序如何，最后会按照执行计划中的步骤调用存储引擎提供的方法来真正的执行查询，并将查询结果返回给用户。 - 它使用“
选取-投影-连接”策略进行查询。例如：
SELECT id,name FROM student WHERE gender = '女';这个SELECT查询先根据WHERE语句进行
选取，而不是将表全部查询出来以后再进行gender过滤。 这个SELECT查询先根据id和name进行属性投影，而不是将属性全部取出以后再进行过滤，将这两个查询条件连接起来生成最终查询结果。 - SQL语句在语法解析之后、查询之前会使用查询优化器确定 SQL 语句的执行路径，生成一个
-
Caches & Buffers： 查询缓存组件
- MySQL内部维持着一些Cache和Buffer，比如Query Cache用来缓存一条SELECT语句的执行结果，如果能够在其中找到对应的查询结果，那么就不必再进行查询解析、优化和执行的整个过程了，直接将结果反馈给客户端。
- 这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等 。
- 这个查询缓存可以在
不同客户端之间共享。 - 从MySQL 5.7.20开始，不推荐使用查询缓存，并在
MySQL 8.0中删除。
4.1.5、第3层：引擎层
插件式存储引擎层（ Storage Engines）， 真正的负责了MySQL中数据的存储和提取，对物理服务器级别维护的底层数据执行操作 ，服务层通过API与存储引擎进行通信。
4.1.6、存储层
所有的数据，数据库、表的定义，表的每一行的内容，索引，都是存在 文件系统 上，以 文件 的方式存在的，并完成与存储引擎的交互。当然有些存储引擎比如InnoDB，也支持不使用文件系统直接管理裸设备，但现代文件系统的实现使得这样做没有必要了。在文件系统之下，可以使用本地磁盘，可以使用DAS、NAS、SAN等各种存储系统。
4.1.7、小结
简化为三层结构：
-
连接层：客户端和服务器端建立连接，客户端发送 SQL 至服务器端；
-
SQL 层（服务层）：对 SQL 语句进行查询处理；与数据库文件的存储方式无关；
-
存储引擎层：与数据库文件打交道，负责数据的存储和读取。
4.2、SQL执行流程
4.2.1、MySQL 中的 SQL执行流程
MySQL的查询流程：
1、查询缓存 ：Server 如果在查询缓存中发现了这条 SQL 语句，就会直接将结果返回给客户端；如果没有，就进入到解析器阶段。需要说明的是，因为查询缓存往往效率不高，所以在 MySQL8.0 之后就抛弃了这个功能。
大多数情况查询缓存就是个鸡肋，为什么呢？
SELECT employee_id,last_name FROM employees WHERE employee_id = 101;
查询缓存是提前把查询结果缓存起来，这样下次不需要执行就可以直接拿到结果。需要说明的是，在MySQL 中的查询缓存，不是缓存查询计划，而是查询对应的结果。这就意味着查询匹配的鲁棒性大大降低，只有相同的查询操作才会命中查询缓存。两个查询请求在任何字符上的不同（例如：空格、注释、大小写），都会导致缓存不会命中。因此 MySQL 的 查询缓存命中率不高 。
同时，如果查询请求中包含某些系统函数、用户自定义变量和函数、一些系统表，如 mysql 、information_schema、performance_schema 数据库中的表，那这个请求就不会被缓存。以某些系统函数举例，可能同样的函数的两次调用会产生不一样的结果，比如函数 NOW ，每次调用都会产生最新的当前时间，如果在一个查询请求中调用了这个函数，那即使查询请求的文本信息都一样，那不同时间的两次查询也应该得到不同的结果，如果在第一次查询时就缓存了，那第二次查询的时候直接使用第一次查询的结果就是错误的！
此外，既然是缓存，那就有它缓存失效的时候。MySQL的缓存系统会监测涉及到的每张表，只要该表的结构或者数据被修改，如对该表使用了INSERT、UPDATE、DELETE、TRUNCATE TABLE、ALTER TABLE、DROP TABLE或DROP DATABASE语句，那使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除！对于更新压力大的数据库来说，查询缓存的命中率会非常低。
总之，因为查询缓存往往弊大于利，查询缓存的失效非常频繁。
一般建议大家在静态表里使用查询缓存，什么叫静态表呢？就是一般我们极少更新的表。比如，一个系统配置表、字典表，这张表上的查询才适合使用查询缓存。好在MysQL也提供了这种”按需使用”的方式。你可以将参数query_cache_type设置成DEMAND，代表当sql语句中有SQL_CACHE关键词时才缓存。比如:
# query_cache_type有3个值，0代表关闭查询缓存OFF，1代表开启ON，2（DEMAND）
query_cache_type=2
这样对于默认的SQL语句都不使用查询缓存。而对于你确定要是使用查询缓存的语句，可以用SQL_CACHE显示指定，像下面这个语句一样：
select SQL_CACHE * from test where ID=5;
查看当前mysql实例是否开启缓存机制
# mysql5.7中:
mysql> show global variables like "%query_cache_type%";
# mysql8.0中
mysql> show global variables like "%query_cache_type%";
Empty set (0.02 sec)
监控查询缓存的命中率：
show status like '%Qcache%';
运行结果解析:
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. :当前缓存中缓存的查诎数量。
Qcache_total_blocks :当前缓存的block数量。
2、解析器 ：在解析器中对 SQL 语句进行语法分析、语义分析。
如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL需要知道你要做什么，因此需要对SQL语句做解析。SQL语句的分析分为词法分析与语法分析。
分析器先做“词法分析”。你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。 MySQL 从你输入的"select"这个关键字识别出来，这是一个查询语句。它也要把字符串“T”识别成“表名 T”，把字符串“ID”识别成“列 ID”。
接着，要做“语法分析”。根据词法分析的结果，语法分析器（比如：Bison）会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。
如果你的语句不对，就会收到“You have an error in your SQL syntax”的错误提醒，比如下面这个语句from写成了“rom”。
# 语句：
select * rom test where id=1;
# 错误：
ERROR 1064 (42800 ) : You have an error in your SQL syntax; check the manual that corresponds toyour MySQL server version for the right syntax to use near 'fro test where id=1' at line 1
如果SQL语句正确，则会生成一个语法树。
下面是SQL语法分析的过程步骤：
3、优化器 ：在优化器中会确定 SQL 语句的执行路径，比如是根据全表检索，还是根据索引检索等。在查询优化器中，可以分为逻辑查询优化阶段和物理查询优化阶段。
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='mysql高级课程' 的记录的 ID 值，再根据 ID 值关联到 test1，再判断 test1 里面 name的值是否等于 zhangwei。
这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。
如果你还有一些疑问，比如优化器是怎么选择索引的，有没有可能选择错等。后面讲到索引我们再谈。
在查询优化器中，可以分为 逻辑查询 优化阶段和 物理查询 优化阶段。
-
逻辑查询优化：就是通过改变SQL语句的内容来使得SQL查询更高效，同时为物理查询优化提供更多的候选执行计划。通常采用的方式是对SQL语句进行等价交换，对查询进行
重写，而查询重写的数学基础就是关系代数。对条件表达式进行等价谓词重写、条件简化，对视图进行重写，对子查询进行优化，对连接语义进行了外连接消除、嵌套连接消除等。 -
物理查询优化：是基于关系代数进行的查询重写，而关系代数的每一步都对应着物理计算，这些物理计算往往存在多种算法，因此需要计算各种物理路径的代价，从中选择代价最小的作为执行计划。在这个阶段里，对于单表和多表连接的操作，需要高效地使用索引，提升查询效率。
4、执行器 ：
在执行之前需要判断该用户是否 具备权限 。如果没有，就会返回权限错误。如果具备权限，就执行 SQL查询并返回结果。在 MySQL8.0 之前的版本，如果设置了查询缓存，这时会将查询结果进行缓存。
select * from test where id=1;
如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，调用存储引擎API对表进行的读写。存储引擎API只是抽象接口，下面还有个存储引擎层，具体实现还是要看表选择的存储引擎。
比如：表 test 中，ID 字段没有索引，那么执行器的执行流程是这样的：
- 调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是1，如果不是则跳过，如果是则将这行存在结果集中；调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
- 执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。
至此，这个语句就执行完成了。对于有索引的表，执行的逻辑也差不多。
SQL 语句在 MySQL 中的流程是： SQL语句→查询缓存→解析器→优化器→执行器 。
4.2.2、MySQL8中SQL执行原理
- 确认profiling 是否开启
mysql> select @@profiling;
mysql> show variables like 'profiling';
profiling=0 代表关闭，我们需要把 profiling 打开，即设置为 1：
mysql> set profiling=1;
- 多次执行相同SQL查询
然后我们执行一个 SQL 查询（你可以执行任何一个 SQL 查询）：
mysql> select * from employees;
- 查看profiles
查看当前会话所产生的所有 profiles：
mysql> show profiles; # 显示最近的几次查询
- 查看profile
显示执行计划，查看程序的执行步骤：
mysql> show profile;
此外，还可以查询更丰富的内容：
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 -- 显示交换次数相关的开销信息
}
mysql> show profile cpu,block io for query 6;
4.2.3、MySQL5.7中SQL执行原理
上述操作在MySQL5.7中测试，发现前后两次相同的sql语句，执行的查询过程仍然是相同的。不是会使用缓存吗？这里我们需要 显式开启查询缓存模式 。在MySQL5.7中如下设置：
- 配置文件中开启查询缓存
在 /etc/ 中新增一行：
query_cache_type=1
- 重启mysql服务
systemctl restart mysqld
- 开启查询执行计划
由于重启过服务，需要重新执行如下指令，开启profiling。
mysql> set profiling=1;
- 执行语句两次：
mysql> select * from locations;
mysql> select * from locations;
- 查看profiles
- 查看profile
显示执行计划，查看程序的执行步骤：
mysql> show profile for query 1;
mysql> show profile for query 2;
结论不言而喻。执行编号2时，比执行编号1时少了很多信息，从截图中可以看出查询语句直接从缓存中获取数据。
4.2.4、SQL语法顺序
随着Mysql版本的更新换代，其优化器也在不断的升级，优化器会分析不同执行顺序产生的性能消耗不同而动态调整执行顺序。
需求：查询每个部门年龄高于20岁的人数且高于20岁人数不能少于2人，显示人数最多的第一名部门信息
下面是经常出现的查询顺序：
4.2.5、Oracle中的SQL执行流程(了解)
Oracle 中采用了 共享池 来判断 SQL 语句是否存在缓存和执行计划，通过这一步骤我们可以知道应该采用硬解析还是软解析。
我们先来看下 SQL 在 Oracle 中的执行过程：
从上面这张图中可以看出，SQL 语句在 Oracle 中经历了以下的几个步骤。
1.语法检查：检查 SQL 拼写是否正确，如果不正确，Oracle 会报语法错误。
2.语义检查：检查 SQL 中的访问对象是否存在。比如我们在写 SELECT 语句的时候，列名写错了，系统就会提示错误。语法检查和语义检查的作用是保证 SQL 语句没有错误。
3.权限检查：看用户是否具备访问该数据的权限。
4.共享池检查：共享池（Shared Pool）是一块内存池，最主要的作用是缓存 SQL 语句和该语句的执行计划。Oracle 通过检查共享池是否存在 SQL 语句的执行计划，来判断进行软解析，还是硬解析。那软解析和硬解析又该怎么理解呢？
在共享池中，Oracle 首先对 SQL 语句进行 Hash 运算 ，然后根据 Hash 值在库缓存（Library Cache）中查找，如果 存在 SQL 语句的执行计划 ，就直接拿来执行，直接进入“执行器”的环节，这就是 软解析 。
如果没有找到 SQL 语句和执行计划，Oracle 就需要创建解析树进行解析，生成执行计划，进入“优化器”这个步骤，这就是 硬解析 。
5.优化器：优化器中就是要进行硬解析，也就是决定怎么做，比如创建解析树，生成执行计划。
6.执行器：当有了解析树和执行计划之后，就知道了 SQL 该怎么被执行，这样就可以在执行器中执行语句了。
共享池是 Oracle 中的术语，包括了库缓存，数据字典缓冲区等。我们上面已经讲到了库缓存区，它主要缓存 SQL 语句和执行计划。而 数据字典缓冲区 存储的是 Oracle 中的对象定义，比如表、视图、索引等对象。当对 SQL 语句进行解析的时候，如果需要相关的数据，会从数据字典缓冲区中提取。
库缓存 这一个步骤，决定了 SQL 语句是否需要进行硬解析。为了提升 SQL 的执行效率，我们应该尽量避免硬解析，因为在 SQL 的执行过程中，创建解析树，生成执行计划是很消耗资源的。
你可能会问，如何避免硬解析，尽量使用软解析呢？在 Oracle 中， 绑定变量 是它的一大特色。绑定变量就是在 SQL 语句中使用变量，通过不同的变量取值来改变 SQL 的执行结果。这样做的好处是能 提升软解析的可能性 ，不足之处在于可能会导致生成的执行计划不够优化，因此是否需要绑定变量还需要视情况而定。
举个例子，我们可以使用下面的查询语句：
SQL> select * from player where player_id = 10001;
你也可以使用绑定变量，如：
SQL> select * from player where player_id = :player_id;
这两个查询语句的效率在 Oracle 中是完全不同的。如果你在查询 player_id = 10001 之后，还会查询10002、10003 之类的数据，那么每一次查询都会创建一个新的查询解析。而第二种方式使用了绑定变量，那么在第一次查询之后，在共享池中就会存在这类查询的执行计划，也就是软解析。
因此，我们可以通过使用绑定变量来减少硬解析，减少 Oracle 的解析工作量。但是这种方式也有缺点，使用动态 SQL 的方式，因为参数不同，会导致 SQL 的执行效率不同，同时 SQL 优化也会比较困难。
Oracle的架构图：
小结：
Oracle 和 MySQL 在进行 SQL 的查询上面有软件实现层面的差异。Oracle 提出了共享池的概念，通过共享池来判断是进行软解析，还是硬解析。
4.3、数据库缓冲池(buffer pool)
InnoDB存储引擎是以页为单位来管理存储空间的，我们进行的增删改查操作其实本质上都是在访问页面（包括读页面、写页面、创建新页面等操作）。而磁盘 I/O 需要消耗的时间很多，而在内存中进行操作，效率则会高很多，为了能让数据表或者索引中的数据随时被我们所用，DBMS 会申请占用内存来作为数据缓冲池，在真正访问页面之前，需要把在磁盘上的页缓存到内存中的Buffer Pool之后才可以访问。
这样做的好处是可以让磁盘活动最小化，从而减少与磁盘直接进行 I/O 的时间。要知道，这种策略对提升 SQL 语句的查询性能来说至关重要。如果索引的数据在缓冲池里，那么访问的成本就会降低很多。
4.3.1、缓冲池vs查询缓存
- 缓冲池（Buffer Pool）
在InnoDB存储引擎中有一部分会放到内存中，缓冲池则占了这部分内存的大部分，他用来存储各种数据的缓存，
从图中，你能看到 InnoDB 缓冲池包括了数据页、索引页、插入缓冲、锁信息、自适应 Hash 和数据字典信息等。
缓存池的重要性：
对于使用InnoDB 作为存储引擎的表来说，不管是用于存储用户数据的索引（包括聚簇索引和二级索引），还是各种系统数据，都是以 页 的形式存放在 表空间中的，而所谓的表空间只不过是InnoDB对文件系统上一个或几个实际文件的抽象，也就是说我们的数据说到底还是存储在磁盘上的。但是各位也都知道，磁盘的速度慢跟乌龟一样，怎么能配得上“快如风，疾如电"的CPU呢?这里，缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟。所以InnoDB存储引擎在处理客户端的请求时，当需要访问某个页的数据时，就会把完整的页的数据全部加载到内存中,也就是说即使我们只需要访问一个页的一条记录，那也需要先把整个页的数据加载到内存中。将整个页加载到内存中后就可以进行读写访问了，在进行完读写访问之后并不着急把该页对应的内存空间释放掉，而是将其缓存起来，这样将来有请求再次访问该页面时，就可以省去磁盘IO的开销了。
缓存原则：
“位置 * 频次”这个原则，可以帮我们对 I/O 访问效率进行优化。
首先，位置决定效率，提供缓冲池就是为了在内存中可以直接访问数据。
其次，频次决定优先级顺序。因为缓冲池的大小是有限的，比如磁盘有 200G，但是内存只有 16G，缓冲池大小只有 1G，就无法将所有数据都加载到缓冲池里，这时就涉及到优先级顺序，会优先对使用频次高的热数据进行加载。
缓冲池的预读特性：
缓冲池的作用就是为了提升I/O效率，而我们进行读取数据的时候存在一个“局部性原理”，也就是说我们使用了一些数据，大概率还会使用它周围的一些数据，因此采用“预读”的机制提前加载，可以减少未来可能的磁盘I/O操作。
- 查询缓存
查询缓存是提前把查询结果缓存起来，这样下次不需要执行就可以直接拿到结果。需要说明的是，在MySQL 中的查询缓存，不是缓存查询计划，而是查询对应的结果。因为命中条件苛刻，而且只要数据表发生变化，查询缓存就会失效，因此命中率低。
4.3.2、缓冲池如何读取数据
缓冲池管理器会尽量将经常使用的数据保存起来，在数据库进行页面读操作的时候，首先会判断该页面是否在缓冲池中，如果存在就直接读取，如果不存在，就会通过内存或磁盘将页面存放到缓冲池中再进行读取。
如果我们执行 SQL 语句的时候更新了缓存池中的数据，那么这些数据会马上同步到磁盘上吗？
4.3.3、查看/设置缓冲池的大小
如果你使用的是MySQL MyISAM存储引擎，它只缓存索引，不缓存数据，对应的键缓存参数为key_buffer_size，你可以用它进行查看。
如果你使用的是InnoDB存储引擎，可以通过查看innodb_buffer_poll_size变量来查看缓冲池的大小
show variables like 'innodb_buffer_pool_size';
设置缓冲池的大小
set global innodb_buffer_pool_size = 268435456;
或者
[server]
innodb_buffer_pool_size = 268435456
4.3.4、多个Buffer Pool实例
Buffer Pool 本质是InnoDB向操作系统申请的一块连续的内存空间，在多线程环境下，访问Buffer Pool中的数据都需要 加锁 处理。在Buffer Pool 特别大而且多线程并发访问特别高的情况下，单一的Buffer Pool 可能会影响请求的处理速度。所以在Buffer Pool特别大的时候，我们可以把他们 差分成若干个小的Buffer Pool，每个Buffer Pool都称为一个 实例，他们都是独立的，独立的去申请内存空间，独立的管理各种链表。所以在多线程并发访问时并不会相互影响，从而提高并发处理能力。
# 我们可以在服务器启动的时候通过设置innodb_buffer_pool_instances的值来修改 Buffer Pool实例的个数
[server]
innodb_buffer_pool_instances = 2
何查看缓冲池的个数
show variables like 'innodb_buffer_pool_instances';
每个Buffer Pool实例实际占内存空间
innodb_buffer_pool_size/innodb_buffer_pool_instances
也就是总共的大小除以实例的个数，结果就是每个Buffer Pool实例占用的大小。
不过也不是说Buffer Pool实例创建的越多越好，分别管理各个Buffer Pool也是需要性能开销的，InnoDB规定:innodb_buffer_pool_size的值小于1G的时候设置多个实例是无效的L,InnoDB会默认把innodb_buffer_pool_instances的值修改为1。而我们鼓励在Buffer Pool大于或等于1G的时候设置多个Buffer Pool实例。
4.3.5、引申问题
Buffer Pool是MySQL内存结构中十分核心的一个组成，你可以先把它想象成一个黑盒子。
黑盒下的更新数据流程：
当我们查询数据的时候，会先去Buffer Pool中查询。如果Buffer Pool中不存在，存储引擎会先将数据从磁盘加载到Buffer Pool中，然后将数据返回给客户端;同理，当我们更新某个数据的时候，如果这个数据不存在于BufferPool，同样会先数据加载进来，然后修改修改内存的数据。被修改过的数据会在之后统一刷入磁盘。
这个过程看似没啥问题，实则是有问题的。假设我们修改Buffer Pool中的数据成功，但是还没来得及将数据刷入磁盘MySQL就挂了怎么办?按照上图的逻辑，此时更新之后的数据只存在于Buffer Pool中，如果此时MySQL宕机了，这部分数据将会永久地丢失;
我更新到一半突然发生错误了，想要回滚到更新之前的版本，该怎么办？连数据持久化的保证、事务回滚都做不到还谈什么崩溃恢复？
答案：Redo Log & Undo Log
五、存储引擎
为了管理方便 ，人们把连接管理、查询缓存、语法解析、查询优化这些并不涉及真实数据存储的功能划分为MySQL server的功能，把真是存取数据的功能划分为 存储引擎 的功能。所以在Mysql server完成了查询优化后，只需按照生成的执行计划调用底层存储引擎提供的API，获取到数据后返回给客户端就好了。
MySQL中提到了存储引擎的概念。简而言之，存储引擎就是指表的类型。其实存储引擎以前叫作表处理器，后来改名为 存储疫情，它的功能就是接受上层传下来的指令，然后对表中的数据进行提取或写入操作。
5.1、查看存储引擎
show engines;
# 或
show engines\G
查询结果显示，MySQL 8支持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参数：表示存储引擎是否支持事务处理的保存点: VES表示支持，NO表示不支持。也就是说，该存储引擎是否支持部分事务回滚。
5.2、设置系统默认的存储引擎
- 查看默认的存储引擎：
show variables like '%storage_engine%';
#或
SELECT @@default_storage_engine;
- 修改默认的存储引擎
如果在创建表的语句中没有显式指定表的存储引擎的话，那就会默认使用InnoDB作为表的存储引擎。
SET DEFAULT_STORAGE_ENGINE=MyISAM;
或者修改文件：
default-storage-engine=MyISAM
# 重启服务
systemctl restart
5.3、设置表的存储引擎
存储引擎是负责对表中的数据进行提取和写入工作的，我们可以为不同的表设置不同的存储引擎，也就是说不同的表可以有不同的物理存储结构，不同的提取和写入方式。
5.3.1、创建表时指定存储引擎
CREATE TABLE 表名(
建表语句;
) ENGINE = 存储引擎名称;
5.3.2、修改表的存储引擎
ALTER TABLE 表名 ENGINE = 存储引擎名称;
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，.等都在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_INCRENENT列属性。AUTO_INCREMENT列可以具有唯一索引或非唯一索引。尝试在任何其他列上创建索引会导致错误。
- Archive表适合日志和数据采集（档案）类应用;适合存储大量的独立的作为历史记录的数据。拥有很高的插入速度，但是对查询的支持较差。
- 下表展示了ARCHIVE存储引擎功能
| 特征 | 支持 |
|---|---|
| B树索引 | 不支持 |
| 备份/时间点恢复(在服务器中实现，而不是在存储引擎中) | 支持 |
| 集群数据库支持 | 不支持 |
| 聚集索引 | 不支持 |
| 压缩数据 | 支持 |
| 数据缓存 | 不支持 |
| 加密数据（加密功能在服务器中实现) | 支持 |
| 外键支持 | 不支持 |
| 全文检索索引 | 不支持 |
| 地理空间数据类型支持 | 支持 |
| 哈希索引 | 不支持 |
| 索引缓存 | 不支持 |
| 锁粒度 | 行锁 |
| MVCC | 不支持 |
| 存储限制 | 没有任何限制 |
| 交易 | 不支持 |
| 更新数据字典的统计信息 | 支持 |
5.4.4、Blackhole 引擎：丢弃写操作，读操作会返回空内容
- Blackhole引擎没有实现任何存储机制Ⅰ它会丢弃所有插入的数据，不做任何保存。
- 但服务器会记录Blackhole表的日志，所以可以用于复制数据到备库，或者简单地记录到日志。但这种应用方式会碰到很多问题，因此并不推荐。
5.4.5、CSV 引擎：存储数据时，以逗号分隔各个数据项
- CSV引擎可以将普通的CSV文件作为MySQL的表来处理，但不支持索引。
- CSv引擎可以作为一种数据交换的机制，非常有用。
- CSv存储的数据直接可以在操作系统里，用文本编辑器，或者excel读取
- 对于数据的快速导入、导出是有明显优势的。
创建CSV表时，服务器会创建一个纯文本数据文件，其名称以表名开头并带有.cSV扩展名。当你将数据存储到表中时，存储引擎将其以逗号分隔值格式保存到数据文件中。
使用案例如下
mysql> CREATE TABLE test (i INT NOT NULL，c CHAR(10)NOT NULL)ENGINE = CSv;
Query 0K,0 rows affected (0.06 sec)
mysql> INSERT INTO test VALUES( 1 , ' record one ' ),(2,'record two ' ) ;
Query oK，2 rows affected (0.05 sec)
Records : 2 Duplicates: 0warnings : 0
mysql> SELECT * FROM test ;
+---+-----------+
| i | c |
+---+-----------+
| 1 | record one|
| 2 | record two|
+---+-----------+
2rows in set (0.00 sec)
创建CSV表还会创建相应的元文件，用于存储表的状态和表中存在的行数了。此文件的名称与表的名称相同，后缀为CSM。
打开如下：
"1", "record one"
"2", "record two"
5.4.6、Memory 引擎：置于内存的表
Memory采用的逻辑介质是内存，响应速度很快，但是当mysqld守护进程崩溃的时候数据会丢失。另外，要求存储的数据是数据长度不变的格式，比如，Blob和Text类型的数据不可用(长度不固定的)。
主要特征:
- Memory同时支持哈希（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.5、MyISAM和InnoDB
MySQL5.5之前的默认存储引擎是MylSAM，5.5之后改为了InnoDB。
首先对于InnoDB存储引擎，提供了良好的事务管理、崩溃修复能力和并发控制。因为InnoDB存储引擎支持事务所以对于要求事务完整性的场合需要选择lnnoDB，比如数据操作除了插入和查询以外还包含有很多更新、删除操作，像财务系统等对数据准确性要求较高的系统。缺点是其读写效率稍差，占用的数据空间相对比较大。
其次对于MylSAM存储引擎，如果是小型应用，系统以读操作和插入操作为主，只有很少的更新、删除操作，并且对事务的要求没有那么高，则可以选择这个存储引擎。MylISAM存储引擎的优势在于占用空间小，处理速度快﹔缺点是不支持事务的完整性和并发性。
这两种引擎各有特点，当然你也可以在MysQL中，针对不同的数据表，可以选择不同的存储引擎。
| 对比项 | MyISAM | InnoDB |
|---|---|---|
| 外键 | 不支持 | 支持 |
| 事务 | 不支持 | 支持 |
| 行表锁 | 表锁，即使操作一条记录也会锁住整个表，不适合高并发的操作 | 行锁，操作时只锁某一行，不对其它行有影响，适合高并发的操作 |
| 缓存 | 只缓存索引，不缓存真实数据 | 不仅缓存索引还要缓存真实数据，对内存要求较高，而且内存大小对性能有决定性的影响 |
| 自带系统表使用 | Y | N |
| 关注点 | 性能：节省资源、消耗少、简单业务 | 事务：并发写、事务、更大资源 |
| 默认安装 | Y | Y |
| 默认使用 | N | Y |
六、索引的数据结构
6.1、为什么使用索引
索引是存储引擎用于快速找到数据记录的一种数据结构，就好比一本教课书的目录部分，通过目录中找到对应文章的页码，便可快速定位到需要的文章。MySQL中也是一样的道理，进行数据查找时，首先查看查询条件是否命中某条索引，符合则通过索引查找相关数据，如果不符合则需要全表扫描，即需要一条一条地查找记录，直到找到与条件符合的记录。
如上图所示，数据库没有索引的情况下，数据分布在硬盘不同的位置上面，读取数据时，摆臂需要前后摆动查找数据，这样操作非常消耗时间。如果数据顺序摆放，那么也需要从1到6行按顺序读取，这样就相当于进行了6次I0操作，依旧非常耗时。如果我们不借助任何索引结构帮助我们快速定位数据的话，我们查找Col2=89这条记录，就要逐行去查找、去比较。从Col 2=34开始，进行比较，发现不是，继续下一行。我们当前的表只有不到10行数据，但如果表很大的话，有上千万条数据，就意味着要做很多很多次磁盘I/0才能找到。现在要查找Col 2=89这条记录。CPU必须先去磁盘查找这条记录，找到之后加载到内存，再对数据进行处理。这个过程最耗时间的就是磁盘I/O(涉及到磁盘的旋转时间（速度快）），磁头的寻道时间（速度慢-费时）
假如给数据使用二叉树这样的数据结构进行存储
对字段Col2添加了索引，就相当于在硬盘上为Col 2维护了一个索引的数据结构，即这个二叉搜索树。二叉搜索树的每个结点存储的是（K，V)结构，key是Col 2，value是该key所在行的文件指针（地址)。比如:该二叉搜索树的根节点就是:(34,0x07)。现在对Col 2添加了索引，这时再去查找Col 2=89这条记录的时候会先去查找该二叉搜索树〈二叉树的遍历查找)。读34到内存，89>34；继续右侧数据，读89到内存，89 == 89;找到数据返回。找到之后就根据当前结点的value快速定位到要查找的记录对应的地址。我们可以发现，只需要查找两次就可以定位到记录的地址，查询速度就提高了。
这就是我们为什么要建索引，目的就是为了减少磁盘I/O的次数，加快查询速率。
6.2、索引及其优缺点
6.2.1 、索引概述
MySQL官方对索引的定义为： 索引（Index）是帮助MySQL高效获取数据的数据结构 。
索引的本质： 索引是数据结构。你可以简单理解为“排好序的快速查找数据结构”，满足特定查找算法。这些数据结构以某种方式指向数据， 这样就可以在这些数据结构的基础上实现高级查找算法。
索引是在存储引擎中实现的，因此每种存储引擎的索引不一定完全相同，并且每种存储引擎不一定支持所有索引类型。同时，存储引擎可以定义每个表的最大索引数和最大索引长度。所有存储引擎支持每个表至少16个索引，总索引长度至少为256字节。有些存储引擎支持更多的索引数和更大的索引长度。
6.2.2、优点
- 类似大学图书馆建书目索引，提高数据检索的效率，降低
数据库的IO成本，这也是创建索引最主要的原因。 - 通过创建唯一索引，可以保证数据库表中每一行
数据的唯一性。 - 在实现数据的参考完整性方面，可以
加速表和表之间的连接。换句话说，对于有依赖关系的子表和父表联合查询时，可以提高查询速度。 - 在使用分组和排序子句进行数据查询时，可以显著
减少查询中分组和排序的时间，降低了CPU的消耗。
6.2.3、缺点
- 创建索引和维护索引要
耗费时间，并且随着数据量的增加，所耗费的时间也会增加。 - 索引需要占
磁盘空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间存储在磁盘上，如果有大量的索引，索引文件就可能比数据文件更快达到最大文件尺寸。 - 虽然索引大大提高了查询速度，同时却会
降低更新表的速度。当对表中的数据进行增加、删除和修改的时候，索引也要动态地维护，这样就降低了数据的维护速度。
提示：索引可以提高查询的速度，但是会影响插入记录的速度。这种情况下，最好的办法是先删除表中的索引，然后插入数据，插入完成后在创建索引。
6.3、InnoDB中索引的推演
6.3.1、索引之前的查找
SELECT [列名列表] FROM 表名 WHERE 列名 = xxx;
1.在一个页中的查找
假设目前表中的记录比较少，所有的记录都可以被存放在一个页中，在查找记录的时候可以根据搜索条件的不同分为两种情况：
- 以主键为搜索条件
- 可以在页目录中使用
二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录。
- 可以在页目录中使用
- 以其他列作为搜索条件
- 因为在数据页中并没有对非主键建立所谓的页目录，所以我们无法通过二分法快速定位相应的槽。这种情况下只能从最小记录开始依次遍历单链表中的每条记录，然后对比每条记录是不是符合搜索条件。很显然，这种查找的效率是非常低的。
2.在很多页中查找
大部分情况下我们表中存放的记录都是非常多的，需要好多的数据页来存储这些记录。在很多页中查找记录的话可以分为两个步骤：
- 定位到记录所在的页。
- 从所在的页内查找相应的记录。
在没有索引的情况下，不论是根据主键列或者其他列的值进行查找，由于我们并不能快速的定位到记录所在的页，所以只能从第一个页沿着双向链表一直往下找，在每一个页中根据我们上面的查找方式去查找指定的记录。因为要遍历所有的数据页，所以这种方式显然是超级耗时的。
6.3.2、设计索引
# 建一个表
mysql> CREATE TABLE index_demo(
-> c1 INT,
-> c2 INT,
-> c3 CHAR(1),
-> PRIMARY KEY(c1)
-> ) ROW_FORMAT = Compact;
这个新建的index_demo表中有2个INT类型的列，1个CHAR(1)类型的列，而且我们规定了c1列为主键，这个表使用Compact行格式来实际存储记录的。这里我们简化了index_demo表的行格式示意图：
-
record_type：记录头信息的一项属性，表示记录的类型，0表示普通记录、1表示目录项记录、2表示最小记录、3表示最大记录。 -
next_record：记录头信息的一项属性，表示下一条地址相对于本条记录的地址偏移量，我们用箭头来表明下一条记录是谁。 -
各个列的值：这里只记录在index_demo表中的三个列，分别是c1、c2和c3。 -
其他信息：除了上述3种信息以外的所有信息，包括其他隐藏列的值以及记录的额外信息。
将记录格式示意图的其他信息项暂时去掉并把它竖起来的效果就是这样：
把一些记录放到页里的示意图就是：
6.3.2.1、一个简单的索引设计方案
我们在根据某个搜索条件查找一些记录时为什么要遍历所有的数据页呢？因为各个页中的记录并没有规律，我们并不知道我们的搜索条件匹配哪些页中的记录，所以不得不依次遍历所有的数据页。所以如果我们想快速的定位到需要查找的记录在哪些数据页中该咋办？我们可以为快速定位记录所在的数据页而建立一个目录，建这个目录必须完成下边这些事：
- 下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。
假设:每个数据页最多能存放3条记录（实际上一个数据页非常大，可以存放下好多记录)。有了这个假设之后我们向index_demo表插入3条记录
mysql> INSERT INTO index_demo VALUES(1,4, 'u'),(3,9,'d'),(5,3,'y');
Query OK, 3 rows affected(0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
那么这些记录已经按照主键值的大小串联成一个单向链表了，
从图中可以看出来，index_demo 表中的3条记录都被插入到编号为10的数据页中了。此时我们再来插入一条记录：
mysql> INSERT INTO index_demo VALUES(4,4,'a');
因为页10最多只能放3条记录，所以我们不得不再分配一个新页
注意，新分配的数据页编号可能并不是连续的。它们只是通过维护着上一个页和下一个页的编号而建立了链表关系。另外，页10中用户记录最大的主键值是5，而页28中有一条记录的主键值是4，因为5>4，所以这就不符合下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值的要求，所以在插入主键值为4的记录的时候需要伴随着一次记录移动，也就是把主键值为5的记录移动到页28中，然后再把主键值为4的记录插入到页10中，这个过程的示意图如下:
这个过程表明了在对页中的记录进行增删改操作的过程中，我们必须通过一些诸如记录移动的操作来始终保证这个状态一直成立:下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。这个过程我们称为页分裂。
- 给所有的页建立一个目录项。
由于数据页的编号可能是不连续的，所以在向index_demo表中插入许多条记录后，可能是这样的效果:
因为这些16KB的页在物理存储上是不连续的，所以如果想从这么多页中根据主键值快速定位某些记录所在页，我们需要给它们做个目录，每个页对应一个目录项，每个目录项包括下边两个部分:
- 页的用户记录中最小的主键值，我们用key来表示。
- 页号，我们用page_no表示。
所有我们为上边几个页做好的目录就像这个样子：
以页28为例，它对应目录项2，这个目录项中包含着该页的页号28以及该页中用户记录的最小主键值5。我们只需要把几个目录项在物理存储器上连续存储（比如：数组），就可以实现根据主键值快速查找某条记录的功能了。比如：查找主键值为20的记录，具体查找过程分两步：
-
先从目录项中根据
二分法快速确定出主键值为20的记录在目录项3中（因为 12 < 20 < 209 ），它对应的页是页9。 -
再根据前边说的在页中查找记录的方式去
页9中定位具体的记录。
至此，针对数据页做的简易目录就搞定了。这个目录有一个别名，称为索引。
6.3.2.2、InnoDB中的索引方案
① 迭代1次：目录项纪录的页
# 上边称为一个简易的索引方案，是因为我们为了在根据主键值进行查找时使用二分法快速定位具体的目录项而假设所有目录项都可以在物理存储器上连续存储，但是这样做有几个问题:
- InnoDB是使用页来作为管理存储空间的基本单位，最多能保证16KB的连续存储空间，而随着表中记录数量增多，需要非常大的连续的存储空间才能把所有的目录项都放下，这对记录数量非常多的表是不现实的。
- 我们时常会对记录进行增删，假设我们把页28中的记录都删除了，那意味着目录项2也就没有存在的必要了，这就需要把目录项2后的目录项都向前移动一下，这样牵一发而动全身的操作效率很差。
所以，我们需要一种可以灵活管理所有目录项的方式。我们发现目录项其实长得跟我们的用户记录差不多，只不过目录项中的两个列是主键和页号而已，为了和用户记录做一下区分，我们把这些用来表示目录项的记录称为目录项己录。那InnoDB怎么区分一条记录是普通的 用户记录还是目录项记录呢？使用记录头信息里的 record_type 属性，它的各个取值代表的意思如下:
- 0：普通的用户记录
- 1：目录项记录
- 2：最小记录
- 3：最大记录
把前边使用到的目录项放到数据页中：
从图中可以看出来，我们新分配了一个编号为30的页来专门存储目录项记录。这里再次强调目录项记录和普通的用户记录的 不同点 ：
-
目录项记录的record_type值是1，而普通用户记录的record_type值是0。 - 目录项记录只有
主键值和页的编号两个列，而普通的用户记录的列是用户自己定义的，可能包含很多列，另外还有InnoDB自己添加的隐藏列。 - 了解：记录头信息里还有一个叫
min_rec_mask的属性，只有在存储目录项记录的页中的主键值最小的目录项记录的min_rec_mask值为1，其他别的记录的min_rec_mask值都是0。
相同点： 两者用的是一样的数据页，都会为主键值生成Page Directory（页目录），从而在按照主键值进行查找时可以使用二分法来加快查询速度。
现在以查找主键为20的记录为例，根据某个主键值去查找记录的步骤就可以大致拆分成下边两步：
-
先到存储
目录项记录的页，也就是页30中通过二分法快速定位到对应目录项，因为 12 < 20 < 209 ，所以定位到对应的记录所在的页就是页9。 -
再到存储用户记录的页9中根据
二分法快速定位到主键值为20的用户记录。
② 迭代2次：多个目录项纪录的页
虽然 目录项记录 中只存储主键值和对应的页号，比用户记录需要的存储空间小多了，但是不论怎么说一个页有16KB大小，能存放的目录项记录也是有限的，如果表中的数据太多，以至于一个数据页不足以存放所有的目录项记录，如何处理呢?
这里假设一个存储目录项记录的页最多只能存放4条目录项记录，如果此时我们再向上图中插入一条主键值为320的用户记录的话，那就需要分配一个新的存储目录项记录的页:
从图中可以看出，我们插入了一条主键值为320的用户记录之后需要两个新的数据页：
- 为存储该用户记录而新生成了
页31。 - 因为原先存储目录项记录的
页30的容量已满（我们前边假设只能存储4条目录项记录），所以不得不需要一个新的页32来存放页31对应的目录项。
现在因为存储目录项记录的页不止一个，所以如果我们想根据主键值查找一条用户记录大致需要3个步骤，以查找主键值为20的记录为例：
-
确定
目录项记录页我们现在的存储目录项记录的页有两个，即页30和页32，又因为页30表示的目录项的主键值的范围是 [1, 320) ，页32表示的目录项的主键值不小于 320 ，所以主键值为20的记录对应的目录项记录在页30中。 -
通过目录项记录页
确定用户记录真实所在的页。在一个存储目录项记录的页中通过主键值定位一条目录项记录的方式说过了。 -
在真实存储用户记录的页中定位到具体的记录。
③ 迭代3次：目录项记录页的目录页
如图，我们生成了一个存储更高级目录项的页33，这个页中的两条记录分别代表页30和页32，如果用户记录的主键值在[1, 320)之间，则到页30中查找更详细的目录项记录，如果主键值不小于320的话，就到页32中查找更详细的目录项记录。
随着表中记录的增加，这个目录的层级会继续增加，如果简化一下，就是下面这种图
这个数据结构，它的名称是B+树。
④ B+Tree
不论是存放用户记录的数据页，还是存放目录项记录的数据页，我们都把它们存放到B+树这个数据结构中了，所以我们也称这些数据页为节点。从图中可以看出，我们的实际用户记录其实都存放在B+树的最底层的节点上，这些节点也被称为叶子节点，其余用来存放目录项的节点称为非叶子节点或者内节点，其中B+树最上边的那个节点也称为根节点。
一个B+树的节点其实可以分成好多层，规定最下边的那层，也就是存放我们用户记录的那层为第0层，之后依次往上加。真实环境中一个页存放的记录数量是非常大的，假设所有存放用户记录的叶子节点代表的数据页可以存放100条用户记录，所有存放目录项记录的内节点代表的数据页可以存放1000条目录项记录，那么：
- 如果B+树只有1层，也就是只有1个用于存放用户记录的节点，最多能存放
100条记录。 - 如果B+树有2层，最多能存放
1000×100=10,0000条记录。 - 如果B+树有3层，最多能存放
1000×1000×100=1,0000,0000条记录。 - 如果B+树有4层，最多能存放
1000×1000×1000×100=1000,0000,0000条记录。相当多的记录！！！
所以一般情况下，我们用到的B+树都不会超过4层，那通过主键值去查找某条记录最多只需要做4个页面内的查找（查找3个目录项页和一个用户记录页），又因为在每个页面内有所谓的Page Directory（页目录），所以在页面内也可以通过二分法实现快速定位记录。
6.3.3、常见索引概念
1、聚簇索引
聚簇索引并不是一种单独的索引类型，而是一种数据存储方式（所有的用户记录都存储在叶子节点），也就是所谓的 索引即数据，数据即索引。
特点：
-
使用记录主键值的大小进行记录和页的排序，这包括三个方面的含义：
-
页内的记录是按照主键的大小顺序排成一个单向链表。 -
各个存放
用户记录的页也是根据页中用户记录的主键大小顺序排成一个双向链表。 -
存放
目录项记录的页分为不同的层次，在同一层次中的页也是根据页中目录项记录的主键大小顺序排成一个双向链表。
-
-
B+树的
叶子节点存储的是完整的用户记录。所谓完整的用户记录，就是指这个记录中存储了所有列的值（包括隐藏列）。
优点：
-
数据访问更快，因为聚簇索引将索引和数据保存在同一个B+树中，因此从聚簇索引中获取数据比非聚簇索引更快 - 聚簇索引对于主键的
排序查找和范围查找速度非常快 - 按照聚簇索引排列顺序，查询显示一定范围数据的时候，由于数据都是紧密相连，数据库不用从多个数据块中提取数据，所以
节省了大量的io操作。
缺点：
-
插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。因此，对于InnoDB表，我们一般都会定义一个 自增ID列为主键 -
更新主键的代价很高，因为将会导致被更新的行移动。因此，对于InnoDB表，我们一般定义 主键为不可更新 -
二级索引访问需要两次索引查找，第一次找到主键值，第二次根据主键值找到行数据
限制：
- 对于Mysql数据库目前只有InnoDB数据引擎支持聚簇索引，而MyISAM并不支持聚簇索引。
- 由于数据物理存储排序方式只有一种，所以每个MySQL的 表只能有一个聚簇索引。 一般情况下就是该表的主键。
- 如果没有定义主键，InnoDB会选择 非空的唯一索引 代替。如果没有这样的索引，InnoDB会隐式的定义一个主键来作为聚簇索引。
- 为了充分利用聚簇索引的聚簇的特性，索引InnoDB表的主键列尽量选用有序的顺序id，而不建议用无序的id，比如UUID，MD5，HASH、字符串列作为主键无法保证数据的顺序增长。
2、二级索引（辅助索引、非聚簇索引）
聚簇索引只能在搜索条件为主键值时才能发挥作用，因为B+树中的数据都是按照主键进行排序的。如果想以别的列作为搜索条件该怎么办？
答案：可以多建几棵B+树，不同的B+树中的数据采用不同的排序规则。
这个B+树与聚簇索引有几处不同：
- 使用记录C2列的大小进行记录和页的排序，这包括三个方面的含义：
- 页内的记录是按照c2列的大小顺序排成一个 单向链表。
- 各个存放 用户记录的页 也是根据页中记录的c2列大小顺序排成一个 双向链表。
- 存放 目录项记录的页 分为不同的层次，在同一层次中的页也是根据页中目录项记录的c2列大小顺序排成一个 双向链表。
- B+ 树的叶子节点存储的并不是完整的用户记录，而只是c2列 + 主键这两个列的值。
- 目录项记录中不再是 主键+页号 的搭配，而变成了 C2列+页号的搭配。
所有如果想通过c2列的值查找某些记录的话就可以使用刚刚建好的这个B+树。
# 以查找c2列的值为4的记录为例，查找过程如下：
1. 确定目录项记录页
根据 根页面，也就是页44，可以快速定位到 目录项记录 所在的页为 页42（因为2< 4 <9）
2. 通过目录项记录页确定用户记录真实所在的页。
在页42中可以快速定位到实际存储用户记录的页，但是由于c2列并没有唯一性约束，所以c2列值为4的记录可能分布在多个数据页中，又因为2<4 ≤ 4, 所以确定实际存储用户记录的页在 页34 和页34中。
3. 在真实存储用户记录的页中定位到具体的记录。
到页34和页34中定位到具体的记录。
4. 但是这个B+树的叶子节点中的记录只存储了c2和c1（主键）两个列，所以我们必须再根据主键值去聚簇索引中再查找一遍完整的用户记录。
概念：回表
我们根据这个以c2列大小排序的B+树只能确定我们要查找记录的主键值，所以如果我们想根据c2列的值查找到完整的用户记录的话，仍然需要到聚簇索引中再查一遍，这个过程称为回表。也就是根据c2列的值查询一条完整的用户记录需要使用到2棵B+树！
# 问题:为什么我们还需要一次回表操作呢?直接把完整的用户记录放到叶子节点不OK吗?
# 回答:
如果把完整的用户记录放到叶子节点是可以不用回表。但是太占地方了，相当于每建立一棵B+树都需要把所有的用户记录再都拷贝一遍，这就有点太浪费存储空间了。
因为这种按照非主键列建立的B+树需要一次回表操作才可以定位到完整的用户记录，所以这种B+树也被称为二级索引(英文名secondary index )，或者辅助索引。由于我们使用的是c2列的大小作为B+树的排序规则，所以我们也称这个B+树是为c2列建立的索引。
非聚簇索引的存在不影响数据在聚簇索引中的组织，所以一张表可以有多个非聚簇索引。
小结：聚簇索引与非聚簇索引的原理不同，在使用上也有一些区别：
- 聚簇索引的叶子节点存储的就是我们的 数据记录，非聚簇索引的叶子节点存储的是数据位置。非聚簇索引不会影响数据表的物理存储顺序；
- 一个表只能有一个聚簇索引，因为只能有一种排序存储的方式，但可以有多个非聚簇索引，也就是多个索引目录提供数据检索。
- 使用聚簇索引的时候，数据的查询效率高，但如果对数据进行插入，删除，更新等操作，效率会比非聚簇索引低。
3、联合索引
也可以同时为多个列建立索引，比方说想让B+树按照c2和c3列的大小进行排序，这个包含两层含义：
-
先把各个记录和页按照c2列进行排序。
-
在记录的c2列相同的情况下，采用c3列进行排序
需要注意：
- 每条目录项记录都由c2、c3、页号三部分组成，各条记录先按照c2列的值进行排序，如果记录的c2列相同，则按照c3列的值进行排序。
- B+树 叶子节点 处的用户记录有c2、c3和主键c1列组成。
注意一点，以c2和c3列的大小为排序规则建立的B+树称为联合索引，本质上也是一个二级索引。它的意思与分别为c2和c3列分别建立索引的表述是不同的，不同点如下：
-
建立
联合索引只会建立如上图一样的1棵B+树。 -
为c2和c3列分别建立索引会分别以c2和c3列的大小为排序规则建立2棵B+树。
6.3.4、InnoDB的B+树索引的注意事项
1、根页面位置万年不动
前边为了大家理解上的方便，先把存储用户记录的叶子节点都画出来，然后接着画存储目录项记录的内节点，实际上B+树的形成过程是这样的：
- 每当为某个表创建一个B+树索引（聚簇索引不是人为创建的，默认就有）的时候，都会为这个索引创建一个
根节点页面。最开始表中没有数据的时候，每个B+树索引对应的根节点中既没有用户记录，也没有目录项记录。 - 随后向表中插入用户记录时，先把用户记录存储到这个
根节点中。 - 当根节点中的可用
空间用完时继续插入记录，此时会将根节点中的所有记录复制到一个新分配的页，比如页a中，然后对这个新页进行页分裂的操作，得到另一个新页，比如页b。这时新插入的记录根据键值（也就是聚簇索引中的主键值，二级索引中对应的索引列的值）的大小就会被分配到页a或者页b中，而根节点便升级为存储目录项记录的页。
这个过程特别注意的是：一个B+树索引的根节点自诞生之日起，便不会再移动。这样只要我们对某个表建立一个索引，那么它的根节点的页号便会被记录到某个地方，然后凡是InnoDB存储引擎需要用到这个索引的时候，都会从那个固定的地方取出根节点的页号，从而来访问这个索引。
2、内节点中目录项记录的唯一性
B+树索引的内节点中目录项记录的内容是索引列+页号的搭配，但是这个搭配对于二级索引来说有点不严谨。还拿index_demo表为例，假设这个表中的数据是这样的：
| c1 | c2 | c3 |
|---|---|---|
| 1 | 1 | ‘u’ |
| 3 | 1 | ‘d’ |
| 5 | 1 | ‘y’ |
| 7 | 1 | ‘a’ |
如果二级索引中目录项的内容只是索引号+页号的搭配的话，那么为c2列建立索引后的B+树应该长这样：
如果我们想要新插入一行记录，其中c1、c2、c3的值分别是：9、1、c，那么在修改这个为c2列建立的二级索引对应的B+树时便碰到了个大问题：由于页3中存储的目录项记录是由c2列+页号的值构成的，页3中的两条目录项记录对应的c2列的值都是1，那么我们这条新插入的记录到底应该放在页4中，还是应该放在页5中啊？答案是：对不起，懵了。
为了让新插入记录能找到自己在哪个页里，我们需要 保证在B+树的同一层内节点的目录项记录除页号这个字段以外是唯一的。 所以对于二级索引的内节点的目录项记录的内容实际上是由三个部分构成的：
- 索引列的值
- 主键值
- 页号
也就是我们把主键值也添加到二级索引内节点中的目录项记录了，这样就能保证B+树每一层节点中各条目录项记录除页号这个字段外是唯一的，所以我们为c2列建立二级索引后的示意图实际上应该是这样子的：
这样我们再插入记录(9, 1, 'c')时，由于页3中存储的目录项记录是由c2列+主键+页号的值构成的，可以先把新记录的c2列的值和页3中各目录项记录的c2列的值作比较，如果c2列的值相同的话，可以接着比较主键值，因为B+树同一层中不同目录项记录的c2列+主键的值肯定是不一样的，所以最后肯定能定位唯一的一条目录项记录，在本例中最后确定新记录应该被插入到页5中。
3、一个页面最少可以存储2条记录
一个B+树只需要很少的层级就可以轻松存储数亿条记录，查询速度相当不错！这是因为B+树本质上就是一个大的多层级目录，每经过一个目录时都会过滤掉许多无效的子目录，直到最后访问的存储真实数据的目录。那如果一个大的目录中只存放一个子目录是个啥效果呢？那就是目录层级非常非常非常多，而且最后的那个存放真实数据的目录中存放一条记录。费了半天劲只能存放一条真实的用户记录？所以InnoDB的一个数据页至少可以存放两条记录
6.4、MyISAM中的索引方案
B树索引适用存储引擎如表所示：
| 索引/存储引擎 | MyISAM | InnoDB | Memory |
|---|---|---|---|
| B-Tree索引 | 支持 | 支持 | 支持 |
即使多个存储引擎支持同一种类型的索引，但是他们的实现原理也是不同的。Innodb和MyISAM默认的索引是Btree索引；而Memory默认的索引是Hash索引。
MyISAM引擎使用B+Tree作为索引结构，叶子节点的data域存放的是数据记录的地址。
6.4.1、MyISAM索引的原理
InnoDB中索引即数据，也就是聚簇索引的那颗B+树的叶子节点中已经把所有完整的用户记录都包含了，而MyISAM的索引方案虽然也使用树形结构，但是却将索引和数据分开存储：
- 将表中的记录 按照记录的插入顺序 单独存储在一个文件中，称之为数据文件。这个文件并不划分为若干个数据也，有多少记录将往这个文件中塞多少记录就成了。由于在插入数据的时候并 没有刻意按照主键大小排序，所以我们并不能在这些数据上使用二分法进行查找。
- 使用MyISAM存储引擎的表会把索引信息另外存储到一个称为索引文件的另一文件中。MyISAM会单独为表的主键创建一个索引，只不过在索引的叶子节点中存储的不是完整的用户记录，而是 主键值+数据记录地址 的组合。
MYISAM 的索引文件仅仅保存数据记录的地址。 在MYISAM中，主键索引和二级索引（Secondary key）在结构中没有任何区别，只是主键索引要求key是唯一的 ，而二级索引的key可以重复。如果在col2上建立一个二级索引，则此索引的结构如下所示：
同样也是一颗B+Tree，data域保存数据记录的地址。-因此，MYISAM中索引检索的算法为：首先按照B+Tree搜索算法搜索索引，如果指定的key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。
6.4.2、MyISAM与 InnoDB对比
MyISAM的索引方式都是“非聚簇”的，与InnoDB包含1个聚簇索引是不同的。
两种引擎中索引的区别：
① 在InnoDB存储引擎中，我们只需要根据主键值对聚簇索引进行一次查找就能找到对应的记录，而在MyISAM中却需要进行一次回表操作，意味着MyISAM中建立的索引相当于全部都是二级索引。
② InnoDB的数据文件本身就是索引文件，而MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。
③ InnoDB的非聚簇索引data域存储相应记录主键的值，而MyISAM索引记录的是地址。换句话说，InnoDB的所有非聚簇索引都引用主键作为data域。
④ MyISAM的回表操作是十分快速的，因为是拿着地址偏移量直接到文件中取数据的，反观InnoDB是通过获取主键之后再去聚簇索引里找记录，虽然说也不慢，但还是比不上直接用地址去访问。
⑤ InnoDB要求表必须有主键（MyISAM可以没有）。如果没有显式指定，则MySQL系统会自动选择一个可以非空且唯一标识数据记录的列作为主键。如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整型。
小结：
- 为什么不建议使用过长的字段作为主键，因为所有二级索引都引用主键索引，过长的主键索引会令二级索引变得过大。
- 用非单调的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一个B+Tree，非单调的主键会造成在插入新纪录时，数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。
6.5、索引的代价
索引是个好东西，可不能乱建，它在空间和时间上都会有消耗：
- 空间上的代价
每建立一个索引都要为它建立一棵B+树，每一棵B+树的每一个节点都是一个数据页，一个页默认会占用16KB的存储空间，一棵很大的B+树由许多数据页组成，那就是很大的一片存储空间。
- 时间上的代价
每次进行增、删、改操作时，都需要去修改各个B+树索引。而B+树每层节点都是按照索引列的值从小到大的顺序排序而组成了双向链表。不论是叶子节点中的记录，还是内节点中的记录（也就是不论是用户记录还是目录项记录）都是按照索引列的值从小到大的顺序而形成了一个单向链表。而增、删、改操作可能会对节点和记录的排序造成破坏，所以存储引擎需要额外的时间进行一些记录移位，页面分裂、页面回收等操作来维护好节点和记录的排序。如果建了许多索引，每个索引对应的B+树都要进行相关的维护操作，会给性能拖后腿。
6.6、MySQL数据结构选择的合理性
从MysQL的角度讲，不得不考虑一个现实问题就是磁盘IO。如果我们能让索引的数据结构尽量减少硬盘的IO操作，所消耗的时间也就越小。可以说，磁盘的I/0操作次数对索引的使用效率至关重要。
查找都是索引操作，一般来说索引非常大，尤其是关系型数据库，当数据量比较大的时候，索引的大小有可能几个G甚至更多，为了减少索引在内存的占用，数据库索引是存储在外部磁盘上的。当我们利用索引查询的时候，不可能把整个索引全部加载到内存，只能逐一加载，那么MySQL衡量查询效率的标准就是磁盘IO次数。
6.6.1、全表遍历
6.6.2、Hash结构
Hash本身是一个函数，又被称为散列函数，它可以帮助我们大幅提升检索数据的效率。
Hash算法是通过某种确定性的算法（比如MD5、SHA1、SHA2、SHA3）将输入转变为输出。相同的输入永远可以得到相同的输出，假设输入内容有微小偏差，在输出中通常会有不同的结果。
加速查找速度的数据结构，常见的有两类:
（1）树，例如平衡二叉搜索树，查询/插入/修改/删除的平钧时间复杂度都是0(log2N) ;
（2）哈希，例如HashMap，查询/插入/修改/删除的平均时间复杂度都是0( 1);
采用Hash进行检索效率非常高，基本上一次检索就可以找到数据，而B+树需要自顶向下一次查找，多次访问节点才能找到数据，中间需要多次I/O操作，从效率来说 Hash比B+树更快。
在Hash的方式下，一个元素k处于h(k)中，即利用哈希函数h，根据关键字k计算出槽的位置。函数h将关键字域映射到哈希表T[0…m-1]的槽位上。
Hash结构效率高，为什么索引结构要设计成树型呢？
- Hash索引仅能满足（=) (◇)和IN查询。如果进行范围查询，哈希型的索引，时间复杂度会退化为o(n);而树型的“有序"”特性，依然能够保持o(log2N)的高效率。
- Hash 索引还有一个缺陷，数据的存储是没有顺序的，在ORDER BY的情况下，使用Hash索引还需要对数据重新排序。
- 对于联合索引的情况，Hash值是将联合索引键合并后一起来计算的，无法对单独的一个键或者几个索引键进行查询。
- 对于等值查询来说，通常Hash 索引的效率更高，不过也存在一种情况，就是索引列的重复值如果很多，效率就会降低。这是因为遇到Hash冲突时，需要遍历桶中的行指针来进行比较，找到查询的关键字，非常耗时。所以，Hash索引通常不会用到重复值多的列上，比如列为性别、年龄的情况等。
Hash索引使用存储引擎：
| 索引/存储引擎 | MyISAM | InnoDB | Memory |
|---|---|---|---|
| HASH索引 | 不支持 | 不支持 | 支持 |
Hash索引的适用性:
Hash索引存在着很多限制，相比之下在数据库中B+树索引的使用面会更广，不过也有一些场景采用Hash索引I效率更高，比如在键值型（Key-value）数据库中， Redis存储的核心就是 Hash表。
MysQL中的Memory存储引擎支持 Hash存储，如果我们需要用到查询的临时表时，就可以选择Memory存储引擎，把某个字段设置为Hash索引，比如字符串类型的字段，进行Hash 计算之后长度可以缩短到几个字节。当字段的重复度低，而且经常需要进行等值查询的时候，架用Hash索引是个不错的选择。
另外，InnoDB本身不支持 Hash索引，但是提供**自适应Hash索引(**Adaptive Hash lndex)。如果某个数据经常被访问，当满足一定条件的时候，就会将这个数据页的地址存放到Hash表中。这样下次查询的时候，就可以直接找到这个页面的所在位置。这样让B+树也具备了Hash索引的优点。
采用自适应Hash索引目的是方便根据SQL的查询条件加速定位到叶子节点，特别是当B+树比较深的时候，通过自适应Hash索引可以明显提高数据的检索效率。
# 查看是否开启了自适应 Hash
show variables like '%adaptive_hash_index';
6.6.3、二叉搜索树
如果利用二叉树作为索引结构，那么磁盘的IO次数和索引树的高度是相关的。
1. 二叉搜索树的特点
- 一个节点只能有两个子节点，也就是一个节点度不能超过2
- 左子节点<根节点；右子节点>=根节点
2. 查找规则
- 如果key大于根节点，则在右子树中进行查找；
- 如果key小于根节点，则在左子树中进行查找；
- 如果key等于根节点，就返回根节点
但存在特殊情况，就是有时候二叉树的深度非常大。
这棵树也属于二叉查找树，但是性能上已经退化成了一条链表了，查找数据的时间复杂度变成了O(n)，
为了提高查询效率，就需要减少磁盘IO数。为了减少磁盘IO的次数，就需要尽量降低树的高度，需要把原来“瘦高”的树结构变的“矮胖”，树的每层的分叉越多越好。
6.6.4、AVL树
为了解决上面二叉查找树退化成链表的问题，人们提出了 平衡二叉搜索树（Balanced Binary Tree）,又称为AVl树，它在二叉搜索树的基础上添加了约束：
# 它是一颗空树 或 它的左右两个子树的高度差的绝对值不超过1，并且左右两个子树都是一颗平衡二叉树
# 常见的平衡二叉树有很多种，包括了 平衡二叉搜索树、红黑树、树堆、伸展树。平衡二叉树是最早提出来的自平衡二叉搜索树，当我们提到平衡二叉树时一般指的就是平衡二叉搜索树。
如果我们利用二叉树作为索引结构，那么磁盘的IO次数和索引树的高度是相关的。
针对同样的数据，如果我们把二叉树改成M 叉树（M>2）呢？当 M=3 时，同样的 31 个节点可以由下面的三叉树来进行存储：
6.6.5、B-Tree
B树的英文是Balance Tree，也就是 多路平衡查找树，简写为B-Tree（横杠表示这两个单词连起来，不是减号）。
它的高度远小于平衡二叉树的高度。
B 树的结构如下图所示：
B树作为多路平衡查找树，它的每一个节点最多可以包括M个子节点，`M称为B树的阶`。每个磁盘块中包括了关键字和子节点的指针。如果一个磁盘块中包括了x个关键字，那么指针数就是×+1。对于一个100阶的B树来说，如果有3层的话最多可以存储约100万的索引数据。对于大量的索引数据来说，采用B树的结构是非常适合的，因为树的高度要远小于二叉树的高度。
一个 M 阶的 B 树（M>2）有以下的特性：
-
根节点的儿子数的范围是 [2,M]。
-
每个中间节点包含 k-1 个关键字和 k 个孩子，孩子的数量 = 关键字的数量 +1，k 的取值范围为[ceil(M/2), M]。
-
叶子节点包括 k-1 个关键字（叶子节点没有孩子），k 的取值范围为 [ceil(M/2), M]。
-
假设中间节点节点的关键字为：Key[1], Key[2], …, Key[k-1]，且关键字按照升序排序，即 Key[i] <Key[i+1]。此时 k-1 个关键字相当于划分了 k 个范围，也就是对应着 k 个指针，即为：P[1], P[2], …,P[k]，其中 P[1] 指向关键字小于 Key[1] 的子树，P[i] 指向关键字属于 (Key[i-1], Key[i]) 的子树，P[k]指向关键字大于 Key[k-1] 的子树。
-
所有叶子节点位于同一层。
# 上面那张图所表示的 B 树就是一棵 3 阶的 B 树。我们可以看下磁盘块 2，里面的关键字为（8，12），它有 3 个孩子 (3，5)，(9，10) 和 (13，15)，你能看到 (3，5) 小于 8，(9，10) 在 8 和 12 之间，而 (13，15)大于 12，刚好符合刚才我们给出的特征。
然后我们来看下如何用 B 树进行查找。假设我们想要`查找的关键字是 9`，那么步骤可以分为以下几步：
1.我们与根节点的关键字 (17，35）进行比较，9 小于 17 那么得到指针 P1；
2.按照指针 P1 找到磁盘块 2，关键字为（8，12），因为 9 在 8 和 12 之间，所以我们得到指针 P2；
3.按照指针 P2 找到磁盘块 6，关键字为（9，10），然后我们找到了关键字 9。
B 树的搜索过程中，比较的次数并不少，但如果把数据读取出来然后在内存中进行比较，这个时间就是可以忽略不计的。而读取磁盘块本身需要进行 I/O 操作，消耗的时间比在内存中进行比较所需要的时间要多，是数据查找用时的重要因素。B 树相比于平衡二叉树来说磁盘 I/O 操作要少，在数据查询中比平衡二叉树效率要高。所以只要树的高度足够低，IO次数足够少，就可以提高查询性能。
小结：
- B树在插入和删除节点的时候如果导致树不平衡，就通过自动调整节点的位置来保持树的自平衡。
- 关键字集合分布在整棵树中，即叶子节点和非叶子节点都存放数据。搜索有可能在非叶子节点结束
- 其搜索性能等价于在关键字全集内做一次二分查找。
6.6.6、B+Tree
B+树也是一种多路搜索树，基于B树做了改进，主流的DBMS都支持B+树的索引方式，比如MySQL，相比于B-Tree，B+Tree适合文件索引系统。
B+树和 B-树的差异：
-
有 k 个孩子的节点就有 k 个关键字。也就是孩子数量 = 关键字数，而 B 树中，孩子数量 = 关键字数+1。
-
非叶子节点的关键字也会同时存在在子节点中，并且是在子节点中所有关键字的最大（或最小）。
-
非叶子节点仅用于索引，不保存数据记录，跟记录有关的信息都放在叶子节点中。而 B 树中，
非叶子节点既保存索引，也保存数据记录。 -
所有关键字都在叶子节点出现，叶子节点构成一个有序链表，而且叶子节点本身按照关键字的大小从小到大顺序链接。
# B+树和B树的查询过程差不多，根本差异在于B+树的中间节点并不直接存储数据，这样有什么好处？
- 首先，B+树查询效率更稳定。因为B+树每次只有访问到叶子节点才能找到对应的数据，而在B树中，非叶子节点也会存储数据，这样就会造成查询效率不稳定的情况，有时候访问到了非叶子节点就可以找到关键字，而有时需要访问到叶子节点才能找到关键字。
- 其次，B+树的查询效率更高。这是因为通常B+树比B树更矮胖(阶数更大，深度更低)，查询所需要的磁盘I/O 也会更少。同样的磁盘页大小，B+树可以存储更多的节点关键字。
- 不仅是对单个关键字的查询上，在查询范围上，B+树的效率也比B树高。这是因为所有关键字都出现在B+树的叶子节点中，叶子节点之间会有指针，数据又是递增的，这使得我们范围查找可以通过指针连接查找。而在B树中则需要通过中序遍历才能完成查询范围的查找，效率要低很多。
B 树和 B+ 树都可以作为索引的数据结构，在 MySQL 中采用的是 B+ 树。
但B树和B+树各有自己的应用场景，不能说B+树完全比B树好，反之亦然。
# 思考题：为了减少IO，索引树会一次性加载吗？
1、数据库索引是存储在磁盘上的，如果数据量很大，必然导致索引的大小也会很大，超过几个G。
2、当我们利用索引查询时候，是不可能将全部几个G的索引都加载进内存的，我们能做的只能是：逐一加载每一个磁盘页，因为磁盘页对应着索引树的节点。
# 思考题：B+树的存储能力如何？为何说一般查找行记录，最多只需1~3次磁盘IO
- InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT(占用4个字节)或BIGINT(占用8个字节)，指针类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储16KB/(8B+8B)=1K个键值，因为是估算，为了方便计算，这里的K取值为10^3。也就是说一个深度为3的B+Tree索引可以维护10^3 * 10^3 * 10^3 = 10亿条记录。（这里假定一个数据页也存储10^3条行记录数据了）
- 实际情况中每个节点可能不能填充满，因此在数据库中，`B+Tree的高度一般都在2~4层`。MySQL的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要1~3次磁盘I/O操作
# 思考题：为什么说B+树比B-树更适合实际应用中操作系统的文件索引和数据库索引？
1. B+树的磁盘读写代价更低
B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对于B树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。
2. B+树的查询效率更加稳定
由于非终结点并不是最终指向文件内容的节点，而只是叶子结点中关键字的索引。所有任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
# 思考题：Hash索引与B+树索引的区别
1、Hash索引`不能进行范围查询`，而B+树可以。这是因为Hash索引指向的数据是无序的，而B+树的叶子节点是个有序的链表。
2、Hash索引`不支持联合索引的最左侧原则`（即联合索引的部分索引无法使用），而B+树可以。对于联合索引来说，Hash索引在计算Hash值的时候是将索引键合并后再一起计算Hash值，所以不会针对每个索引单独计算Hash值。因此如果用到联合索引的一个或者几个索引时，联合索引无法被利用。
3、Hash索引`不支持 ORDER BY 排序`，因为Hash索引指向的数据是无序的，因此无法起到排序优化的作用，而B+树索引数据是有序的，可以起到对该字段ORDER BY 排序优化的作用。同理，我们也无法用Hash索引进行`模糊查询`，而B+树使用LIKE进行模糊查询的时候，LIKE后面后模糊查询（比如%结尾）的话就可以起到优化作用。
4、`InnoDB不支持哈希索引`
6.6.7、R树
6.6.8、小结
使用索引可以帮助我们从海量的数据中快速定位想要查找的数据，不过索引也存在一些不足，比如占用存储空间、降低数据库写操作的性能等，如果有多个索引还会增加索引选择的时间。当我们使用索引时，需要平衡索引的利(提升查询效率）和弊（维护索引所需的代价）。
在实际工作中，还需要基于需求和数据本身的分布情况来确定是否使用索引，尽管索引不是万能的，但数据量大的时候不使用索引是不可想象的，毕竟索引的本质，是帮助我们提升数据检索的效率。
七、InnoDB数据存储结构
7.1、数据库的存储结构：页
索引结构提供了高效的索引方式，不过索引信息以及数据记录都保存在文件上的，确切说是存储在页结构中。另一方面，索引是在存储引擎中实现的，MySQL服务器上的存储引擎负责对表中数据的读取和写入工作。不同存储引擎中存放的格式一般不同的，甚至有的存储引擎比如Memory都不用磁盘来存储数据。
InnoDB是MySQL的默认存储引擎。
7.1.1、磁盘与内存交互基本单位：页
InnoDB将数据划分为若干个页，InnoDB中页的大小默认为16KB。
以页作为磁盘和内存之间交互的基本单位，也就是一次最少从磁盘中读取16KB的内容到内存中，一次最少把内存中的16KB内容刷新到磁盘中。也就是说， 在数据库中，不论读一行，还是读多行，都是将这些行所在的页进行加载。也就是说，数据库管理存储空间的基本单位是页（Page），数据库I/O操作的最小单位是页。 一个页中可以存储多个行记录。
记录是按照行来存储的，但是数据库的读取并不以行为单位，否则一次读取（也就是一次I/O操作）只能处理一行数据，效率会非常低。
7.1.2、页结构概述
页a、页b、页c…页n 这些页可以不在物理结构上相连，只要通过双向链表相关联即可。每个数据页中的记录会按照主键值从小到大的顺序组成一个单向链表，每个数据页都会为存储在它里边的记录生成一个页目录，在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应的分组中的记录即可快速找到指定的记录。
7.1.3、页的大小
不同的数据库管理系统（DBMS）的页大小不同。比如在MySQL的InnoDB存储引擎中，默认页的大小是16KB
# 通过下面的命令来进行查看；
show variables like '%innodb_page_size%';
7.1.4、页的上层结构
区（Extent）是比页大一级的存储结构，在InnoDB存储引擎中，一个区会分配64个连续的页。因为InnoDB中的页大小默认是16KB，所以一个区的大小是64*16KB=1MB。
段（Segment）由一个或多个区组成，区在文件系统是一个连续分配的空间（在InnoDB中是连续的64个页），不过在段中不要求区与区之间是相邻的。段是数据库中的分配单位，不同类型的数据库对象以不同的段形式存在。当我们创建数据表、索引的时候，就会相应创建对应的段，比如创建一张表时会创建一个表段，创建一个索引时会创建一个索引段。
表空间（Tablespace）是一个逻辑容器，表空间存储的对象是段，在一个表空间中可以有一个或多个段，但是一个段只能属于一个表空间。数据库由一个或多个表空间组成，表空间从管理上可以划分为系统表空间、用户表空间、撤销表空间、临时表空间等。
7.2、页的内部结构
页如果按类型划分的话，常见的有 数据页（保存 B+ 树节点）、系统页、Undo 页 和事务数据页等。数据页是最常使用的页。
数据页的16KB大小的存储空间被划分为七个部分，分别是文件头（File Header）、页头（Page Header）、最大最小记录（Infimum+supermum）、用户记录（User Records）、空闲空间（Free Space）、页目录（Page Directory）和文件尾（File Tailer）。
这七部分的作用如下：
7.2.1、第1部分：文件头部和文件尾部
7.2.1.1、File Header(文件头)
文件头部信息
不同类型的页都会以File Header作为第一个组成部分，它描述了一些针对各种页都通用的一些信息，比方说这个页的编号是多少，它的上一个页，下一个页是谁等，所有的数据页会组成一个双链表。这个部分占用固定的38字节，是中下边这些内容组成的：
| 名称 | 占用空间大小 | 描述 |
|---|---|---|
FIL_PAGE_SPACE_OR_CHKSUM |
4字节 |
页的校验和（checksum值） |
FIL_PAGE_OFFSET |
4字节 |
页号 |
FIL_PAGE_PREV |
4字节 |
上一个页的页号 |
FIL_PAGE_NEXT |
4字节 |
下一个页的页号 |
| FIL_PAGE_LSN |
8字节 |
页面被最后修改时对应的日志序列位置 |
FIL_PAGE_TYPE |
2字节 |
该页的类型 |
| FIL_PAGE_FILE_FLUSH_LSN |
8字节 |
仅在系统表空间的一个页中定义，代表文件至少被刷新到了对应的LSN值 |
FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID |
4字节 |
页属于哪个表空间 |
FIL_PAGE_OFFSET（4字节）：每一个页都有一个单独的页号，就跟你的身份证号码一样，InnoDB通过页号可以唯一定位一个页。
FIL_PAGE_TYPE（2字节）：这个代表当前页的类型。
存放记录的数据页的类型其实是FIL_PAGE_INDEX， 也就是所谓的 索引页 。
数据页的链接实现
在文件头部内容中有两个属性：FIL_PAGE_PREV和FIL_PAGE_NEXT
InnoDB都是以页为单位存放数据的，如果数据分散到多个不连续的页中存储的话需要把这些页关联起来，FIL_PAGE_PREV和FIL_PAGE_NEXT 就分别代表本页的上一个和下一个页的页号。这样通过建立一个双向链表把许许多多的页就都串联起来了，保证这些页之间 不需要是物理上的连续，而是逻辑上的连续。
检验页的完整性
# 什么是校验和?
- 就是对于一个很长的字节串来说，我们会通过某种算法来计算一个比较短的值来代表这个很长的字节串，这个比较短的值就称为校验和。
- 在比较两个很长的字节串之前，先比较这两个长字节串的校验和，如果校验和都不一样，则两个长字节串肯定是不同的，所以省去了直接比较两个比较长的字节串的时间损耗。
文件头部和文件尾部都有：FIL_PAGE_SPACE_OR_CHKSUM
InnoDB存储引擎以页为单位把数据加载到内存中处理，如果该页中的数据在内存中被修改了，那么在修改后的某个时间需要把数据同步到磁盘中。但是在同步了一半的时候断电了，造成了该页传输的不完整。
为了检测一个页是否完整（也就是在同步的时候有没有发生只同步一半的尴尬情况），这时可以通过文件尾的校验和（checksum 值）与文件头的校验和做比对，如果两个值不相等则证明页的传输有问题，需要重新进行传输，否则认为页的传输已经完成。
FIL_PAGE_LSN（8字节）：页面被最后修改时对应的日志序列位置（英文名是：Log Sequence Number）
7.2.1.2、File Trailer（文件尾部）
- 前4个字节代表页的校验和：这个部分是和File Header中的校验和相对应的。
- 后4个字节代表页面被最后修改时对应的日志序列位置（LSN）：这个部分也是为了校验页的完整性的，如果首部和尾部的LSN值校验不成功的话，就说明同步过程出现了问题。
7.2.2、第2部分：空闲空间、用户记录和最小最大记录
7.2.2.1、Free Space (空闲空间)
我们自己存储的记录会按照指定的行格式存储到User Records部分。但是在一开始生成页的时候，其实并没有User Records这个部分，每当我们插入一条记录，都会从Free Space部分，也就是尚未使用的存储空间中申请一个记录大小的空间划分到User Records部分，当Free Space部分的空间全部被User Records部分替代掉之后，也就意味着这个页使用完了，如果还有新的记录插入的话，就需要去申请新的页了。
7.2.2.2、User Records (用户记录)
User Records中的这些记录按照指定的行格式一条一条摆在User Records部分，相互之间形成单链表。
具体看7.3.2.3 记录头信息 章节。
7.2.2.3、Infimum + Supremum（最小最大记录）
记录可以比较大小吗 ？
是的，记录可以比大小，对于一条完整的记录来说，比较记录的大小就是比较主键的大小。比方说我们插入的4行记录的主键值分别是：1、2、3、4，这也就意味着这4条记录是从小到大依次递增。
InnoDB规定的最小记录与最大记录这两条记录的构造十分简单，都是由5字节大小的记录头信息和8字节大小的一个固定的部分组成的。
这两条记录不是我们自己定义的记录，所以它们并不存放在页的User Records部分，他们被单独放在一个称为Infimum + Supremum的部分
7.2.3、第3部分：页目录和页面头部
7.2.3.1、Page Directory（页目录）
为什么需要页目录 ？
在页中，记录是以单向链表的形式进行存储的。单向链表的特点就是插入、删除非常方便，但是检索效率不高，最差的情况下需要遍历链表上的所有节点才能完成检索。因此在页结构中专门设计了页目录这个模块，专门给记录做一个目录，通过二分查找法的方式进行检索，提升效率。
# 方式1：顺序查找
- 从Infimum记录（最小记录）开始，沿着链表一直往后找，总有一天会找到（或者找不到），在找的时候还能投机取巧，因为链表中各个记录的值是从小到大顺序排序的，所有当链表的某个节点代表的记录的主键值大于你想要查找的主键值时，你就可以停止查找了，因为该节点后边的节点的主键值依次递增。
如果一个页中存储了非常多的记录，这么查找性能很差。
# 方式2；使用页目录，二分法查找
1. 将所有的记录`分成几个组`，这些记录包括最小记录和最大记录，但不包括标记为“已删除”的记录。
2. 第 1 组，也就是最小记录所在的分组只有 1 个记录；
最后一组，就是最大记录所在的分组，会有 1-8 条记录；
其余的组记录数量在 4-8 条之间。
这样做的好处是，除了第 1 组（最小记录所在组）以外，其余组的记录数会`尽量平分`。
3. 在每个组中最后一条记录的头信息中会存储该组一共有多少条记录，作为 n_owned 字段。
4. `页目录用来存储每组最后一条记录的地址偏移量`，这些地址偏移量会按照`先后顺序存储`起来，每组的地址偏移量也被称之为`槽（slot）`，每个槽相当于指针指向了不同组的最后一个记录。
举例：
现在的page_demo表中正常的记录共有6条，InnoDB会把它们分成两组，第一组中只有一个最小记录，第二组中是剩余的5条记录。如下图：
从这个图中我们需要注意这么几点：
- 现在页目录部分中有两个槽，也就意味着我们的记录被分成了两个组，槽1中的值是112，代表最大记录的地址偏移量（就是从页面的0字节开始数，数112个字节）；槽0中的值是99，代表最小记录的地址偏移量。
- 注意最小和最大记录的头信息中的n_owned属性
- 最小记录的n_owned值为1，这就代表着以最小记录结尾的这个分组中只有1条记录，也就是最小记录本身。
- 最大记录的n_owned值为5，这就代表着以最大记录结尾的这个分组中只有5条记录，包括最大记录本身还有我们自己插入的4条记录。
用箭头指向的方式替代数字，这样更易于我们理解，修改后如下
页目录分组的个数如果确定？
为什么最小记录的n_owned值为1，而最大记录的n_owned值为5呢？
InnoDB规定：对于最小记录所在的分组只能有1条记录，最大记录所在的分组拥有的记录条数只能在1~8条之间，剩下的分组中记录的条数范围只能在是 4~8 条之间。
分组是按照下边的步骤进行的：
- 初始情况下一个数据页里只有最小记录和最大记录两条记录，它们分属于两个分组。
- 之后每插入一条记录，都会从页目录中找到主键值比本记录的主键值大并且差值最小的槽，然后把该槽对应的记录的n_owned值加1，表示本组内又添加了一条记录，直到该组中的记录数等于8个。
- 在一个组中的记录数等于8个后再插入一条记录时，会将组中的记录拆分成两个组，一个组中4条记录，另一个5条记录。这个过程会在页目录中新增一个槽来记录这个新增分组中最大的那条记录的偏移量。
页目录结构下如何快速查找记录？
# 比方说我们想找主键值为6的记录，过程是这样的：
1. 计算中间槽的位置:(O+4)/2=2，所以查看槽2对应记录的主键值为8，又因为8 >6，所以设置high=2，low保持不变。
2. 重新计算中间槽的位置:(O+2)/2=1，所以查看槽1对应的主键值为4，又因为4<6，所以设置low=1，high保持不变。
3. 因为high - low的值为1，所以确定主键值为6的记录在槽2对应的组中。此刻我们需要找到槽2中主键值最小的那条记录，然后沿着单向链表遍历槽2中的记录。
但是我们前边又说过，每个槽对应的记录都是该组中主键值最大的记录，这里槽2对应的记录是主键值为8的记录，怎么定位一个组中最小的记录呢?别忘了各个槽都是挨着的，我们可以很轻易的拿到槽1对应的记录(主键值为4），该条记录的下一条记录就是槽2中主键值最小的记录，该记录的主键值为5。所以我们可以从这条主键值为5的记录出发，遍历槽2中的各条记录，直到找到主键值为6的那条记录即可。
由于一个组中包含的记录条数只能是1~8条，所以遍历一个组中的记录的代价是很小的。
小结：
在一个数据页中查找指定主键值的记录的过程分为两步：
- 通过二分法确定该记录所在的槽，并找到该槽所在分组中主键值最小的那条记录。
- 通过记录的next_record属性遍历该槽所在的组中的各个记录。
7.2.3.2、Page Header（页面头部）
为了能得到一个数据页中存储的记录的状态信息，比如本页中已经存储了多少条记录，第一条记录的地址是什么，页目录中存储了多少个槽等等，特意在页中定义了一个叫Page Header的部分，这个部分占用固定的56个字节，专门存储各种状态信息。
| 名称 | 占用空间大小 | 描述 |
|---|---|---|
| PAGE_N_DIR_SLOTS | 2字节 | 在页目录中的槽数量 |
| PAGE_HEAP_TOP | 2字节 | 还未使用的空间最小地址，也就是说从该地址之后就是Free Space
|
| PAGE_N_HEAP | 2字节 | 本页中的记录的数量（包括最小和最大记录以及标记为删除的记录） |
| PAGE_FREE | 2字节 | 第一个已经标记为删除的记录的记录地址（各个已删除的记录通过next_record也会组成一个单链表，这个单链表中的记录可以被重新利用） |
| PAGE_GARBAGE | 2字节 | 已删除记录占用的字节数 |
| PAGE_LAST_INSERT | 2字节 | 最后插入记录的位置 |
| PAGE_DIRECTION | 2字节 | 记录插入的方向 |
| PAGE_N_DIRECTION | 2字节 | 一个方向连续插入的记录数量 |
| PAGE_N_RECS | 2字节 | 该页中记录的数量（不包括最小和最大记录以及被标记为删除的记录） |
| PAGE_MAX_TRX_ID | 8字节 | 修改当前页的最大事务ID，该值仅在二级索引中定义 |
| PAGE_LEVEL | 2字节 | 当前页在B+树中所处的层级 |
| PAGE_INDEX_ID | 8字节 | 索引ID，表示当前页属于哪个索引 |
| PAGE_BTR_SEG_LEAF | 10字节 | B+树叶子段的头部信息，仅在B+树的Root页定义 |
| PAGE_BTR_SEG_TOP | 10字节 | B+树非叶子段的头部信息，仅在B+树的Root页定义 |
PAGE_DIRECTION：假如新插入的一条记录的主键值比上一条记录的主键值大，我们说这条记录的插入方向是右边，反之则是左边。用来标识最后一条记录插入方向的状态就是PAGE_DIRECTION。
PAGE_DIRECTION：假设连续几次插入新纪录的方向都是一致的，InnoDB会把沿着同一个方向插入记录的条数记下来，这个条数就用PAGE_DIRECTION这个状态标表示。当然，如果最后一条记录的插入方向改变了的话，这个状态的值会被清零重新统计。
从数据页的角度看B+树如何查询
一颗B+树按照节点类型可以分成两部分：
- 叶子节点，B+树最底层的节点，节点的高度为0，存储行记录。
- 非叶子节点，节点的高度大于0，存储索引键和页面指针，并不存储行记录本身。
当我们从页结构来理解B+树的结构的时候，可以帮我们理解一些通过索引进行检索的原理：
-
B+树是如何进行记录检索的？
如果通过B+树的索引查询行记录，首先是从B+树的根开始，逐层检索，直到找到叶子节点，也就是找到对应的数据页为止，将数据页加载到内存中，页目录中的槽（slot）采用 二分查找 的方式先找到一个粗略的记录分组，然后再在分组汇总通过链表遍历的方式查找记录。
-
普通索引和唯一索引在查询效率上有什不同？
我们创建索引的时候可以是普通索引，也可以是唯一索引，那么这两个索引在查询效率上有什么不同呢？
唯一索引就是在普通索引上增加了约束性，也就是关键字唯一，找到了关键字就停止检索。而普通索引，可能会存在用户记录中的关键字相同的情况，根据页结构的原理，当我们读取一条记录的时候，不是单独将这条记录从磁盘中读出去，而是将这个记录所在的页加载到内存中进行读取。InnoDB存储引擎的页大小为16KB，在一个页中可能存储着上千条记录，因此在普通索引的字段上进行查找也就是在内存中多几次“判断下一条记录”的操作，对于CPU来说，这些操作所消耗的时间是可以忽略不计的。所以对一个索引字段进行检索，采用普通索引还是唯一索引在检索效率上基本上没有差别。
7.3、InnoDB行格式（或记录格式）
我们平时的数据以行为单位来向表中插入数据，这些记录在磁盘上的存放方式也被称为‘ 行格式 ’ 或者 ‘记录格式’。InnoDB存储引擎设计了4种不同类型的‘ 行格式 ’，分别是‘ Compact’，’Redundant‘，’Dynamic‘’和’ compressed‘行格式。
# 查看Mysql8的默认行格式
SELECT @@innodb_default_row_format;
# 也可以使用如下语法查看具体表使用的行格式；
SHOW TABLE STATUS LIKE '表名'\G
7.3.1、指定行格式的语法
CREATE TABLE 表名 (列的信息) ROW_FORMAT=行格式名称
ALTER TABLE 表名 ROW_FORMAT=行格式名称
CREATE TABLE record_test_table(
col1 VARCHAR(8),
col2 VARCHAR(8) NOT NULL,
col3 CHAR(8),
col4 VARCHAR(8)
) CHARSET = ASCII ROW_FORMAT=CPMPACT;
INSERT INTO record_test_table(col1, col2, col3, col4)VALUES('zhangsan', 'lisi', 'wangwu', 'songhk'),('tong', 'chen', NULL, NULL);
7.3.2、COMPACT行格式
在MySQL 5.1版本中，默认设置为Compact行格式。一条完整的记录其实可以被分为记录的额外信息和记录的真实数据两大部分。
7.3.2.1、变长字段长度列表
MySQL支持一些变长的数据类型，比如VARCHAR(M)、VARBINARY(M)、TEXT类型，BLOB类型，这些数据类型修饰列称为变长字段，变长字段中存储多少字节的数据不是固定的，所以我们在存储真实数据的时候需要顺便把这些数据占用的字节数也存起来。在Compact行格式中，把所有变长字段的真实数据占用的字节长度都存放在记录的开头部位，从而形成一个变长字段长度列表。
注意：这里面存储的变长长度和字段顺序是反过来的。比如两个varchar字段在表结构的顺序是a(10)，b(15)。那么在变长字段长度列表中存储的长度顺序就是15，10，是反过来的。
以record_test_table表中的第一条记录举例：因为record_test_table表的col1、col2、col2列都是VARCHAR(8)类型的，所以这三个列的值的长度都需要保存在记录开头处，注意record_test_table表中的各个列都使用的是ascii字符集（每个字符只需要1个字节来进行编码）。
又因为这些长度值需要按照列的逆序存放，所以最后变长字段长度列表的字节串用十六进制表示的效果就是（各个字节之间实际上没有空格，用空格隔开知识方便理解）：06 04 08
把这个节点串组成的变长字段长度列表填入上边的示意图中的效果就是：
7.3.2.2、NULL值列表
Compact行格式会把可以为NULL的列统一管理起来，存在一个标记为NULL值列表中。如果表中没有允许存储 NULL 的列，则 NULL值列表也不存在了。
为什么定义NULL值列表？
之所以要存储NULL是因为数据都是需要对齐的，如果没有标注出来NULL值的位置，就有可能在查询数据的时候出现混乱。如果使用一个特定的符号放到相应的数据位表示空置的话，虽然能达到效果，但是这样很浪费空间，所以直接就在行数据得头部开辟出一块空间专门用来记录该行数据哪些是非空数据，哪些是空数据，格式如下：
- 二进制位的值为1时，代表该列的值为NULL。
- 二进制位的值为0时，代表该列的值不为NULL。
注意：同样顺序也是反过来存放的
例如:字段a、b、c，其中a是主键，在某一行中存储的数依次是a=1、b=null、c=2。那么Compact行格式中的NULL值列表中存储:01。第一个0表示c不为null，第二个1表示b是null。这里之所以没有a是因为数据库会自动跳过主键，因为主键肯定是非NULL且唯一的，在NULL值列表的数据中就会自动跳过主键。
record_test_table的两条记录的NULL值列表就如下:
7.3.2.3、记录头信息（5字节）
这些记录头信息中各个属性如下：
| 名称 | 大小（单位：bit） | 描述 |
|---|---|---|
预留位1 |
1 | 没有使用 |
预留位2 |
1 | 没有使用 |
delete_mask |
1 | 标记该记录是否被删除 |
mini_rec_mask |
1 | B+树的每层非叶子节点中的最小记录都会添加该标记 |
n_owned |
4 | 表示当前记录拥有的记录数 |
heap_no |
13 | 表示当前记录在记录堆的位置信息 |
record_type |
3 | 表示当前记录的类型，0表示普通记录，1表示B+树非叶子节点记录，2表示最小记录，3表示最大记录 |
next_record |
16 | 表示下一条记录的相对位置 |
INSERT INTO page_demo VALUES
(1,100,'song'),(2,200,'tong'),(3,300,'zhan'),(4,400,"list");
-
delete_mask：这个属性标记着当前记录是否被删除，占用1个二进制位。- 值为0：代表记录并没有被删除
- 值为1：代表记录被删除掉了
# 被删除的记录为什么还在页中存储呢？
- 你以为它删除了，可它还在真实的磁盘上。这些被删除的记录之所以不立即从磁盘上移除，是因为移除它们之后其他的记录在磁盘上需要`重新排列，导致性能消耗`。所以只是打一个删除标记而已，所有被删除掉的记录都会组成一个所谓的`垃圾链表`，在这个链表中的记录占用的空间称之为`可重用空间`，之后如果有新记录插入到表中的话，可能把这些被删除的记录占用的存储空间覆盖掉。
-
min_rec_mask：B+树的每层非叶子节点中的最小记录都会添加该标记，min_rec_mask值为1。我们自己插入的四条记录的min_rec_mask值都是0，意味着它们都不是B+树的非叶子节点中的最小记录。 -
record_type：这个属性表示当前记录的类型，一共有4种类型的记录：- 0：表示普通记录
- 1：表示B+树非叶节点记录
- 2：表示最小记录
- 3：表示最大记录
-
heap_no：这个属性表示当前记录在本页中的位置。
# 怎么不见heap_no值为0和1的记录呢 ？
- MySQL会自动给每个页里加了两个记录，由于这两个记录并不是我们自己插入的，所以有时候也称为`伪记录`或者`虚拟记录`。这两个伪记录一个代表`最小记录`，一个代表`最大记录`。最小记录和最大记录的heap_no值分别是0和1，也就是说它们的位置最靠前
-
n_owned：页目录中每个组中最后一条记录的头信息中会存储该组一共有多少条记录，作为 n_owned 字段 -
next_record：记录头信息里该属性非常重要，它表示从当前记录的真实数据到下一条记录的真实数据的地址偏移量。
比如:第一条记录的next_record值为32，意味着从第一条记录的真实数据的地址处向后找32个字节便是下一条记录的真实数据。
注意，下一条记录指得并不是按照我们插入顺序的下一条记录，而是按照主键值由小到大的顺序的下一条记录。而且规定Infimum记录（也就是最小记录）的下一条记录就是本页中主键值最小的用户记录，而本页中主键值最大的用户记录的下一条记录就是
Supremum记录（也就是最大记录）。下图用箭头代替偏移量表示next_record。
从图中可以看出来，删除第2条记录前后主要发生了这些变化：
- 第2条记录并没有从存储空间中移除，而是把该条记录的delete_mask值设置为1.
- 第2条记录的next_record值变为了0，意味着该记录没有下一条记录了
- 第1条记录的next_record指向了第3条记录
- 最大记录的n_owned值从5变成了4.
所以，不论我们怎么对页中的记录做增删改操作，InnoDB始终会维护一条记录的单链表，链表中的各个节点是按照主键值由小到大的顺序连接起来的。
7.3.2.4、记录的真实数据
| 列名 | 是否必须 | 占用空间 | 描述 |
|---|---|---|---|
| row_id | 否 | 6字节 | 行ID，唯一标识一条记录 |
| transaction_id | 是 | 6字节 | 事务ID |
| roll_pointer | 是 | 7字节 | 回滚指针 |
实际上这几个列的真正名称是：DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR。
- 一个表没有手动定义主键，则会选取一个Unique键作为主键，如果连Unique键都没有定义的话，则会为表默认添加一个名为row_id的隐藏列作为主键。所以row_id是在没有自定义主键以及Unique键的情况下才会存在的。
7.3.3、Dynamic和Compressed行格式
行溢出
InnoDB存储引擎可以将一条记录中的某些数据存储在真正的数据页面之外。
- 很多DBA喜欢MySQL数据库提供的VARCHAR(M)类型，认为可以存放65535字节。这是真的吗?如果我们使用ascii字符集的话，一个字符就代表一个字节，我们看看VARCHAR(65535)是否可用。
CREATE TABLE varchar_size_demo(
c VARCHAR(65535)
)CHARSET=ascii ROW_FORMAT=Compact;
- 结果如下:
ERROR 1118(42000):Row size too maximum row size for the used tabletype, not counting BLOBs, is 65535. This includes storage overhead, check the have to change some columns tp TEXT or BLOBs
报错信息表达的意思是:MySQL对一条记录占用的最大存储空间是有限制的，除BLOB或者TEXT类型的列之外，其他所有的列（不包括隐藏列和记录头信息）占用的字节长度加起来不能超过65535个字节。
这个65535个字节除了列本身的数据之外，还包括一些其他的数据，以Compact行格式为例，比如说我们为了存储一个VARCHAR(M)类型的列，除了真实数据占有空间以外，还需要记录的额外信息。
如果该VARCHAR类型的列没有NOT NULL属性，那最多只能存储65532个字节的数据，因为变长字段的长度占用2个字节，NULL值标识需要1个字节。
CREATE TABLE varchar_size_demo(
c VARCHAR(655352)
)CHARSET=ascii ROW_FORMAT=Compact;
如果有not null属性，那么久不需要NULL值标识，也就是可以多存储一个字节，即65533个字节
CREATE TABLE varchar_size_demo(
c VARCHAR(65533)
)CHARSET=ascii ROW_FORMAT=Compact;
我们可以知道一个页的大小一般是16KB，也就是16384字节，而一个VARCHAR(M)类型的列就最多可以存储65533个字节，这样就可能出现一个页存放不了一条记录，这种现象称为行溢出
在Compact和Reduntant行格式中，对于占用存储空间非常大的列，在记录的真实数据处只会存储该列的一部分数据，把剩余的数据分散存储在几个其他的页中进行分页存储，然后记录的真实数据处用20个字节存储指向这些页的地址（当然这20个字节中还包括这些分散在其他页面中的数据的占用的字节数），从而可以找到剩余数据所在的页。这称为页的扩展。
在MySQL 8.0中，默认行格式就是Dynamic，Dynamic、Compressed行格式和Compact行格式挺像，只不过在处理行溢出数据时有分歧
- Compressed和Dynamic两种记录格式对于存放在BLOB中的数据采用了完全的行溢出的方式。如图，在数据页中只存放20个字节的指针（溢出页的地址），实际的数据都存放在Off Page（溢出页）中。
- Compact和Redundant两种格式会在记录的真实数据处存储一部分数据（存放768个前缀字节）。
Compressed行记录格式的另一个功能就是，存储在其中的行数据会以zlib的算法进行压缩，因此对于BLOB、TEXT、VARCHAR这类大长度类型的数据能够进行非常有效的存储。
7.3.4、Redundant行格式
Redundant是MySQL 5.0版本之前InnoDB的行记录存储方式,MySQL 5.0支持Redundant是为了兼容之前版本的页格式。
现在我们把表record_test_table的行格式修改为Redundant:
ALTER TABLE record_test_table ROW_FORMAT=Redundant;
Query OK, 0 rows affected (0.05 sec)
Records: 0 Duplicates: o Warnings: 0
从上图可以看到，不同于Compact行记录格式，Redundant行格式的首部是一个字段长度偏移列表，同样是按照列的顺序逆序放置的。
注意Compact行格式的开头是变长字段长度列表，而Redundant行格式的开头是字段长度偏移列表，与变长字段长度列表有两处不同:
- 少了“变长”两个字:Redundant行格式会把该条记录中所有列（包括隐藏列）的长度信息都按照逆序存储到字段长度偏移列表。
- 多了“偏移”两个字:这意味着计算列值长度的方式不像Compact行格式那么直观，它是采用两个相邻数值的差值来计算各个列值的长度。
举例:比如第一条记录的字段长度偏移列表就是:
2B 25 1F 1B13 0C 06
因为它是逆序排放的，所以按照列的顺序排列就是:
06 0C 1317 1A24 25
按照两个相邻数值的差值来计算各个列值的长度的意思就是:
- 第一列(row_id)的长度就是Ox06个字节，也就是6个字节。
- 第二列(transaction_id)的长度就是(OxOC- 0x06)个字节，也就是6个字节。
- 第三列(roll_pointer)的长度就是(Ox13 - oxOC)个字节，也就是7个字节。
- 第四列(col1)的长度就是(Ox1B- Ox13)个字节，也就是8个字节。
- 第五列(col2)的长度就是(Ox1F - Ox1B)个字节，也就是4个字节。
- 第六列(col3)的长度就是(Ox25 - Ox1F)个字节，也就是6个字节。
- 第七列(col4)的长度就是(Ox2B - Ox25)个字节，也就是6个字节。
不同于Compact行格式，Redundant行格式中的记录头信息固定占用6个字节(48位)，每位的含义见下表。
与Compact行格式的记录头信息对比来看，有两处不同:
- Redundant行格式多了n_field和1byte_offs_flag这两个属性。
- Redundant行格式没有record_type这个属性。
其中，n_fields:代表一行中列的数量，占用10位，这也很好地解释了为什么MySQL一个行支持最多的列为1023。另一个值为1byte_offs_flags，该值定义了偏移列表占用1个字节还是2个字节。当它的值为1时，表明使用1个字节存储。当它的值为0时，表明使用2个字节存储。
7.4、区、段和碎片区
7.4.1、为什么要有区？
B+树的每一层中的页都会形成一个双向链表，如果是以页为单位来分配存储空间的话，双向链表相邻的两个页之间的物理位置可能离得非常远。我们介绍B+树索引的使用场景的时候特别提到范围查询只需要定位到最左边的记录和最右边的记录，然后沿着双向链表一直扫描就可以了，而如果链表中相邻的两个页物理位置离得非常远，就是所谓的随机I/O。再一次强调，磁盘的速度和内存的速度差了好几个数量级，随机I/O是非常慢的，所以我们应该尽量让链表中相邻的页的物理位置也相邻，这样进行范围查询的时候才可以使用所谓的顺序I/O。
引入区的概念，一个区就是物理位置上连续的64个页。因为InnoDB中的页的大小默认是16KB，所以一个区的大小是64*16KB=1MB。在表中数据量大的时候，为某个索引分配空间的时候就不再按照页的单位分配了，而是按照区为单位分配，甚至在表中的数据特别多的时候，可以一次性分配多个连续的区。虽然可能造成一点点空间的浪费（数据不足以填充满整个区），但是从性能角度看，可以消除很多的随机I/O，功大于过！
7.4.2、为什么要有段？
对于范围查询，其实是对B+树叶子节点中的记录进行顺序扫描，而如果不区分叶子节点和非叶子节点，统统把节点代表的页面放到申请到的区中的话，进行范围扫描的效果就大打折扣了。所以InnoDB对B+树的叶子节点和非叶子节点进行了区别对待，也就是说叶子节点有自己独有的区，非叶子节点也有自己独有的区。存放叶子节点的区的集合就算是一个段（segment），存放非叶子节点的区的集合也算是一个段。也就是说一个索引会生成2个段，一个叶子节点段，一个非叶子节点段。
除了索引的叶子节点段和非叶子节点段之外，InnoDB中还有为存储一些特殊的数据而定义的段，比如回滚段。所以，常见的段有数据段、索引段、回滚段。数据段即为B+树的叶子节点，索引段即为B+树的非叶子节点。
在InnoDB存储引擎中，对段的管理都是由引擎自身所完成，DBA不能也没有必要对其进行控制。这从一定程度上简化了DBA对于段的管理。
段其实不对应表空间中的某一个连续的物理区域，而是一个逻辑上的概念，由若干个零散的页面以及一些完整的区组成。
7.4.3、为什么要有碎片区？
默认情况下，一个使用InnoDB存储引擎的表只有一个聚簇索引，一个索引会生成2个段，而段是以区为单位申请存储空间的，一个区默认占用1M（64*16KB=1024KB）存储空间，所以 默认情况下一个只存在几条记录的小表也需要2M的存储空间么？ 以后每次添加一个索引都要多申请2M的存储空间么？这对于存储记录比较少的表简直是天大的浪费。这个问题的症结在于到现在为止我们介绍的区都是非常纯粹的，也就是一个区被整个分配给某一个段，或者说区中的所有页面都是为了存储同一个段的数据而存在的，即使段的数据填不满区中所有的页面，那余下的页面也不能挪作他用。
为了考虑以完整的区为单位分配给某个段对于数据量较小的表太浪费存储空间的这种情况，InnoDB提出了一个碎片（fragment）区的概念。在一个碎片区中，并不是所有的页都是为了存储同一个段的数据而存在的，而是碎片区中的页可以用于不同的目的，比如有些页面用于段A，有些页面用于段B，有些页甚至哪个段都不属于。碎片区直属于表空间，并不属于任何一个段。
所以此后为某个段分配存储空间的策略是这样的：
- 在刚开始向表中插入数据的时候，段是从某个碎片区以单个页面为单位来分配存储空间的。
- 当某个段已经占用了
32个碎片区页面之后，就会申请以完整的区为单位来分配存储空间。
所以现在段不能仅定义为是某些区的集合，更精确的应该是某些零散的页面已经一些完整的区的集合。
7.4.4、区的分类
区大体上可以分为4种类型：
-
空闲的区(FREE)：现在还没有用到这个区中的任何页面。 -
有剩余空间的碎片区(FREE_FRAG)：表示碎片区中还有可用的页面。 -
没有剩余空间的碎片区(FULL_FRAG)：表示碎片区中的所有页面都被使用，没有空闲页面。 -
附属于某个段的区(FSEG)：每一索引都可以分为叶子节点段和非叶子节点段
处于FREE、FREE_FRAG以及FULL_FRAG这三种状态的区都是独立的，直属于表空间。而处于FSEG状态的区是附属于某个段的。
7.5、表空间
表空间可以看做是InnoDB存储引擎逻辑结构的最高层，所有的数据都存放在表空间中。
表空间是一个 逻辑容器 ，表空间存储的对象是段，在一个表空间中可以有一个或多个段，但是一个段只能属于一个表空间。表空间数据库由一个或多个表空间组成，表空间从管理上可以划分为 系统表空间（System tablespace） 、独立表空间（File-per-table tablespace）、撤销表空间（Undo Tablespace） 和 临时表空间（Temporary TableSpace）等。
7.5.1、独立表空间
独立表空间，即每张表有一个独立的表空间，也就是数据和索引信息都会保存在自己的表空间中。独立的表空间（即：单表）可以在不同的数据库之间进行 迁移。
空间可以回收(DROP TABLE操作可自动回收表空间;其他情况，表空间不能自己回收)。如果对于统计分析或是日志表，删除大量数据后可以通过: alter table TableName engine=innodb;回收不用的空间。对于使用独立表空间的表，不管怎么删除，表空间的碎片不会太严重的影响性能，而且还有机会处理。
独立表空间结构
独立表空间由段、区、页组成。前面已经讲解过了。
真实表空间对应的文件大小
我们到数据目录里看，会发现一个新建的表对应的.ibd文件只占用了96K，才6个页面大小(MySQL5.7中)，这是因为一开始表空间占用的空间很小，因为表里边都没有数据。不过别忘了这些.ibd文件是自扩展的，随着表中数据的增多，表空间对应的文件也逐渐增大。
# 查看InnoDB的表空间类型
show variables like 'innodb_file_per_table';
你能看到 innodb_file_per_table=ON，这就意味着每张表都会单独保存为一个 .ibd 文件。
7.5.2、系统表空间
系统表空间的结构和独立表空间基本类似，只不过由于整个MySQL进程只有一个系统表空间，在系统表空间中会额外记录一些有关整个系统信息的页面,这部分是独立表空间中没有的。
InnoDB数据字典
每当我们向一个表中插入一条记录的时候，MySQL校验过程如下:
先要校验一下插入语句对应的表存不存在，插入的列和表中的列是否符合，如果语法没有问题的话，还需要知道该表的聚簇索引和所有二级索引对应的根页面是哪个表空间的哪个页面，然后把记录插入对应索引的B+树中。所以说，MySQL除了保存着我们插入的用户数据之外，还需要保存许多额外的信息，比方说:
- 某个表属于哪个表空间，表里边有多少列
- 表对应的每一个列的类型是什么
- 该表有多少索引，每个索引对应哪几个字段，该索引对应的根页面在哪个表空间的哪个页面
- 该表有哪些外键,外键对应哪个表的哪些列
- 某个表空间对应文什系统上文件路径是什么
上述这些数据并不是我们使用INSERT语句插入的用户数据，实际上是为了更好的管理我们这些用户数据而不得已引入的一些额外数据，这些数据也称为 元数据，InnoDB存储引擎特意定义了一系列的 内部系统表（Internal System table）来记录这些元数据：
| 表名 | 描述 |
|---|---|
| SYS_TABLES | 整个InnoDB存储引擎中所有的表的信息 |
| SYS_COLUMNS | 整个InnoDB存储引擎中所有的列的信息 |
| SYS_INDEXES | 整个InnoDB存储引擎中所有的索引的信息 |
| SYS_FIELDS | 整个InnoDB存储引擎中所有的索引对应的列的信息 |
| SYS_FOREIGN | 整个InnoDB存储引擎中所有的外键的信息 |
| SYS_FOREIGN_COLS | 整个InnoDB存储引擎中所有的外键对应列的信息 |
| SYS_TABLESPACES | 整个InnoDB存储引擎中所有的表空间信息 |
| SYS_DATAFILES | 整个InnoDB存储引擎中所有的表空间对应文件系统的文件路径信息 |
| SYS_VIRTUAL | 整个InnoDB存储引擎中所有的虚拟生成列的信息 |
这些系统表也被称为数据字典，它们都是以B+树的形式保存在系统表空间的某些页面中，其中SYS_TABLES、SYS_COLUMNS、SYS_INDEXES、SYS_FIELDS这四个表尤其重要，称之为基本系统表(basic system tables)
注意：用户是不能直接访问InnoDB的这些内部系统表，除非你直接去解析系统表空间对应文件系统上的文件。不过考虑到查看这些表的内容可能有助于大家分析问题，所以在系统数据库information_schema中提供了一些以innodb_sys开头的表:
USE information_schema;
SHOW TABLES LIKE 'innodb_sys%';
八、索引的创建与设计原则
8.1、索引的声明与使用
8.1.1、索引的分类
MySQL的索引包括普通索引、唯一性索引、全文索引、单列索引、多列索引和空间索引等。
- 从
功能逻辑上说，索引主要有 4 种，分别是普通索引、唯一索引、主键索引、全文索引。 - 按照
物理实现方式，索引可以分为 2 种：聚簇索引和非聚簇索引。 - 按照
作用字段个数进行划分，分成单列索引和联合索引。
-
普通索引
在创建普通索引时，不附加任何限制条件，只是用于提高查询效率。这类索引可以创建在任何数据类型中，其值是否唯一和非空，要由字段本身的完整性约束条件决定。建立索引以后，可以通过索引进行查询。例如，在表student的字段name上建立一个普通索引，查询记录时就可以根据该索引进行查询。
-
唯一性索引
使用
UNIQUE参数可以设置索引为唯一性索引，在创建唯一性索引时，限制该索引的值必须是唯一的，但允许有空值。在一张数据表里可以有多个唯一索引。例如，在表student的字段email中创建唯一性索引，那么字段email的值就必须是唯一的。通过唯一性索引，可以更快速地确定某条记录。 -
主键索引
主键索引就是一种特殊的唯一性索引，在唯一索引的基础上增加了不为空的约束，也就是NOT NULL+UNIQUE，一张表里最多只有一个主键索引。why?这是由主键索引的物理实现方式决定的，因为数据存储在文件中只能按照一种顺序进行存储。
-
单列索引
在表中的单个字段上创建索引。单列索引只根据该字段进行索引。单列索引可以是普通索引，也可以是唯一性索引，还可以是全文索引。只要保证该索引只对应一个字段即可。一个表可以有多个单列索引。
-
多列(组合、联合)索引
多列索引是在表的多个字段组合上创建一个索引。该索引指向创建时对应的多个字段，可以通过这几个字段进行查询，但是只有查询条件中使用了这些字段中的第一个字段时才会被使用。例如，在表中的字段id、name和gender上建立一个多列索引idx_id_name.gender，只有在查询条件中使用了字段id时该索引才会被使用。使用组合索引时遵循最左前缀集合。
-
全文索引
全文索引(也称全文检索）是目前搜索引擎使用的一种关键技术。它能够利用【分词技术】等多种算法智能分析出文本文字中关键词的频率和重要性，然后按照一定的算法规则智能地筛选出我们想要的搜索结果。全文索引非常适合大型数据集，对于小的数据集，它的用处比较小。
使用参数FULLTEXT可以设置索引为全文索引。在定义索引的列上支持值的全文查找，允许在这些索引列中插入重复值和空值。全文索引只能创建在CHAR、VARCHAR或TEXT类型及其系列类型的字段上，查询数据量较大的字符串类型的字段时，使用全文索引可以提高查询速度。例如，表student的字段information是TEXT类型该字段包含了很多文字信息。在字段information上建立全文索引后，可以提高查询字段information的速度。
全文索引典型的有两种类型:自然语言的全文索引和布尔全文索引。
- 自然语言搜索引擎将计算每一个文档对象和查询的相关度。这里，相关度是基于匹配的关键词的个数，以及关键词在文档中出现的次数。在整个索引中出现次数越少的词语，匹配时的相关度就越高。相反，非常常见的单词将不会被搜索，如果一个词语的在超过50%的记录中都出现了，那么自然语言的搜索将不会搜索这类词语。
MySQL数据库从3.23.23版开始支持全文索引，但MySQL5.6.4以前只有Myisam支持，5.6.4版本以后innodb才支持，但是官方版本不支持中文分词，需要第三方分词插件。在5.7.6版本，MySQL内置了ngram全文解析器，用来支持亚洲语种的分词。测试或使用全文索引时，要先看一下自己的MysQL版本、存储引擎和数据类型是否支持全文索引。
随着大数据时代的到来，关系型数据库应对全文索引的需求已力不从心，逐渐被 solr、 ElasticSearch等专门的搜索引擎所替代。
-
空间索引
使用参数SPATIAL可以设置索引为空间索引。空间索引只能建立在空间数据类型上，这样可以提高系统获取空间数据的效率。MySQL中的空间数据类型包括GEOMETRY、POINT、LINESTRING和POLYGON等。目前只有MyISAM存储引擎支持空间检索，而且索引的字段不能为空值。对于初学者来说，这类索引很少会用到。
小结:不同的存储引擎支持的索引类型也不一样
- lnnoDB:支持 B-tree、Full-text 等索引，不支持Hash索引;
- MylSAM:支持B-tree、Full-text等索引，不支持Hash索引;
- Memory :支持B-tree、Hash等索引，不支持Full-text索引;
- NDB :支持Hash 索引，不支持B-tree、Full-text等索引;
- Archive :不支持B-tree、Hash、Full-text等索引;
8.1.2、创建索引
MySQL支持多种方法在单个或多个列上创建索引:在创建表的定义语句CREATE TABLE中指定索引列，使用ALTER TABLE语句在存在的表上创建索引，或者使用CREATE INDEX语句在已存在的表上添加索引。
1. 创建表的时候创建索引
使用CREATE TABLE创建表时，除了可以定义列的数据类型外，还可以定义主键约束、外键约束或者唯一性约束,而不论创建哪种约束，在定义约束的同时相当于在指定列上创建了一个索引（隐式创建）。
# 举例:
CREATE TABLE dept(
dept_id INT PRIMARY KEY AUTO_INCREMENT,
dept_name VARCHAR(20)
);
CREATE TABLE emp(
emp_id INT PRIMARY KEY AUTO_INCREMENT,
emp_name VARCHAR(20) UNIQUE,
dept_id INT,
CONSTRAINT emp_dept_id_fk FOREIGN KEY(dept_id) REFERENCES dept( dept_id)
);
但是，如果显式创建表时创建索引的话，基本语法格式如下:
CREATE TABLE table_name [col_name data_type]
[UNIQUE | FULLTEXT | SPATIAL] [INDEX | KEY] [index_name] (col_name [length]) [ASC | DESC]
-
UNIQUE、FULLTEXT和SPATIAL为可选参数，分别表示唯一索引、全文索引和空间索引； -
INDEX与KEY为同义词，两者的作用相同，用来指定创建索引； -
index_name指定索引的名称，为可选参数，如果不指定，那么MySQL默认col_name为索引名； -
col_name为需要创建索引的字段列，该列必须从数据表中定义的多个列中选择； -
length为可选参数，表示索引的长度，只有字符串类型的字段才能指定索引长度； -
ASC或DESC指定升序或者降序的索引值存储。- 创建普通索引
CREATE TABLE book(
book_id INT,
book_name VARCHAR(100),
authors VARCHAR(100),
info VARCHAR(100) ,
comment VARCHAR(100),
year_publication YEAR,
INDEX(year_publication)
);
#查看索引
SHOW CREATE TABLE book;
SHOW INDEX FROM book;
2. 创建唯一索引
CREATE TABLE test1(
id INT NOT NULL,
name varchar(30) NOT NULL,
UNIQUE INDEX uk_idx_id(id)
);
- 主键索引
CREATE TABLE student (
id INT(10) PRIMARY KEY AUTO_INCREMENT,
student_no VARCHAR(200),
student_name VARCHAR(200)
);
# 删除主键索引
ALTER TABLE student drop PRIMARY KEY;
- 创建单列索引
CREATE TABLE test2(
id INT NOT NULL,
name CHAR(50) NULL,
INDEX single_idx_name(name(20))
);
- 创建组合索引
CREATE TABLE test3(
id INT(11) NOT NULL,
name CHAR(30) NOT NULL,
age INT(11) NOT NULL,
info VARCHAR(255),
INDEX multi_idx(id,name,age)
);
- 创建全文索引
CREATE TABLE `papers` (
id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`title` varchar(200) DEFAULT NULL,
`content` text,
PRIMARY KEY (`id`),
FULLTEXT KEY `title` (`title`,`content`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
#全文索引用match+against方式查询：
SELECT * FROM papers WHERE MATCH(title,content) AGAINST ('查询字符串');
- 创建空间索引
CREATE TABLE test5(
geo GEOMETRY NOT NULL,
SPATIAL INDEX spa_idx_geo(geo)
) ENGINE=MyISAM;
2. 在已经存在的表上创建索引
- 使用ALTER TABLE语句创建索引
ALTER TABLE table_name
ADD [UNIQUE | FULLTEXT | SPATIAL] [INDEX | KEY] [index_name] (col_name[length],...) [ASC | DESC]
- 使用CREATE INDEX创建索引
CREATE [UNIQUE | FULLTEXT | SPATIAL] INDEX index_name
ON table_name (col_name[length],...) [ASC | DESC]
8. 1.3、删除索引
- 使用ALTER TABLE删除索引
ALTER TABLE table_name DROP INDEX index_name;
- 使用DROP INDEX语句删除索引
DROP INDEX index_name ON table_name;
提示：
删除表中的列时，如果要删除的列为索引的组成部分，则该列也会从索引中删除。如果组成索引的所有列都被删除，则整个索引将被删除。
8.2、MySQL8.0索引新特性
8.2.1、支持降序索引
降序索引以降序存储键值。虽然在语法上，从MysQL 4版本开始就已经支持降序索引的语法了，但实际上该DESC定义是被忽略的，直到MysQL 版本才开始真正支持降序索引(仅限于InnoDB存储引擎）。
MySQL在8.0版本之前创建的仍然是升序索引，使用时进行反向扫描，这大大降低了数据库的效率。在某些场景下，降序索引意义重大。例如，如果一个查询，需要对多个列进行排序，且顺序要求不一致，那么使用降序索引将会避免数据库使用额外的文件排序操作，从而提高性能。
举例:分别在MySQL 5.7版本和MySQL 8.0版本中创建数据表ts1，结果如下:
CREATE TABLE ts1(a int,b int,index idx_a_b(a asc,b desc));
在MySQL 5.7版本中查看数据ts1的结构，如下：
从结果中可以看出，索引仍然是默认的升序。
在MySQL8.0版本中查看数据ts1的结构，如下：
从结果可以看出，索引已经是降序了。下面继续测试降序索引在执行计划中的表现。
分别在MySQL 5.7版本和MySQL 版本的数据表ts1中插入8oo条随机数据，执行语句如下:
DELIMITER //
CREATE PROCEDURE ts_insert()
BEGIN
DECLARE i INT DEFAULT 1;
WHILE i < 880
DO
insert into ts1 select rand()*80080, rand ()*80000;
SET i = i + 1;
END WHILE;
commit;
END //
DELIMITER ;
#调用
CALL ts_insert();
在MySQL5.7版本中查看数据表ts1的执行计划，结果如下：
EXPLAIN SELECT * FROM ts1 ORDER BY a,b DESC LIMIT 5;
从结果可以看出，执行计划中扫描数为799，而且使用了Using filesort。
提示
Using filesort是MysQL中一种速度比较慢的外部排序，能避免是最好的。多数情况下，管理员可以通过优化索引来尽量避免出现Using filesort，从而提高数据库执行速度。
在MysQL 8.0版本中查看数据表ts1的执行计划。从结果可以看出，执行计划中扫描数为5，而且没有使用Usingfilesort。
注意
降序索引只对查询中特定的排序顺序有效，如果使用不当，反而查询效率更低。例如，上述查询排序条件改为ORDER BY a DESC, b DESC，MYSQL5.7自执行计划要明显好于MySQL 8.0.
将排序条件修改为order by a desc, b desc后，下面来对比不同版本中执行计划的效果。
在MySQL 5.7版本中查看数据表ts1的执行计划，结果如下:
EXPLAIN SELECT * FROM ts1 ORDER BY a DESC, b DESC LIMIT 5;
在MySQL 8.0版本中查看数据表ts1的执行计划。
从结果可以看出，修改后MySQL 5.7.的执行计划要明显好于MySQL 8.0。
8.2.2、隐藏索引
在MysQL 5.7版本及之前，只能通过显式的方式删除索引。此时，如果发现删除索引后出现错误，又只能通过显式创建索引的方式将删除的索引创建回来。如果数据表中的数据量非常大，或者数据表本身比较大，这种操作就会消耗系统过多的资源，操作成本非常高。
从MySQL 开始支持隐藏索引（invisible indexes），只需要将待删除的索引设置为隐藏索引，使查询优化器不再使用这个索引（即使使用force index（强制使用索引），优化器也不会使用该索引），确认将索引设置为隐藏索引后系统不受任何响应，就可以彻底删除索引。这种通过先将索引设置为隐藏索引，再删除索引的方式就是软删除。
同时，如果你想验证某个索引删除之后的查询性能影响，就可以暂时先隐藏该索引
注意:
主键不能被设置为隐藏索引。当表中没有显式主键时，表中第一个唯一非空索引会成为隐式主键，也不能设置为隐藏索引。
索引默认是可见的，在使用CREATE TABLE，CREATE INDEX或者ALTER TABLE等语句时可以通过VISIBLE或者INVISIBLE关键词设置索引的可见性。
- 创建表时直接创建
CREATE TABLE tablename(
propname1 type1[CONSTRAINT1],
propname2 type2[CONSTRAINT2],
……
propnamen typen,
INDEX [indexname](propname1 [(length)]) INVISIBLE
);
- 在已经存在的表上创建
CREATE INDEX indexname
ON tablename(propname[(length)]) INVISIBLE;
- 通过ALTER TABLE语句创建
ALTER TABLE tablename
ADD INDEX indexname (propname [(length)]) INVISIBLE;
- 切换索引可见状态
ALTER TABLE tablename ALTER INDEX index_name INVISIBLE; #切换成隐藏索引
ALTER TABLE tablename ALTER INDEX index_name VISIBLE; #切换成非隐藏索引
注意
当索引被隐藏时，它的内容仍然是和正常索引一样实时更新的。如果一个索引需要长期被隐藏，那么可以将其删除，因为索引的存在会影响插入、更新和删除的性能。
通过设置隐藏索引的可见性可以查看索引对调优的帮助。
- 使隐藏索引对查询优化器可见
在MysQL 版本中，为索引提供了一种新的测试方式，可以通过查询优化器的一个开关(use_invisible_indexes)来打开某个设置，使隐藏索引对查询优化器可见。如果use_invisible_indexes 设置为off(默认)，优化器会忽略隐藏索引。如果设置为on，即使隐藏索引不可见，优化器在生成执行计划时仍会考虑使用隐藏索引。
(1）在MySQL命令行执行如下命令查看查询优化器的开关设置。
mysql> select @@optimizer_switch \G
在输出的结果信息中找到如下属性配置。
use_invisible_indexes=off
此属性配置值为off，说明隐藏索引默认对查询优化器不可见。
(2）使隐藏索引对查询优化器可见，需要在MySQL命令行执行如下命令:
mysql> set session optimizer_switch="use_invisible_indexes=on";
Query oK,0 rows affected (0.80 sec)
SQL语句执行成功，再次查看查询优化器的开关设置。
8.3、索引的设计原则
为了使索引的使用效率更高，在创建索引时，必须考虑在哪些字段上创建索引和创建什么类型的索引。索引设计不合理或者缺少索引都会对数据库和应用程序的性能造成障碍。高效的索引对于获得良好的性能非常重要。设计索引时，应该考虑相应准则。
8.3.1、哪些情况适合创建索引
- 字段的数值有唯一性的限制
索引本身可以起到约束的作用，比如唯一索引、主键索引都可以起到唯一性约束的，因此在我们的数据表中，如果某个字段是唯一的，就可以直接创建唯一性索引，或者主键索引。这样可以更快速地通过该索引来确定某条记录。
业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。（来源：Alibaba）
说明：不要以为唯一索引影响了insert速度，这个速度损耗可以忽略，但提高查找速度是明显的。
- 频繁作为 WHERE 查询条件的字段
某个字段在SELECT语句的 WHERE 条件中经常被使用到，那么就需要给这个字段创建索引了。尤其是在数据量大的情况下，创建普通索引就可以大幅提升数据查询的效率。
- 经常 GROUP BY 和 ORDER BY的列
索引就是让数据按照某种顺序进行存储或检索，因此当我们使用 GROUP BY 对数据进行分组查询，或者使用 ORDER BY 对数据进行排序的时候，就需要对分组或者排序的字段进行索引。如果待排序的列有多个，那么可以在这些列上建立组合索引。
- UPDATE、DELETE的 WHERE条件列
对数据按照某个条件进行查询后再进行 UPDATE 或 DELETE 的操作，如果对 WHERE 字段创建了索引，就能大幅提升效率。原理是因为我们需要先根据 WHERE 条件列检索出来这条记录，然后再对它进行更新或删除。 如果进行更新的时候，更新的字段是非索引字段，提升的效率会更明显，这是因为非索引字段更新不需要对索引进行维护。
- DISTINCT字段需要创建索引
有时候我们需要对某个字段进行去重，使用 DISTINCT，那么对这个字段创建索引，也会提升查询效率。
- 多表 JOIN、连接操作时，创建索引注意事项
首先，连接表的数量尽量不要超过 3 张，因为每增加一张表就相当于增加了一次嵌套的循环，数量级增长会非常快，严重影响查询的效率。
其次，对 WHERE 条件创建索引，因为 WHERE 才是对数据条件的过滤。如果在数据量非常大的情况下，没有 WHERE 条件过滤是非常可怕的。
最后，对用于连接的字段创建索引，并且该字段在多张表中的类型必须一致。
- 使用列的类型小的创建索引
我们这里所说的类型大小指的就是该类型表示的数据范围的大小。
我们在定义表结构的时候要显式的指定列的类型，以整数类型为例，有TINYINT、MEDIUMINT、INT、BIGINT等，它们占用的存储空间依次递增，能表示的整数范围当然也是依次递增。如果我们想要对某个整数列建立索引的话，在表示的整数范围允许的情况下，尽量让索引列使用较小的类型，比如我们能使用INT就不要使用BIGINT，能使用MEDIUMINT就不要使用INT。这是因为：
- 数据类型越小，在查询时进行的比较操作越快
- 数据类型越小，索引占用的存储空间就越少，在一个数据页内就可以
放下更多的记录，从而减少磁盘I/O带来的性能损耗，也就意味着可以把更多的数据页缓存在内存中，从而加快读写效率。
这个建议对于表的主键来说更加适用，因为不仅是聚簇索引中会存储主键值，其他所有的二级索引的节点处都会存储一份记录的主键值，如果主键使用更小的数据类型，也就意味着节省更多的存储空间和更高效的I/O。
- 使用字符串前缀创建索引
假设我们的字符串很长，那存储一个字符串就需要占用很大的存储空间。在我们需要为这个字符串列建立索引时，那就意味着在对应的B+树中有这么两个问题:
- B+树索引中的记录需要把该列的完整字符串存储起来，更费时。而且字符串越长，在索引中占用的存储空间越大。
- 如果B+树索引中索引列存储的字符串很长，那在做字符串比较时会占用更多的时间。
我们可以通过截取字段的前面一部分内容建立索引，这个就叫前缀索引。这样在查找记录时虽然不能精确的定位到记录的位置，但是能定位到相应前缀所在的位置，然后根据前缀相同的记录的主键值回表查询完整的字符串值。既节约空间，又减少了字符串的比较时间，还大体能解决排序的问题。
区分度计算公式：
count(distinct left(列名, 索引长度))/count(*)
索引列前缀对排序的影响：使用索引列前缀的方式 无法支持使用索引排序，只能使用文件排序
拓展：Alibaba《Java开发手册》
【
强制】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度。说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会
高达 90% 以上，可以使用count(distinct left(列名, 索引长度))/count(*)的区分度来确定。
- 区分度高(散列性高)的列适合作为索引
列的基数指的是某一列中不重复数据的个数，比方说某个列包含值2,5,8,2,5,8,2,5,8，虽然有9条记录，但该列的基数却是3。也就是说， 在记录行数一定的情况下，列的基数越大，该列中的值越分散；列的基数越小，该列中的值越集中。 这个列的基数指标非常重要，直接影响我们是否能有效的利用索引。最好为列的基数大的列建立索引，为基数太小的列建立索引效果可能不好。
可以使用公式select count(distinct a)/count(*) from t1计算区分度，越接近1越好，一般超过33%就算是比较高效的索引了。
拓展：联合索引把区分度高（散列性高）的列放在前面。
-
使用最频繁的列放到联合索引的左侧
-
在多个字段都要创建索引的情况下，联合索引优于单值索引
8.3.2、限制索引的数目
在实际工作中，我们也需要注意平衡，索引的数目不是越多越好。我们需要限制每张表上的索引数量，建议单张表索引数量不超过6个。原因：
- 每个索引都需要占用
磁盘空间，索引越多，需要的磁盘空间就越大。 - 索引会影响
INSERT、DELETE、UPDATE等语句的性能，因为表中的数据更改的同时，索引也会进行调整和更新，会造成负担。 - 优化器在选择如何优化查询时，会根据统一信息，对每一个可以用到的
索引来进行评估，以生成出一个最好的执行计划，如果同时有很多个索引都可以用于查询，会增加MySQL优化器生成执行计划时间，降低查询性能。
8.3.3、哪些情况不适合创建索引
1. 在where中使用不到的字段，不要设置索引
2. 数据量小的表最好不要使用索引
3. 有大量重复数据的列上不要建立索引
4. 避免对经常更新的表创建过多的索引
- 第一层含义：频繁更新的字段不一定要创建索引。因为更新数据的时候，也需要更新索引，如果索引太多，在更新索引的时候也会造成负担，从而影响效率。
- 第二层含义：避免对经常更新的表创建过多的索引，并且索引中的列尽可能少。此时虽然提高了查询速度，同时却会降低更新表的速度。
5. 不建议用无序的值作为索引
- 例如身份证、UUID(在索引比较时需要转为ASCII，并且插入时可能造成页分裂)、MD5、HASH、无序长字符串等。
6. 删除不再使用或者很少使用的索引
- 表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理员应当定期找出这些索引，将它们删除，从而减少索引多更新操作的影响。
7. 不要定义冗余或重复的索引
九、性能分析工具的使用
9.1、数据库服务器的优化步骤
整个流程划分成了 观察（Show status）和 行动（Action）两部分。字母S的部分代表观察（会使用相应的分析工具），字母A代表的部分是行动（对应分析可以采取的行动）。
我们可以通过观察了解数据库整体的运行状态，通过性能分析工具可以让我们了解执行慢的SQL都有哪些，查看具体的SQL执行计划，甚至是SQL执行中的每一步的成本代价，这样才能定位问题所在，找到问题，再采取相应的行动。
# 调优流程图详解：
1. 首先在 S1 部分，我们需要观察服务器的状态是否存在周期性的波动。如果存在周期性波动，有可能是周期性节点的原因，如双十一，促销活动等。这样的话，可以通过 A1 加缓存这一步骤解决，或者更改缓存失效策略。
2. 如果缓存策略没有解决，或者不是周期性波动的原因，就需要进一步分析查询延迟和卡顿的原因。进入开启慢查询 S2 步骤，通过慢查询可用快速定位执行慢的SQL语句。我们可以通过设置 long_query_time 参数定义“慢”的阈值（阈值即边界值），如果SQL执行时间超过了阈值，则认为是慢查询。收集上来这些慢查询的SQL语句之后，我们就可以通过分析工具对慢查询日志进行分析。
3. 在S3这一步骤中，我们就知道了执行慢的sQL，这样就可以针对性地用EXPLAIN查看对应SQL语句的执行计划，或者使用show profile查看sQL中每一个步骤的时间成本。这样我们就可以了解SQL查询慢是因为执行时间长，还是等待时间长。
4. 如果是SQL等待时间长，就进入 A2 步骤。进行调优服务器的参数，比如适当增加数据库缓冲池等。如果是SQL执行时间长，就进入 A3 步骤。可以从三个方面进行优化调整：
- 索引设计优化。比如联合索引就比多个单个索引的查询效率要快一些。
- Join表是否过多。Join表的数据最好不要超过三张，表的数据越多，嵌套循环就越多，查询时间也就越长。
- 数据表设计优化。虽然一般设计数据表都遵循三范式，但是我们可以适当的增加数据冗余度，以空间换取时间提高数据的查询效率。
5. 如果 A2 和 A3 都不能解决问题，就要考虑数据库自身的SQL查询性能是否已经达到了瓶颈，如果确认没有达到性能瓶颈，就需要重新检查也就是重复上述步骤。如果已经达到了性能瓶颈，进入 A4 阶段，需要考虑增加服务器，采用读写分离的架构，或者考虑对数据库进行分库分表，比如垂直分库，垂直分表和水平分表等。
以上就是数据库调优的流程思路。如果我们发现执行sQL时存在不规则延迟或卡顿的时候，就可以采用分析工具帮我们定位有问题的sQL，这三种分析工具你可以理解是sQL调优的三个步骤:慢查询、EXPLAIN和SHoWPROFILING。
9.2、查看系统性能参数
在MySQL中，可以使用SHOW STATUS语句查询一些MySQL数据库服务器的 性能参数、执行频率。
SHOW STATUS语句语法如下：
SHOW [GLOBAL|SESSION] STATUS LIKE '参数';
一些常用的性能参数如下:
- Connections：连接MySQL服务器的次数。.
- Uptime：MySQL服务器的上线时间。
- Slow_queries：慢查询的次数。
- lnnodb_rows_read：select查询返回的行数
- lnnodb_rows_inserted：执行INSERT操作插入的行数
- Innodb_rows_updated：执行UPDATE操作更新的行数
- lnnodb_rows_deleted：执行DELETE操作删除的行数
- com_select：查询操作的次数。
- Com_insert：插入操作的次数。对于批量插入的INSERT操作，只累加一次。
- Com_update：更新操作的次数。
- Com_delete：删除操作的次数。
9.3、统计SQL的查询成本：last_query_cost
SHOW STATUS LIKE 'last_query_cost';
使用场景：它对于比较开销是非常有用的，特别是我们有好几种查询方式可选的时候。
SQL 查询是一个动态的过程，从页加载的角度来看，我们可以得到以下两点结论：
位置决定效率。如果页就在数据库缓冲池中，那么效率是最高的，否则还需要从内存或者磁盘中进行读取，当然针对单个页的读取来说，如果页存在于内存中，会比在磁盘中读取效率高很多。批量决定效率。如果我们从磁盘中对单一页进行随机读，那么效率是很低的（差不多10ms），而采用顺序读取的方式，批量对页进行读取，平均一页的读取效率就会提升很多，甚至要快于单个页面在内存中的随机读取。所以说，遇到I/O并不用担心，方法找对了，效率还是很高的。我们首先要考虑数据存放的位置，如果是经常使用的数据就要尽量放到
缓冲池中，其次我们可以充分利用磁盘的吞吐能力，一次性批量读取数据，这样单个页的读取效率也就得到了提升。
9.4、定位执行慢的SQL：慢查询日志
MySQL的慢查询日志，用来记录在MySQL中响应时间超过阈值的语句，具体指运行时间超过long_query_time的值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10秒以上（不含10秒）的语句，认为是超出了我们的最大忍耐时间值。
默认情况下，MySQL数据库没有开启慢查询日志，需要我们手动来设置这个参数。如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。
9.4.1、开启慢查询日志参数
- 开启slow_query_log
set global slow_query_log='ON';
查看下慢查询日志是否开启，以及慢查询日志文件的位置：
show variables like `%slow_query_log%`;
- 修改long_query_time阈值
show variables like '%long_query_time%';
#测试发现：设置global的方式对当前session的long_query_time失效。对新连接的客户端有效。所以可以一并 执行下述语句
mysql> set global long_query_time = 1;
mysql> show global variables like '%long_query_time%';
mysql> set long_query_time=1;
mysql> show variables like '%long_query_time%';
9.4.2、查看慢查询数目
SHOW GLOBAL STATUS LIKE '%Slow_queries%';
补充说明:
除了上述变量，控制慢查询日志的还有一个系统变量: min_examined_row_limit。这个变量的意思是，查询扫描过的最少记录数。这个变量和查询执行时间，共同组成了判别一个查询是否是慢查询的条件。如果查询扫描过的记录数大于等于这个变量的值，并且查询执行时间超过long_query_time的值，那么，这个查询就被记录到慢查询日志中;反之，则不被记录到慢查询日志中。
mysql> show variables like 'min%'; +-------------------------+-------+ | Variable_namel | Value | +-------------------------+-------+ | min_examined_row_limit | 0 | +-------------------------+-------+ 1 row in set,1 warning ( 0.00 sec)这个值默认是0。与long_query_time=10合在一起，表示只要查询的执行时间超过10秒，哪怕一个记录也没有扫描过，都要被记录到慢查询日志中。你也可以根据需要，通过修改“ "文件，来修改查询时长，或者通过SET指令，用SQL语句修改“min_examined_row_limit”的值。
9.4.3、慢查询日志分析工具：mysqldumpslow
在生产环境中，如果要手工分析日志，查找、分析sQL，显然是个体力活，MysQL提供了日志分析工具mysqldumpslow 。
# 查看mysqldumpslow的帮助信息
mysqldumpslow --help
#得到返回记录集最多的10个SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/
#得到访问次数最多的10个SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/
#得到按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/
#另外建议在使用这些命令时结合 | 和more 使用，否则有可能出现爆屏情况
mysqldumpslow -s r -t 10 /var/lib/mysql/ | more
9.4.4、关闭慢查询日志
方式1：永久性方式
[mysqld]
slow_query_log=OFF
#或
[mysqld]
#slow_query_log=ON
方式2：临时性方式
SET GLOBAL slow_query_log=off;
重启mysql服务，执行如下语句查询慢日志功能
SHOW VARIABLES LIKE '%slow%' ; #查询慢查询日志所在目录
SHOw VARIABLES LIKE '%long_query_time%'; #查询超时时长
9.4.5、删除慢查询日志
使用SHOW语句显示慢查询日志信息，具体sQL语句如下。
SHow VARIABLES LIKE 'slow_query_log%';
从执行结果可以看出，慢查询日志的目录默认为MysQL的数据目录，在该目录下手动删除慢查询日志文件即可。
使用命令mysqladmin flush-logs 来重新生成查询日志文件，具体命令如下，执行完毕会在数据目录下重新生成慢查询日志文件。
mysqladmin -uroot -p flush-logs slow
提示:
慢查询日志都是使用mysqladmin flush-logs命令来删除重建的。使用时一定要注意，一旦执行了这个命令，慢查询日志都只存在新的日志文件中，如果需要旧的查询日志，就必须事先备份。
9.5、查看SQL执行成本：SHOW PROFILE
逻辑架构章节 已经使用过。
Show Profile是MysQL提供的可以用来分析当前会话中SQL都做了什么、执行的资源消耗情况的工具，可用于sql调优的测量。默认情况下处于关闭状态，并保存最近15次的运行结果。
show variables like 'profiling';
#开启
set profiling = 'ON';
#查看
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 -- 显示交换次数相关的开销信息
}
show profiles;
show profile cpu,block io for query 2;
日常开发需注意的结论:
- converting HEAP to MyISAM︰查询结果太大，内存不够，数据往磁盘上搬了。
- creating tmp table:创建临时表。先拷贝数据到临时表，用完后再删除临时表。
- Copying to tmp table on disk:把内存中临时表复制到磁盘上，警惕!
- locked 。
如果在show profile诊断结果中出现了以上4条结果中的任何一条，则sql语句需要优化。
注意：不过 SHOW PROFILE命令将被弃用，我们可以从information_schema 中的profiling数据表进行查看。
9.6、分析查询语句：EXPLAIN
定位了查询慢的SQL之后，我们就可以使用EXPLAIN或DESCRIBE,工具做针对性的分析查询语句。DESCRIBE语句的使用方法与EXPLAIN语句是一样的，并且分析结果也是一样的。
MysQL中有专门负责优化SELECT语句的优化器模块，主要功能:通过计算分析系统中收集到的统计信息，为客户端请求的Query提供它认为最优的执行计划（他认为最优的数据检索方式，但不见得是DBA认为是最优的，这部分最耗费时间)。
这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。MySQL为我们提供了EXPLAIN语句来帮助我们查看某个查询语句的具体执行计划，大家看懂EXPLAIN语句的各个输出项，可以有针对性的提升我们查询语句的性能。
MySQL 5.6.3以前只能EXPLAIN SELECT；MYSQL 5.6.3以后就可以 EXPLAIN SELECT，UPDATE，DELETE
在5.7以前的版本中，想要显示partitions需要使用explain partitions命令；想要显示 filtered 需要使用explain extended命令。在5.7版本后，默认explain直接显示partitions和filtered中的信息。
9.6.1、基本语法
EXPLAIN SELECT select_options
#或者
DESCRIBE SELECT select_options
EXPLAIN 语句输出的各个列的作用如下：
| 列名 | 描述 |
|---|---|
| id | 在一个大的查询语句中每个SELECT关键字都对应一个唯一的id
|
| select_type | SELECT关键字对应的那个查询的类型 |
| table | 表名 |
| partitions | 匹配的分区信息 |
| type | 针对单表的访问方法 |
| possible_keys | 可能用到的索引 |
| key | 实际上使用的索引 |
| key_len | 实际使用到的索引长度 |
| ref | 当使用索引列等值查询时，与索引列进行等值匹配的对象信息 |
| rows | 预估的需要读取的记录条数 |
| filtered | 某个表经过搜索条件过滤后剩余记录条数的百分比 |
| Extra | 一些额外的信息 |
9.6.2、EXPLAIN各列作用
-
table
不论我们的查询语句有多复杂，包含了多少个表 ，到最后也是需要对每个表进行
单表访问的，所以MySQL规定EXPLAIN语句输出的每条记录都对应着某个单表的访问方法 ，该条记录的table列代表着该表的表名（有时不是真实的表名字，可能是简称）。 -
id
-
id如果相同，可以认为是一组，从上往下顺序执行
-
在所有组中，id值越大，优先级越高，越先执行
-
关注点：id号每个号码，表示一趟独立的查询,一个sql的查询趟数越少越好
-
-
select_type
一条大的查询语句里边可以包含若干个SELECT关键字，每个SELECT天键字代表着一个小的查询语句，而每个SELECT关键字的FROM子句中都可以包含若干张表(这些表用来做连接查询)，每一张表都对应着执行计划输出中的一条记录，对于在同一个SELECT关键字中的表来说，它们的id值是相同的。
MySQL为每一个SELECT关键字代表的小查询都定义了一个称之为的属性，意思是我们只要知道了某个小查询的select_type 属性，就知道了这个小查询在整个大查询中扮演了一个什么角色，我们看一下select_type都能取哪些值，请看官方文档:
名称 描述 SIMPLE Simple SELECT (not using UNION or subqueries) PRIMARY Outermost SELECT UNION Second or later SELECT statement in a UNION UNION RESULT Result of a UNION SUBQUERY First SELECT in subquery DEPENDENT SUBQUERY First SELECT in subquery, dependent on outer query DEPENDENT UNION Second or later SELECT statement in a UNION, dependent on outer query DERIVED Derived table MATERIALIZED Materialized subquery UNCACHEABLE SUBQUERY Asubquery for which the result cannot be cached and must be re-evaluated for each row of the outer query UNCACHEABLE UNION The second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY) -
partitions
代表分区表中的命中情况，非分区表，该项为NULL。一般情况下我们的查询语句的执行计划的partitions列的值都是NULL。
-
type（重点）
执行计划的一条记录就代表着MysQL对某个表的执行查询时的访问方法，又称“访问类型”，其中的type列就表:了这个访问方法是啥，是较为重要的一个指标。比如，看到type列的值是ref，表明MySQL即将使用ref访问方法来执行对s1表的查询。
完整的访问方法如下: system，const,，ref，fulltext,ref_or_null,index_merge,unique_subquery , index_subquery , range , index，ALL。
结果值从最好到最坏依次是： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
SQL性能优化的目标：至少要达到 range级别，要求是ref级别，最好是const级别。（阿里巴巴开发手册要求）
-
possible_keys和key
在EXPLAIN语句输出的执行计划中, possible_keys列表示在某个查询语句中，对某个表执行单表查询时可能用到的索引有哪些。一般查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。key列表示实际用到的索引有哪些，如果为NULL，则没有使用索引。
-
key_len（重点）
key_len的长度计算公式：
varchar(10)变长字段且允许NULL = 10 * ( character set： utf8=3,gbk=2,latin1=1)+1(NULL)+2(变长字段)
varchar(10)变长字段且不允许NULL = 10 * ( character set：utf8=3,gbk=2,latin1=1)+2(变长字段)
char(10)固定字段且允许NULL = 10 * ( character set：utf8=3,gbk=2,latin1=1)+1(NULL)
char(10)固定字段且不允许NULL = 10 * ( character set：utf8=3,gbk=2,latin1=1)
-
ref
显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值。
当使用索引列等值匹配的条件去执行查询时，也就是在访问方法是 const、eq_ref、ref、ref_of_null、unique_subquery、index_subquery其中之一时，ref 列展示的就是与索引列作等值匹配的结构是什么，比如只是一个常数或者是某个列。
-
rows（重点）
预估的需要读取的记录条数。。。值越小越好
-
filtered
某个表经过搜索条件过滤后剩余记录条数的百分比
对个单表查询来说，这个filtered列的值没有什么意义，我们更关注连接查询
-
Extra
Extra列是用来说明一些额外信息的，包含不适合在其他列中显示但十分重要的额外信息。我们可以通过这些额外信息来更准确的理解MySQL到底将如何执行给定的查询语句。
- No tables used ——当查询语句没有 ‘from’ 子句时将会提示该额外信息
- Impossible WHERE ——查询语句的 where 子句永远为 false 时将会提示该额外信息
- Using where ——当使用全表扫描来执行对给某个表的查询，并且该语句的 where 子句中有针对该表的搜索条件时，会提示该额外信息；当使用索引访问来执行对某个表的查询，并且该语句的 where 子句中有除了该索引包含的列之外的其他搜索条件时，也会提示该额外信息
- No matching min/max row ——当查询列表处有 MIN 或 MAX 聚合函数，但是并没有符合 WHERE 子句中的搜索条件的记录时
- Using index ——当查询列表以及搜索条件中只包含某个索引的列，也就是在可以使用覆盖索引的情况下，将提示该信息。比方说下边这个查询中只需要用到 idx_key1 而不需要回表操作。
- Using index condition ——有些搜索条件中虽然出现了索引列，但却不能使用到索引。称为索引条件下推。
- Using join buffer ——在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为其分配一块名叫 ‘join buffer’ 的内存块来加快查询速度，也就是我们所讲的 ‘基于块的嵌套循环算法’
- Not exists ——当我们使用左（外）连接时，如果 ‘WHERE’ 子句中包含要求被驱动表的某个列等于 ‘NULL’ 值的搜索条件，而且那个列又是不允许存储 ‘NULL’ 值的，将提示该额外信息。
- Using intersect（…） ——说明准备使用 Intersect 索引合并的方式执行查询，括号中的 ‘…’ 表示需要进行索引合并的索引名称；Using union（…） ——说明准备使用 Union 索引合并的方式执行查询；Using sort_union（…），说明准备使用 Sort-Union 索引合并的方式执行查询。
- Zero limit ——当 limit 子句的参数为 0 时，表示压根儿不打算从表中读取任何记录，将提示该额外信息
- Using filesort ——很多情况下排序操作无法使用到索引，只能在内存中（记录较少的时候）或者磁盘中（记录较多的时候）进行排序，MySQL把这种在内存中或者磁盘上进行排序的方式统称为文件排序。如果某个查询需要文件排序的方式执行查询，将提示该信息
- Using temporary ——在许多查询执行过程中，MySQL可能会借助临时表来完成一些功能，比如去重、排序之类的，比如我们在执行许多包含 ‘DISTINCT’，‘GROUP BY’， 'UNION’等子句的查询过程中，如果不能有效利用索引来完成查询，MySQL很有可能寻求通过建立内部的临时表来执行查询。如果查询中使用到了内部的临时表，将提示该信息。
小结：
- EXPLAIN不考虑各种cache
- EXPLAIN不能显示MySQL在执行查询时所作的优化工作
- EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定文函数对查询的影响情况
- 部分统计信息是估算的，并非精确值
9.7、EXPLAIN的进一步使用
9.7.1、EXPLAIN四种输出格式
这里谈谈EXPLAIN的输出格式。EXPLAIN可以输出四种格式：传统格式，JSON格式，TREE格式以及可视化输出。用户可以根据需要选择适用于自己的格式。
-
传统格式
-
JSON格式
JSON格式：在EXPLAIN单词和真正的查询语句中间加上
FORMAT=JSON。用于查看执行成本cost_infoColumn JSON Name Meaning id select_id The SELECT identifier select_type None The SELECT type table table_name The table for the output row partitions partitions The matching partitions type access_type The join type possible_keys possible_keys The possible indexes to choose key key The index actually chosen key_len key_length The length of the chosen key ref ref The columns compared to the index rows rows Estimate of rows to be examined filtered filtered Percentage of rows filtered by table condition Extra None Additional information -
TREE格式
TREE格式是8.0.16版本之后引入的新格式，主要根据查询的
各个部分之间的关系和各部分的执行顺序来描述如何查询。 -
可视化输出
可视化输出，可以通过MySQL Workbench可视化查看MySQL的执行计划。
9.7.2、SHOW WARNINGS的使用
mysql> EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE s2.common_field IS NOT NULL;
# 查看优化后的执行语句
mysql> SHOW WARNINGS\G
***************************1. roW ***************************
Level : Note
Code : 1003
Message: /* select#1 */ select 'atguigu'.'s1'.'key1' AS 'key1', 'atguigu'.'s2'.'key1' AS 'key1' from 'atguigu'.'s1' join 'atguigu'.'s2' where (( 'atguigu'.'s1'.'key1' = 'atguigu'.'s2'.'key1') and ( 'atguigu'.'s2'.'common_field' is not null))
1 row in set (8.00 sec)
9.8、分析优化器执行计划：trace
OPTIMIZER_TRACE 是MySQL 5.6引入的一项跟踪功能，它可以跟踪优化器做出的各种决策(比如访问表的方法、各种开销计算、各种转换等)，并将跟踪结果记录到INFORMATION_SCHEMALI.OPTIMIZER_TRACE表中。
此功能默认关闭。开启trace，并设置格式为JSON，同时设置trace最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整展示。
# 开启
SET optimizer_trace="enabled=on",end_markers_in_json=on;
# 设置大小
set optimizer_trace_max_mem_size=1000000;
# 使用
select * from student where id < 10;
select * from information_schema.optimizer_trace\G
9.9、MySQL监控分析视图-sys schema
关于MySQL的性能监控和问题诊断，我们一般都从performance_schema中去获取想要的数据，在MySQL5.7.7版本中新增sys schema，它将performance_schernla和information_schema中的数据以更容易理解的方式总结归纳为"视图”，其目的就是为了降低查询performance_schema的复杂度，让DBA能够快速的定位问题。下面看看这些库中都有哪些监控表和视图，掌握了这些，在我们开发和运维的过程中就起到了事半功倍的效果。
9.9.1、Sys schema视图摘要
- 主机相关：以host_summary开头，主要汇总了IO延迟的信息。
- Innodb相关：以innodb开头，汇总了innodb buffer信息和事务等待innodb锁的信息。
- l/o相关：以io开头，汇总了等待I/O、I/o使用量情况。
- 内存使用情况：以memorv开头，从主机、线程、事件等角度展示内存的使用情况
- 连接与会话信息：processlist和session相关视图，总结了会话相关信息。
- 表相关：以schema_table开头的视图，展示了表的统计信息。
- 索引信息：统计了索引的使用情况，包含冗余索引和未使用的索引情况。
- 语句相关：以statement开头，包含执行全表扫描、使用临时表、排序等的语句信息。
- 用户相关：以user开头的视图，统计了用户使用的文件I/o、执行语句统计信息。
- 等待事件相关信息：以wait开头，展示等待事件的延迟情况。
9.9.2、Sys schema视图使用场景
索引情况
#1. 查询冗余索引
select * from sys.schema_redundant_indexes;
#2. 查询未使用过的索引
select * from sys.schema_unused_indexes;
#3. 查询索引的使用情况
select index_name,rows_selected,rows_inserted,rows_updated,rows_deleted from sys.schema_index_statistics where table_schema='dbname' ;
表相关
# 1. 查询表的访问量
select table_schema,table_name,sum(io_read_requests+io_write_requests) as io from sys.schema_table_statistics group by table_schema,table_name order by io desc;
# 2. 查询占用bufferpool较多的表
select object_schema,object_name,allocated,data
from sys.innodb_buffer_stats_by_table order by allocated limit 10;
# 3. 查看表的全表扫描情况
select * from sys.statements_with_full_table_scans where db='dbname';
语句相关
#1. 监控SQL执行的频率
select db,exec_count,query from sys.statement_analysis order by exec_count desc;
#2. 监控使用了排序的SQL
select db,exec_count,first_seen,last_seen,query
from sys.statements_with_sorting limit 1;
#3. 监控使用了临时表或者磁盘临时表的SQL
select db,exec_count,tmp_tables,tmp_disk_tables,query
from sys.statement_analysis where tmp_tables>0 or tmp_disk_tables >0 order by (tmp_tables+tmp_disk_tables) desc;
IO相关
#1. 查看消耗磁盘IO的文件
select file,avg_read,avg_write,avg_read+avg_write as avg_io
from sys.io_global_by_file_by_bytes order by avg_read limit 10;
Innodb相关
#1. 行锁阻塞情况
select * from sys.innodb_lock_waits;
风险提示:
通过sys库去查询时，MySQL会消耗大量资源去收集相关信息，严重的可能会导致业务请求被阻塞，从而引起故障。建议生产上不要频繁的去查询sys或者performance_schema、information_schema来完成监控、巡检等工作。
十、索引优化与查询优化
都有哪些维度可以进行数据库调优?
- 简言之:·索引失效、没有充分利用到索引—―索引建立
- 关联查询太多JOIN(设计缺陷或不得已的需求)——sQL优化。
- 服务器调优及各个参数设置（缓冲、线程数等)――调整
- 数据过多――分库分表
关于数据库调优的知识点非常分散。不同的DBMS，不同的公司，不同的职位，不同的项目遇到的问题都不尽相同。
虽然SQL查询优化的技术有很多，但是大方向上完全可以分成物理查询优化和逻辑查询优化两大块
-
物理查询优化是通过索引和表连接方式等技术来进行优化，这里重点需要掌握索引的使用。
-
逻辑查询优化就是通过SQL等价变换提升查询效率，直白一点就是说，换一种查询写法执行效率可能更高。
10.1、索引失效案例
MySQL中提高性能的一个最有效的方式是对数据表设计合理的索引。索引提供了访问高效数据的方法，并且加快查询的速度，因此索引对查询的速度有着至关重要的影响。
- 使用索引可以
快速地定位表中的某条记录，从而提高数据库查询的速度，提高数据库的性能。 - 如果查询时没有使用索引，查询语句就会
扫描表中的所有记录。在数据量大的情况下，这样查询的速度会很慢。
大多数情况下都（默认）采用B+树来构建索引。只是空间列类型的索引使用R-树，并且MEMORY表还支持hash索引。
其实，用不用索引，最终都是优化器说了算。优化器是基于什么的优化器？基于cost开销(CostBaseOptimizer)，它不是基于规则(Rule-BasedOptimizer)，也不是基于语义。怎么样开销小就怎么来。另外，SQL语句是否使用索引，跟数据库版本、数据量、数据选择度都有关系。
1.1、全值匹配我最爱
# 系统中经常出现的sql语句如下：
EXPLAIN SELECT SQL NO CACHE * FROM student WHERE age=30;
EXPLAIN SELECT sQL NO CACHE * FROM student WHERE age=30 AND classId=4;
EXPLAIN SELECT SQL NO CACHE * FROM student WHERE age=30 AND classId=4 AND NAMB='abcd';
# 建立索引前执行时间： （0.28 sec）
SELECT SQL_NO_CACHE * FROM student WHERE age=30 AND classId=4 AND NAME='abcd';
# 建立索引
CREATE INDEX idx_age ON student(age);
CREATE INDEX idx_age_classid ON student(age, classId);
CREATE INDEX idx_age_classid_name ON student (age, classId, NAME);
# 建立索引后执行时间： （0.01 sec）
1.2、最佳左前缀法则
在MySQL建立联合索引时会遵守最佳左前缀匹配原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。
结论：MySQL可以为多个字段创建索引，一个索引可以包括16个字段。对于多列索引， 过滤条件要使用索引必须按照索引建立时的顺序，依次满足，一旦跳过某个字段，索引后面的字段都无法被使用。 如果查询条件中没有使用这些字段中第1个字段时，多列（或联合）索引不会被使用。
1.3、主键插入顺序
对于一个使用InnoDB存储引擎的表来说，在我们没有显示的创建索引时，表中的数据实际上都是存储在聚簇索引的叶子节点的。而记录又存储在数据页中的，数据页和记录又是按照记录主键值从小到大的顺序进行排序，所以如果我们插入的记录的主键值是依次增大的话，那我们每插满一个数据页就换到下一个数据页继续插，而如果我们插入的主键值忽小忽大的话，则可能会造成页面分裂和记录移位。
1.4、计算、函数、类型转换(自动或手动)导致索引失效
# 索引失效
SELECT SQL_NO_CACHE * FROM student WHERE LEFT(student.name, 3) = 'abc';
1.5、类型转换导致索引失效
# 索引失效
SELECT SQL_NO_CACHE * FROM student WHERE name= 123;
# 使用到索引
SELECT SQL_NO_CACHE * FROM student WHERE name= '123';
1.6、范围条件右边的列索引失效
应用开发中范围查询，例如：金额查询，日期查询往往都是范围查询。应将查询条件放置where语句最后。（创建的联合索引中，务必把范围涉及到的字段写在最后）
CREATE INDEX idx_age_classId_name ON student(age, classId, name);
SELECT SQL_NO_CACHE * FROM student WHERE age=30 ADN classId>20 AND name='abc';
1.7、不等于(!= 或者<>)索引失效
1.8、is null可以使用索引，is not null无法使用索引
结论：最好在设计数据表的时候就将
字段设置为 NOT NULL 约束，比如你可以将INT类型的字段，默认值设置为0。将字符类型的默认值设置为空字符串(‘’)拓展：同理，在查询中使用
not like也无法使用索引，导致全表扫描
1.9、like以通配符%开头索引失效
拓展：Alibaba《Java开发手册》
【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。
# 使用到索引
SELECT SQL_NO_CACHE * FROM student WHERE name LIKE 'abc%';
# 索引失效
SELECT SQL_NO_CACHE * FROM student WHERE name LIKE '%abc';
1.10、OR前后存在非索引的列，索引失效
在WHERE子句中，如果在OR前的条件列进行了索引，而在OR后的条件列没有进行索引，那么索引会失效。也就是说，**OR前后的两个条件中的列都是索引时，查询中才使用索引。
1.11、数据库和表的字符集统一使用utf8mb4
统一使用utf8mb4( 5.5.3版本以上支持)兼容性更好，统一字符集可以避免由于字符集转换产生的乱码。不同的字符集进行比较前需要进行转换会造成索引失效。
一般性建议：
- 对于单列索引，尽量选择针对当前query过滤性更好的索引
- 在选择组合索引的时候，当前query中过滤性最好的字段在索引字段顺序中，位置越靠前越好
- 在选择组合索引的时候，尽量选择能够包含当前query中的where子句中更多字段的索引
- 在选择组合索引的时候，如果某个字段可能出现范围查询时，尽量把这个字段放在索引次序的最后面
总之，书写SQL语句时，尽量避免造成索引失效的情况
10.2、关联查询优化
结论1：对于内连接来说，查询优化器可以决定谁来作为驱动表，谁作为被驱动表出现
结论2：对于内连接来讲，如果表的连接条件中只能有一个字段有索引，则有索引的字段所在的表会被作为被驱动表
结论3：对于内连接来说，在两个表的连接条件都存在索引的情况下，会选择小表作为驱动表。
小表驱动大表
join方式连接多个表，本质就是各个表之间数据的循环匹配。MySQL5.5版本之前，MySQL只支持一种表间关联方式，就是嵌套循环(Nested Loop Join)。如果关联表的数据量很大，则join关联的执行时间会非常长。在MySQL5.5以后的版本中，MySQL通过引入BNLJ算法来优化嵌套执行。
10.2.1、Simple Nested-Loop Join（简单嵌套循环连接）
算法相当简单，从表A中取出一条数据1，遍历表B，将匹配到的数据放到result…以此类推，驱动表A中的每一条记录与被驱动表B的记录进行判断:
可以看到这种方式效率是非常低的，以上述表A数据10o条，表B数据100O条计算，则A*B=10万次。开销统计如下:
| 开销统计 | SNLJ |
|---|---|
| 外表扫描次数: | |
| 内表扫描次数: | A |
| 读取记录数: | A+B*A |
| JOIN比较次数: | B*A |
| 回表读取记录次数: | 0 |
当然mysql肯定不会这么粗暴的去进行表连接，所以就出现了后面的两种Nested-Loop Join优化算法。
10.2.2、Index Nested-Loop Join（索引嵌套循环连接）
Index Nested-Loop Join其优化的思路主要是为了减少内层表数据的匹配次数，所以要求被驱动表上必须有索引才行。通过外层表匹配条件直接与内层表索引进行匹配，避免和内层表的每条记录去比较，这样极大的减少了对内层表的匹配次数。
驱动表中的每条记录通过被驱动表的索引进行访问，因为索引查询的成本是比较固定的，故mysql优化器都倾向与使用记录数少的表作为驱动表（外表）。
如果被驱动表加索引，效率是非常高的，但如果索引不是主键索引，还得进行一次回表查询。相比，被驱动表的索引是主键索引，效率会更高。
10.2.3、Block Nested-Loop Join（块嵌套循环连接）
如果存在索引，那么会使用index的方式进行join，如果join的列没有索引，被驱动表要扫描的次数太多了。每次访问被驱动表，其表中的记录都会被加载到内存中，然后再从驱动表中取一条与其匹配，匹配结束后清除内存，然后再从驱动表中加载一条记录，然后把被驱动表的记录再加载到内存匹配，这样周而复始，大大增加了IO的次数。为了减少被驱动表的IO次数，就出现了Block Nested-Loop Join的方式。
不再是逐条获取驱动表的数据，而是一块一块的获取，引入了join buffer缓冲区，将驱动表join相关的部分数据列（大小受join buffer的限制）缓存到join buffer中，然后全表扫描被驱动表，被驱动表的每一条记录一次性和join buffer中的所有驱动表记录进行匹配（内存中操作），将简单嵌套循环中的多次比较合并成一次，降低了被驱动表的访问频率。
注意：
这里缓存的不只是关联表的列，select后面的列也会缓存起来。
在一个有N个join关联的sql中会分配N-1个join buffer。所以查询的时候尽量减少不必要的字段，可以让join buffer中存放更多的列
参数设置：
- block_nested_loop
通过 show variables like ''%optimizer_switch% 查看 block_nested_lopp 状态。默认是开启的。
- join_buffer_size
驱动表能不能一次加载完，要看join buffer能不能存储所有的数据，默认情况下 join_buffer_size=256k。
join_buffer_size的最大值在32位系统可以申请4G，而在64位操作系统下可以申请大于4G的Join buffer空间（64位windows除外，其最大值会被截断为4GB并发出警告）。
JOIN小结
-
整体效率比较：INLJ > BNLJ > SNLJ
-
永远用小结果集驱动大结果集(其本质就是减少外层循环的数据数量) (小的度量单位指的是 表行数 * 每行大小)
select t1.b,t2.* from t1 straight_join t2 on (t1.b=t2.b) where t2.id<=180; #推荐 select t1.b,t2.* from t2 straight.join t1 on (t1.b=t2.b) where t2.id<=100; #不推荐 -
为被驱动表匹配的条件增加索引(减少内层表的循环匹配次数)
-
增大join buffer size的大小(一次缓存的数据越多，那么内层包的扫表次数就越少)
-
减少驱动表不必要的字段查询（字段越少，join buffer所缓存的数据就越多)
10.2.4、Hash Join
从MySQL的8.0.20版本开始将废弃BNLJ，因为从MySQL8.0.18版本开始就加入了hash join默认都会使用hash join
- Nested Loop：对于被连接的数据子集较小的情况下，Nested Loop是个较好的选择。
- Hash Join是做
大数据集连接时的常用方式，优化器使用两个表中较小（相对较小）的表利用Join Key在内存中建立散列值，然后扫描较大的表并探测散列值，找出与Hash表匹配的行。- 这种方式适用于较小的表完全可以放入内存中的情况，这样总成本就是访问两个表的成本之和。
- 在表很大的情况下并不能完全放入内存，这时优化器会将它分割成
若干不同的分区，不能放入内存的部分就把该分区写入磁盘的临时段，此时要求有较大的临时段从而尽量提高I/O的性能。 - 它能够很好的工作于没有索引的大表和并行查询的环境中，并提供最好的性能。Hash Join只能应用于等值连接，这是由Hash的特点决定的。
小结
- 保证被驱动表的JOIN字段已经创建了索引需要JoIN的字段，数据类型保持绝对一致。
- LEFT JOIN时，选择小表作为驱动表，大表作为被驱动表。减少外层循环的次数。
- INNER JOIN时，MySQL会自动将小结果集的表选为驱动表。选择相信MySQL优化策略。
- 能够直接多表关联的尽量直接关联，不用子查询。(减少查询的趟数)
- 不建议使用子查询，建议将子查询sQL拆开结合程序多次查询，或使用JOIN来代替子查询。
- 衍生表建不了索引
10.3、子查询优化
MysQL从4.1版本开始支持子查询，使用子查询可以进行SELECT语句的嵌套查询，即一个SELECT查询的结果作为另一个SELECT语句的条件。子查询可以一次性完成很多逻辑上需要多个步骤才能完成的SQL操作。
子查询是 **MySQL、的一项重要的功能，可以帮助我们通过一个 **SQL、语句实现比较复杂的查询。但是，子查询的执行效率不高。 原因：
-
执行子查询时，MySQL需要为内层查询语句的查询结果
建立一个临时表，然后外层查询语句从临时表中查询记录。查询完毕后，再撤销这些临时表。这样会消耗过多的CPU和IO资源，产生大量的慢查询。 -
子查询的结果集存储的临时表，不论是内存临时表还是磁盘临时表都
不会存在索引，所以查询性能会受到一定的影响。 -
对于返回结果集比较大的子查询，其对查询性能的影响也就越大。
在MySQL中，可以使用连接（JOIN）查询来替代子查询。 连接查询不需要建立临时表，其速度比子查询要快，如果查询中使用索引的话，性能就会更好。
结论：尽量不要使用NOT IN 或者 NOT EXISTS，用LEFT JOIN xxx ON xx WHERE xx IS NULL替代
10.4、排序优化
-
SQL 中，可以在 WHERE 子句和 ORDER BY 子句中使用索引，目的是在 WHERE 子句中
避免全表扫描，在 ORDER BY 子句避免使用 FileSort排序。当然，某些情况下全表扫描，或者 FileSort 排序不一定比索引慢。但总的来说，我们还是要避免，以提高查询效率。 -
尽量使用 Index 完成 ORDER BY排序。如果 WHERE 和 ORDER BY 后面是相同的列就使用单索引列；如果不同就使用联合索引。
-
无法使用 Index 时，需要对 FileSort 方式进行调优。
所有的排序都是在条件过滤之后才执行的。所以，如果条件过滤掉大部分数据的话，剩下几百几千条数据进行排序其实并不是很消耗性能，即使索引优化了排序，但实际提升性能很有限。
结论:
两个索引同时存在，mysql自动选择最优的方案。(对于这个例子，mysql选择idx_age_stuno_name)。但是，随着数据量的变化，选择的索引也会随之变化的。
当【范围条件】和【group by或者order by】的字段出现二选一时，优先观察条件字段的过滤数量，如果过滤的数据足够多，而需要排序的数据并不多时，优先把索引放在范围字段上。反之，亦然。
filesort算法：双路排序和单路排序
排序的字段若如果不在索引列上，则filesort会有两种算法：双路排序和单路排序
双路排序（慢)
- MySQL 4.1之前是使用双路排序，字面意思就是两次扫描磁盘，最终得到数据，读取行指针和order by列，对他们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读取对应的数据输出。
- 从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。
取一批数据，要对磁盘进行两次扫描，众所周知，lo是很耗时的，所以在mysql4.1之后，出现了第二种改进的算法，就是单路排序。
单路排序(快)
从磁盘读取查询需要的所有列，按照order by列在buffer对它们进行排序，然后扫描排序后的列表进行输出，它的效率更快一些，避免了第二次读取数据。并且把随机lO变成了顺序IO，但是它会使用更多的空间，因为它把每一行都保存在内存中了。
结论及引申出的问题
- 由于单路是后出的，总体而言好过双路
- 但是用单路有问题
- 在sort_buffer中，单路比多路要多占用很多空间，因为单路是把所有字段都取出,所以有可能取出的数据的总大小超出了sort_buffer的容量，导致每次只能取sort_buffer容量大小的数据，进行排序〈创建tmp文件，多路合并)，排完再取sort_buffer容量大小，再排…从而多次I/O。
- 单路本来想省一次l/o操作，反而导致了大量的I/0操作，反而得不偿失。
10.5、GROUP BY优化
- group by 使用索引的原则几乎跟order by一致 ，group by 即使没有过滤条件用到索引，也可以直接使用索引。
- group by 先排序再分组，遵照索引建的最佳左前缀法则
- 当无法使用索引列，可以增大
max_length_for_sort_data和sort_buffer_size参数的设置 - where效率高于having，能写在where限定的条件就不要写在having中了
- 减少使用order by，和业务沟通能不排序就不排序，或将排序放到程序端去做。Order by、group by、distinct这些语句较为耗费CPU，数据库的CPU资源是极其宝贵的。
- 包含了order by、group by、distinct这些查询的语句，where条件过滤出来的结果集请保持在1000行以内，否则SQL会很慢。
10.6、优化分页查询
优化思路一
在索引上完成排序分页操作，最后根据主键关联回原表查询所需要的其他列内容。
EXPLAIN SELECT * FROM student t,(SELECT id FROM student ORDER BY id LIMIT 2000000,10) a
WHERE t.id = a.id;
优化思路二
该方案适用于主键自增的表，可以把Limit 查询转换成某个位置的查询。
EXPLAIN SELECT * FROM student WHERE id > 2000000 LIMIT 10;
10.7、优先考虑覆盖索引
7.1、什么是覆盖索引？
理解方式一 ：索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据；当能通过读取索引就可以得到想要的数据，那就不需要读取行了。一个索引包含了满足查询结果的数据就叫做覆盖索引。
理解方式二 ：非聚簇复合索引的一种形式，它包括在查询里的SELECT、JOIN和WHERE子句用到的所有列（即建索引的字段正好是覆盖查询条件中所涉及的字段）。
简单说就是，索引列+主键包含SELECT 到 FROM之间查询的列。
7.2、覆盖索引的利弊
好处：
-
避免Innodb表进行索引的二次查询（回表）
Innodb是以聚集索引的顺序来存储的，对于Innodb来说，二级索引7子节点中所保存的是行的主键信息，如果是用二级索引查询数据，在查找到相应的键值后，还需通过主键进行二次查询才能获取我们真实所需要的数据。
在覆盖索引中，二级索引的键值中可以获取所要的数据，避免了对主键的二次查询，减少了IO操作，提升了查询效率。
-
可以把随机IO变成顺序IO加快查询效率
由于覆盖索引是按键值的顺序存储的，对于I0密集型的范围查找来说，对比随机从磁盘读取每一行的数据lo要少的多，因此利用覆盖索引在访问时也可以把磁盘的随机读取的IO转变成索引查找的顺序IO。
弊端：
索引字段的维护总是有代价的。因此，在建立冗余索引来支持覆盖索引时就需要权衡考虑了。这是业务DBA，或者称为业务数据架构师的工作。
10.8、索引条件下推
Index Condition Pushdown(ICP)是MySQL 5.6中新特性，是一种在存储引擎层使用索引过滤数据的优化方式。
- 如果没有ICP，存储引擎会遍历索引以定位基表中的行，并将它们返回给MySQL服务器，由MySQL服务器评估WHERE后面的条件是否保留行。
- 启用ICP后，如果部分WHERE条件可以仅使用索引中的列进行筛选，则MySQL服务器会把这部分WHERE条件放到存储引擎筛选。然后，存储引擎通过使用索引条目来筛选数据，并且只有在满足这一条件时才从表中读取行。
- 好处：ICP可以减少存储引擎必须访问基表的次数和MysQL服务器必须访问存储引擎的次数。
- 但是，ICP的加速效果取决于在存储引擎内通过ICP筛选掉的数据的比例。
10.8.1、使用前后的扫描过程
在不使用ICP索引扫描的过程：
-
storage层：只将满足index key条件的索引记录对应的整行记录取出，返回给server层
-
server 层：对返回的数据，使用后面的where条件过滤，直至返回最后一行。
使用ICP扫描的过程：
-
storage层：首先将index key条件满足的索引记录区间确定，然后在索引上使用index filter进行过滤。将满足的index filter条件的索引记录才去回表取出整行记录返回server层。不满足index filter条件的索引记录丢弃，不回表、也不会返回server层。
-
server 层：对返回的数据，使用table filter条件做最后的过滤。
10.8.2、ICP的开启/关闭
默认情况下启用索引条件下推。可以通过设置系统变量 optimizer_switch 控制：index_condition_pushdown
#打开索引下推
SET optimizer_switch = 'indeI_condition_pushdown=off';
#关闭索引下推
SET optimizer_switch = 'index_condition_pushdown=on ';
当使用索引条件下推时，EXPLAIN语句输出结果中Extra列内容显示为Using index condition
10.8.3、ICP的使用条件
- 如果表访问的类型为range、ref、eq_ref和ref_or_null可以使用ICP
- ICP可以用于InnoDB和MyISAM表，包括分区表InnoDB和MyISAM表
- 对于InnoDB表，ICP仅用于二级索引。ICP的目标是减少全行读取次数，从而减少I/O操作。
- 当sQL使用覆盖索引时，不支持ICP。因为这种情况下使用ICP不会减少I/O。
- 相关子查询的条件不能使用ICP
10.9、其它查询优化策略
10.9.1、EXISTS、和IN的区分
索引是个前提，其实选择与否还会要看表的大小。你可以将选择的标准理解为小表驱动大表。
10.9.2、COUNT(*)与COUNT(具体字段)效率
环节1： COUNT(*)和COUNT(1)都是对所有结果进行COUNT，COUNT(*)和COUNT(1)本质上并没有区别（二者执行时间可能略有差别，不过你还是可以把它俩的执行效率看成是相等的）。如果有WHERE子句，则是对所有符合筛选条件的数据行进行统计；如果没有WHERE子句，则是对数据表的数据行数进行统计。
环节2： 如果是MyISAM存储引擎，统计数据表的行数只需要O(1)的复杂度，这是因为每张MyISAM的数据表都有一个meta信息存储了row_count值，而一致性则是由表级锁来保证的。
如果是InnoDB存储引擎，因为InnoDB支持事务，采用行级锁和MVCC机制，所以无法像MyISAM一样，维护一个row_count变量，因此需要采用扫描全表，是O(n)的复杂度，进行循环+计数的方式来完成统计。
环节3： 在InnoDB引擎中，如果采用COUNT(具体字段)来统计数据行数，要尽量采用二级索引。因为主键采用的索引是聚簇索引，聚簇索引包含的信息多，明显会大于二级索引（非聚簇索引）。对于COUNT(*)和COUNT(1)来说，它们不需要查找具体的行，只是统计行数，系统会自动采用占用空间更小的二级索引来进行统计。
如果有多个二级索引，会使用key_len小的二级索引进行扫描。当没有二级索引的时候，才会采用主键索引来进行统计。
9.3、关于SELECT(*)
在表查询中，建议明确字段，不要使用 * 作为查询的字段列表，推荐使用SELECT <字段列表> 查询。原因：
① MySQL 在解析的过程中，会通过查询数据字典将"*"按序转换成所有列名，这会大大的耗费资源和时间。
② 无法使用覆盖索引
9.4、LIMIT 1对优化的影响
针对的是会扫描全表的 SQL 语句，如果你可以确定结果集只有一条，那么加上LIMIT 1的时候，当找到一条结果的时候就不会继续扫描了，这样会加快查询速度。
如果数据表已经对字段建立了唯一索引，那么可以通过索引进行查询，不会全表扫描的话，就不需要加上LIMIT 1了。
9.5、多使用COMMIT
只要有可能，在程序中尽量多使用 COMMIT，这样程序的性能得到提高，需求也会因为 COMMIT 所释放的资源而减少。
COMMIT 所释放的资源：
-
回滚段上用于恢复数据的信息
-
被程序语句获得的锁
-
redo / undo log buffer 中的空间
-
管理上述 3 种资源中的内部花费
十一、数据库的设计规范
11.1、范 式
11.1.1、范式简介
在关系型数据库中，关于数据表设计的基本原则、规则就称为范式。 可以理解为，一张数据表的设计结构需要满足的某种设计标准的级别。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
11.1.2、范式都包括哪些
目前关系型数据库有六种常见范式，按照范式级别，从低到高分别是： 第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式） 。
数据库的范式设计越高阶，冗余度就越低，同时高阶的范式一定符合低阶范式的要求，满足最低要求的范式是第一范式。一般来说，在关系型数据库设计中，最高也就遵循到BCNF，普遍还是3NF。
11.1.3、键和相关属性的概念
- 超键：能唯─标识元组的属性集叫做超键。
- 候选键：如果超键不包括多余的属性，那么这个超键就是候选键。
- 主键：用户可以从候选键中选择一个作为主键。
- 外键：如果数据表R1中的某属性集不是R1的主键，而是另一个数据表R2的主键，那么这个属性集就是数据表R1的外键。
- 主属性：包含在任一候选键中的属性称为主属性。
- 非主属性：与主属性相对，指的是不包含在任何一个候选键中的属性。
通常，我们也将候选键称之为“码”，把主键也称为“主码”。因为键可能是由多个属性组成的，针对单个属性，我们还可以用主属性和非主属性来进行区分。
11.1.4、第一范式(1st NF)
第一范式主要是确保数据表中每个字段的值必须具有原子性，也就是说数据表中每个字段的值为不可再次拆分的最小数据单位。
11.1.5、第二范式(2nd NF)
第二范式要求，在满足第一范式的基础上，还要满足数据表里的每一条数据记录，都是可唯一标识的。而且所有非主键字段，都必须完全依赖主键，不能只依赖主键的一部分。 如果知道主键的所有属性的值，就可以检索到任何元组（行）的任何属性的任何值。
对非主属性来说，并非完全依赖候选键。
11.1.6、第三范式(3rd NF)
第三范式是在第二范式的基础上，确保数据表中的每一个非主键字段都和主键字段直接相关，也就是说， 要求数据表中的所有非主键字段不能依赖于其他非主键字段。 （即，不能存在非主属性A依赖于非主属性B，非主属性B依赖于主键C的情况，即存在"A–>B–>C"的决定关系）通俗地讲，该规则的意思是所有非主键属性之间不能有依赖关系，必须相互独立。
11.1.7、小结
关于数据表的设计，有三个范式要遵循。
（1）第一范式（1NF），确保每列保持原子性
数据库的每一列都是不可分割的原子数据项，不可再分的最小数据单元，而不能是集合、数组、记录等非原子数据项。
（2）第二范式（2NF），确保每列都和主键完全依赖
尤其在复合主键的情况向下，非主键部分不应该依赖于部分主键。
（3）第三范式（3NF），确保每列都和主键直接相关，而不是间接相关
范式的优点： 数据的标准化有助于消除数据库中的数据冗余，第三范式（3NF）通常被认为在性能、拓展性和数据完整性方面达到了最好的平衡。
范式的缺点： 范式的使用，可能降低查询的效率。因为范式等级越高，设计出来的数据表就越多、越精细，数据的冗余度就越低，进行数据查询的时候就可能需要关联多张表，这不但代价昂贵，也可能使一些索引策略无效。
范式只是提出了设计的标准，实际上设计数据表时，未必一定要符合这些标准。开发中，我们会出现为了性能和读取效率违反范式化的原则，通过增加少量的冗余或重复的数据来提高数据库的读性能，减少关联查询，join表的次数，实现空间换取时间的目的。因此在实际的设计过程中要理论结合实际，灵活运用。
11.2. 反范式化
2.1、概述
规范化vs性能
-
为满足某种商业目标 , 数据库性能比规范化数据库更重要
-
在数据规范化的同时 , 要综合考虑数据库的性能
-
通过在给定的表中添加额外的字段，以大量减少需要从中搜索信息所需的时间
-
通过在给定的表中插入计算列，以方便查询
2.2、反范式的新问题
- 存储
空间变大了 - 一个表中字段做了修改，另一个表中冗余的字段也需要做同步修改，否则
数据不一致 - 若采用存储过程来支持数据的更新、删除等额外操作，如果更新频繁，会非常
消耗系统资源 - 在
数据量小的情况下，反范式不能体现性能的优势，可能还会让数据库的设计更加复杂
2.3、反范式的适用场景
当冗余信息有价值或者能大幅度提高查询效率的时候，我们才会采取反范式的优化。
1. 增加冗余字段的建议
- 这个冗余字段`不需要经常进行修改`
- 这个冗余字段`查询的时候不可或缺`
- 历史快照、历史数据的需要
在现实生活中，我们经常需要一些冗余信息，比如订单中的收货人信息，包括姓名、电话和地址等。每次发生的订单收货信息都属于历史快照，需要进行保存，但用户可以随时修改自己的信息，这时保存这些冗余信息是非常有必要的。
反范式优化也常用在数据仓库的设计中，因为数据仓库通常存储历史数据，对增删改的实时性要求不强历史数据的分析需求强。这时适当允许数据的冗余度，更方便进行数据分析。
11.3、BCNF(巴斯范式)
在3NF的基础上进行了改进，提出了巴斯范式（BCNF），也叫作巴斯-科德范式。BCNF被认为没有新的设计规范加入，知识对第三范式中涉及规范要求更强，是的数据库冗余度更小。所以是 修正的第三范式，或 扩充的第三范式。
若一个关系达到了第三范式，并且它只有一个候选键，或者它的每个候选键都是单属性，则该关系自然达到BC范式。
11.4、ER模型
ER模型也叫做实体关系模型，是用来描述现实生活中客观存在的事物、事物的属性，以及事物之间关系的一种数据模型。 在开发基于数据库的信息系统的设计阶段，通常使用ER模型来描述信息需要和信息特性，帮助我们理清业务逻辑，从而设计出优秀的数据库。
4.1、ER 模型包括那些要素？
ER模型中有三个要素，分别是实体、属性和关系 。
实体，可以看做是数据对象，往往对应于现实生活中的真实存在的个体。在 ER 模型中，用矩形来表示。实体分为两类，分别是强实体和弱实体。强实体是指不依赖于其他实体的实体；弱实体是指对另一个实体有很强的依赖关系的实体。
属性，则是指实体的特性。比如超市的地址、联系电话、员工数等。在 ER 模型中用椭圆形来表示。
关系，则是指实体之间的联系。比如超市把商品卖给顾客，就是一种超市与顾客之间的联系。在 ER 模型中用菱形来表示。
注意：实体和属性不容易区分。这里提供一个原则：我们要从系统整体的角度出发去看， 可以独立存在的是实体，不可再分的是属性 。也就是说，属性不能包含其他属性。
4.2、关系的类型
在 ER 模型的 3 个要素中，关系又可以分为 3 种类型，分别是 一对一、一对多、多对多。
一对一：指实体之间的关系是一一对应的
一对多：指一边的实体通过关系，可以对应多个另外一边的实体。相反，另外一边的实体通过这个关系，则只能对应唯一的一边的实体
多对多：指关系两边的实体都可以通过关系对应多个对方的实体
5. 数据表的设计原则
数据表设计的一般原则：“三少一多”
-
数据表的个数越少越好
RDBMS的核心在于对实体和联系的定义，也就是E-R图(Entity Relationship Diagram)，数据表越少，证明实体和联系设计得越简洁，既方便理解又方便操作。
-
数据表中的字段个数越少越好
字段个数越多，数据冗余的可能性越大。设置字段个数少的前提是各个字段相互独立，而不是某个字段的取值可以由其他字段计算出来。当然字段个数少是相对的，我们通常会在数据冗余和检索效率中进行平衡。
-
数据表中联合主键的字段个数越少越好
设置主键是为了确定唯一性，当一个字段无法确定唯一性的时候，就需要采用联合主键的方式(也就是用多个字段来定义一个主键)。联合主键中的字段越多，占用的索引空间越大，不仅会加大理解难度，还会增加运行时间和索引空间，因此联合主键的字段个数越少越好。
-
使用主键和外键越多越好
数据库的设计实际上就是定义各种表，以及各种字段之间的关系。这些关系越多，证明这些实体之间的冗余度越低，利用度越高。这样做的好处在于不仅保证了数据表之间的独立性，还能提升相互之间的关联使用率。
注意：这个原则并不是绝对的，有时候我们需要牺牲数据的冗余度来换取数据处理的效率。
6. 数据库对象编写建议
6.1、关于库
-
【强制】库的名称必须控制在32个字符以内，只能使用英文字母、数字和下划线，建议以英文字母开头。
-
【强制】库名中英文
一律小写，不同单词采用下划线分割。须见名知意。 -
【强制】库的名称格式：业务系统名称_子系统名。
-
【强制】库名禁止使用关键字（如type,order等）。
-
【强制】创建数据库时必须
显式指定字符集，并且字符集只能是utf8或者utf8mb4。创建数据库SQL举例：CREATE DATABASE crm_fundDEFAULT CHARACTER SET 'utf8'; -
【建议】对于程序连接数据库账号，遵循
权限最小原则。使用数据库账号只能在一个DB下使用，不准跨库。程序使用的账号原则上不准有drop权限。 -
【建议】临时库以
tmp_为前缀，并以日期为后缀；备份库以bak_为前缀，并以日期为后缀。
6.2、关于表、列
-
【强制】表和列的名称必须控制在32个字符以内，表名只能使用英文字母、数字和下划线，建议以
英文字母开头。 -
【强制】
表名、列名一律小写，不同单词采用下划线分割。须见名知意。 -
【强制】表名要求有模块名强相关，同一模块的表名尽量使用
统一前缀。比如：crm_fund_item -
【强制】创建表时必须
显式指定字符集为utf8或utf8mb4。 -
【强制】表名、列名禁止使用关键字（如type,order等）。
-
【强制】创建表时必须
显式指定表存储引擎类型。如无特殊需求，一律为InnoDB。 -
【强制】建表必须有comment。
-
【强制】字段命名应尽可能使用表达实际含义的英文单词或
缩写。如：公司 ID，不要使用 corporation_id, 而用corp_id 即可。 -
【强制】布尔值类型的字段命名为
is_描述。如member表上表示是否为enabled的会员的字段命名为 is_enabled。 -
【强制】禁止在数据库中存储图片、文件等大的二进制数据。
通常文件很大，短时间内造成数据量快速增长，数据库进行数据库读取时，通常会进行大量的随机IO操作，文件很大时，IO操作很耗时。通常存储于文件服务器，数据库只存储文件地址信息。
-
【建议】建表时关于主键：
表必须有主键(1)强制要求主键为id，类型为int或bigint，且为auto_increment 建议使用unsigned无符号型。
(2)标识表里每一行主体的字段不要设为主键，建议设为其他字段如user_id，order_id等，并建立unique key索引。因为如果设为主键且主键值为随机插入，则会导致innodb内部页分裂和大量随机I/O，性能下降。
-
【建议】核心表（如用户表）必须有行数据的
创建时间字段（create_time）和最后更新时间字段（update_time），便于查问题。 -
【建议】表中所有字段尽量都是
NOT NULL属性，业务可以根据需要定义DEFAULT值。因为使用NULL值会存在每一行都会占用额外存储空间、数据迁移容易出错、聚合函数计算结果偏差等问题。
-
【建议】所有存储相同数据的
列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低）。 -
【建议】中间表（或临时表）用于保留中间结果集，名称以
tmp_开头。备份表用于备份或抓取源表快照，名称以
bak_开头。中间表和备份表定期清理。66 -
【示范】一个较为规范的建表语句：
CREATE TABLE user_info (
`id` int unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
`user_id` bigint(11) NOT NULL COMMENT '用户id',
`username` varchar(45) NOT NULL COMMENT '真实姓名',
`email` varchar(30) NOT NULL COMMENT '用户邮箱',
`nickname` varchar(45) NOT NULL COMMENT '昵称',
`birthday` date NOT NULL COMMENT '生日',
`sex` tinyint(4) DEFAULT '0' COMMENT '性别',
`short_introduce` varchar(150) DEFAULT NULL COMMENT '一句话介绍自己，最多50个汉字',
`user_resume` varchar(300) NOT NULL COMMENT '用户提交的简历存放地址',
`user_register_ip` int NOT NULL COMMENT '用户注册时的源ip',
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
`user_review_status` tinyint NOT NULL COMMENT '用户资料审核状态，1为通过，2为审核中，3为未 通过，4为还未提交审核',
PRIMARY KEY (`id`),
UNIQUE KEY `uniq_user_id` (`user_id`),
KEY `idx_username`(`username`),
KEY `idx_create_time_status`(`create_time`,`user_review_status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='网站用户基本信息'
- 【建议】创建表时，可以使用可视化工具。这样可以确保表、字段相关的约定都能设置上。实际上，我们通常很少自己写 DDL 语句，可以使用一些可视化工具来创建和操作数据库和数据表。可视化工具除了方便，还能直接帮我们将数据库的结构定义转化成 SQL 语言，方便数据库和数据表结构的导出和导入。
6.3、关于索引
-
【强制】InnoDB表必须主键为id int/bigint auto_increment，且主键值
禁止被更新。 -
【强制】InnoDB和MyISAM存储引擎表，索引类型必须为
BTREE。 -
【建议】主键的名称以
pk_开头，唯一键以uni_或uk_开头，普通索引以idx_开头，一律使用小写格式，以字段的名称或缩写作为后缀。 -
【建议】多单词组成的columnname，取前几个单词首字母，加末单词组成column_name。如: sample 表 member_id 上的索引：idx_sample_mid。
-
【建议】单个表上的索引个数
不能超过6个。 -
【建议】在建立索引时，多考虑建立
联合索引，并把区分度最高的字段放在最前面。 -
【建议】在多表 JOIN 的SQL里，保证被驱动表的连接列上有索引，这样JOIN 执行效率最高。
-
【建议】建表或加索引时，保证表里互相不存在
冗余索引。 比如：如果表里已经存在key(a,b)， 则key(a)为冗余索引，需要删除。
6.4、SQL编写
-
【强制】程序端SELECT语句必须指定具体字段名称，禁止写成 *。
-
【建议】程序端insert语句指定具体字段名称，不要写成INSERT INTO t1 VALUES(…)。
-
【建议】除静态表或小表（100行以内），DML语句必须有WHERE条件，且使用索引查找。
-
【建议】INSERT INTO…VALUES(XX),(XX),(XX)… 这里XX的值不要超过5000个。 值过多虽然上线很快，但会引起主从同步延迟。
-
【建议】SELECT语句不要使用UNION，推荐使用UNION ALL，并且UNION子句个数限制在5个以内。
-
【建议】线上环境，多表 JOIN 不要超过5个表。
-
【建议】减少使用ORDER BY，和业务沟通能不排序就不排序，或将排序放到程序端去做。ORDER BY、GROUP BY、DISTINCT 这些语句较为耗费CPU，数据库的CPU资源是极其宝贵的。
-
【建议】包含了ORDER BY、GROUP BY、DISTINCT 这些查询的语句，WHERE 条件过滤出来的结果集请保持在1000行以内，否则SQL会很慢。
-
【建议】对单表的多次alter操作必须合并为一次。对于超过100W行的大表进行alter table，必须经过DBA审核，并在业务低峰期执行，多个alter需整合在一起。 因为alter table会产生
表锁，期间阻塞对于该表的所有写入，对于业务可能会产生极大影响。 -
【建议】批量操作数据时，需要控制事务处理间隔时间，进行必要的sleep。
-
【建议】事务里包含SQL不超过5个。因为过长的事务会导致锁数据较久，MySQL内部缓存、连接消耗过多等问题。
-
【建议】事务里更新语句尽量基于主键或UNIQUE KEY，如UPDATE… WHERE id=XX；否则会产生间隙锁，内部扩大锁定范围，导致系统性能下降，产生死锁。
十二、数据库其它调优策略
12.1、数据库调优的措施
12.1.1、调优的目标
- 尽可能
节省系统资源，以便系统可以提供更大负荷的服务。（吞吐量更大） - 合理的结构设计和参数调整，以提高用户操
响应的速度。（响应速度更快） - 减少系统的瓶颈，提高MySQL数据库整体的性能。
12.1.2、如何定位调优问题
- 用户的反馈（主要）
- 日志分析（主要）
- 服务器资源使用监控
- 数据库内部状况监控
- 其它
12.1.3、调优的维度和步骤
第1步：选择适合的 DBMS
第2步：优化表设计
第3步：优化逻辑查询
第4步：优化物理查询
物理查询优化是在确定了逻辑查询优化之后，采用物理优化技术（比如索引等），通过计算代价模型对各种可能的访问路径进行估算，从而找到执行方式中代价最小的作为执行计划。（重点掌握索引的创建和使用）
第5步：使用 Redis或 Memcached 作为缓存
第6步：库级优化
1、读写分离
如果读和写的业务量都很大，并且它们都在同一个数据库服务器中进行操作，那么数据库的性能就会出现瓶颈这时为了提升系统的性能，优化用户体验，我们可以采用读写分离的方式降低主数据库的负载，比如用主数据库(master)完成写操作，用从数据库(slave）完成读操作。
2、数据分片
对数据库分库分表。当数据量级达到千万级以上时，有时候我们需要把一个数据库切成多份，放到不同的数据库服务器上，减少对单一数据库服务器的访问压力。如果你使用的是MySQL，就可以使用MySQL自带的分区表功能，当然你也可以考虑自己做垂直拆分（分库）、水平拆分（分表)、垂直+水平拆分(分库分表)。
12.2、优化MySQL服务器
12.2.1、优化服务器硬件
服务器的硬件性能直接决定着MySQL数据库的性能。 硬件的性能瓶颈直接决定MySQL数据库的运行速度和效率。针对性能瓶颈提高硬件配置，可以提高MySQL数据库查询、更新的速度。
（1）配置较大的内存
（2）配置高速磁盘系统
（3）合理分布磁盘I/O
（4）配置多处理器
12.2.2、优化MySQL的参数
-
innodb_buffer_pool_size：这个参数是Mysql数据库最重要的参数之一，表示InnoDB类型的表和索引的最大缓存。它不仅仅缓存索引数据，还会缓存表的数据。这个值越大，查询的速度就会越快。但是这个值太大会影响操作系统的性能。 -
key_buffer_size：表示索引缓冲区的大小。索引缓冲区是所有的线程共享。增加索引缓冲区可以得到更好处理的索引（对所有读和多重写）。当然，这个值不是越大越好，它的大小取决于内存的大小。如果这个值太大，就会导致操作系统频繁换页，也会降低系统性能。对于内存在4GB左右的服务器该参数可设置为256M或384M。 -
table_cache：表示同时打开的表的个数。这个值越大，能够同时打开的表的个数越多。物理内存越大，设置就越大。默认为2402，调到512-1024最佳。这个值不是越大越好，因为同时打开的表太多会影响操作系统的性能。 -
query_cache_size：表示查询缓冲区的大小。可以通过在MySQL控制台观察，如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况，就要增加Query_cache_size的值；如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓存；Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多。MySQL8.0之后失效。该参数需要和query_cache_type配合使用。 -
query_cache_type的值是0时，所有的查询都不使用查询缓存区。但是query_cache_type=0并不会导致MySQL释放query_cache_size所配置的缓存区内存。- 当query_cache_type=1时，所有的查询都将使用查询缓存区，除非在查询语句中指定
SQL_NO_CACHE，如SELECT SQL_NO_CACHE * FROM tbl_name。 - 当query_cache_type=2时，只有在查询语句中使用
SQL_CACHE关键字，查询才会使用查询缓存区。使用查询缓存区可以提高查询的速度，这种方式只适用于修改操作少且经常执行相同的查询操作的情况。
- 当query_cache_type=1时，所有的查询都将使用查询缓存区，除非在查询语句中指定
-
sort_buffer_size：表示每个需要进行排序的线程分配的缓冲区的大小。增加这个参数的值可以提高ORDER BY或GROUP BY操作的速度。默认数值是2 097 144字节（约2MB）。对于内存在4GB左右的服务器推荐设置为6-8M，如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。 -
join_buffer_size = 8M：表示联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每个连接独享。 -
read_buffer_size：表示每个线程连续扫描时为扫描的每个表分配的缓冲区的大小（字节）。当线程从表中连续读取记录时需要用到这个缓冲区。SET SESSION read_buffer_size=n可以临时设置该参数的值。默认为64K，可以设置为4M。 -
innodb_flush_log_at_trx_commit：表示何时将缓冲区的数据写入日志文件，并且将日志文件写入磁盘中。该参数对于innoDB引擎非常重要。该参数有3个值，分别为0、1和2。该参数的默认值为1。- 值为
0时，表示每秒1次的频率将数据写入日志文件并将日志文件写入磁盘。每个事务的commit并不会触发前面的任何操作。该模式速度最快，但不太安全，mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。 - 值为
1时，表示每次提交事务时将数据写入日志文件并将日志文件写入磁盘进行同步。该模式是最安全的，但也是最慢的一种方式。因为每次事务提交或事务外的指令都需要把日志写入（flush）硬盘。 - 值为
2时，表示每次提交事务时将数据写入日志文件，每隔1秒将日志文件写入磁盘。该模式速度较快，也比0安全，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。
- 值为
-
innodb_log_buffer_size：这是 InnoDB 存储引擎的事务日志所使用的缓冲区。为了提高性能，也是先将信息写入 Innodb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。 -
max_connections：表示 允许连接到MySQL数据库的最大数量 ，默认值是 151 。如果状态变量connection_errors_max_connections 不为零，并且一直增长，则说明不断有连接请求因数据库连接数已达到允许最大值而失败，这是可以考虑增大max_connections 的值。在Linux 平台下，性能好的服务器，支持 500-1000 个连接不是难事，需要根据服务器性能进行评估设定。这个连接数 不是越大 越好 ，因为这些连接会浪费内存的资源。过多的连接可能会导致MySQL服务器僵死。 -
back_log：用于控制MySQL监听TCP端口时设置的积压请求栈大小。如果MySql的连接数达到max_connections时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即back_log，如果等待连接的数量超过back_log，将不被授予连接资源，将会报错。5.6.6 版本之前默认值为 50 ， 之后的版本默认为 50 + （max_connections / 5）， 对于Linux系统推荐设置为小于512的整数，但最大不超过900。如果需要数据库在较短的时间内处理大量连接请求， 可以考虑适当增大back_log 的值。 -
thread_cache_size：线程池缓存线程数量的大小，当客户端断开连接后将当前线程缓存起来，当在接到新的连接请求时快速响应无需创建新的线程 。这尤其对那些使用短连接的应用程序来说可以极大的提高创建连接的效率。那么为了提高性能可以增大该参数的值。默认为60，可以设置为120。 -
wait_timeout：指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。 -
interactive_timeout：表示服务器在关闭连接前等待行动的秒数。
12.3、优化数据库结构
3.1、拆分表：冷热数据分离
拆分表的思路是，把1个包含很多字段的表拆分成2个或者多个相对较小的表。这样做的原因是，这些表中某些字段的操作频率很高（热数据），经常要进行查询或者更新操作，而另外一些字段的使用频率却很低（冷数据），冷热数据分离，可以减小表的宽度。如果放在一个表里面，每次查询都要读取大记录，会消耗较多的资源。
MysQL限制每个表最多存储4096列，并且每一行数据的大小不能超过65535字节。表越宽，把表装载进内存缓冲池时所占用的内存也就越大，也会消耗更多的IO。冷热数据分离的目的是:①减少磁盘lO，保证热数据的内存缓存命中率。②更有效的利用缓存，避免读入无用的冷数据。
3.2、增加中间表
把需要经常联合查询的数据插入中间表中，然后将原来的联合查询改为对中间表的查询，以此来提高查询效率。
3.3、增加冗余字段
3.4、优化数据类型
优先选择符合存储需要的最小的数据类型。
情况1：对整数类型数据进行优化。
遇到整数类型的字段可以用INT 型。这样做的理由是，INT 型数据有足够大的取值范围，不用担心数据超出取值范围的问题。刚开始做项目的时候，首先要保证系统的稳定性，这样设计字段类型是可以的。但在数据量很大的时候，数据类型的定义，在很大程度上会影响到系统整体的执行效率。
对于非负型的数据（如自增ID、整型IP）来说，要优先使用无符号整型UNSIGNED来存储。因为无符号相对于有符号，同样的字节数，存储的数值范围更大。如tinyint有符号为-128-127，无符号为0-255，多出一倍的存储空间。
情况2：既可以使用文本类型也可以使用整数类型的字段，要选择使用整数类型 。
跟文本类型数据相比，大整数往往占用更少的存储空间，因此，在存取和比对的时候，可以占用更少的内存空间。所以，在二者皆可用的情况下，尽量使用整数类型，这样可以提高查询的效率。如：将IP地址转换成整型数据。
情况3：避免使用TEXT、BLOB数据类型
情况4：避免使用ENUM类型
情况5：使用TIMESTAMP存储时间
情况6：用DECIMAL代替FLOAT和DOUBLE存储精确浮点数
总之，遇到数据量大的项目时，一定要在充分了解业务需求的前提下，合理优化数据类型，这样才能充分发挥资源的效率，使系统达到最优 。
3.5、优化插入记录的速度
-
MyISAM引擎的表：
① 禁用索引
② 禁用唯一性检查
③ 使用批量插入
④ 使用LOAD DATA INFILE 批量导入
-
InnoDB引擎的表：
① 禁用唯一性检查
② 禁用外键检查
③ 禁止自动提交
3.6、使用非空约束
在设计字段的时候，如果业务允许，建议尽量使用非空约束
3.7、分析表、检查表与优化表
MySQL提供了分析表、检查表和优化表的语句。分析表主要是分析关键字的分布，检查表主要是检查表是否存在错误，优化表主要是消除删除或者更新造成的空间浪费。
- 分析表
ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name]…
默认的，MySQL服务会将 ANALYZE TABLE语句写到binlog中，以便在主从架构中，从服务能够同步数据。可以添加参数LOCAL 或者 NO_WRITE_TO_BINLOG取消将语句写到binlog中。
使用ANALYZE TABLE分析表的过程中，数据库系统会自动对表加一个只读锁。在分析期间，只能读取表中的记录，不能更新和插入记录。ANALYZE TABLE语句能够分析InnoDB和MyISAM类型的表，但是不能作用于视图。
ANALYZE TABLE分析后的统计结果会反应到cardinality的值，该值统计了表中某一键所在的列不重复的值的个数。 该值越接近表中的总行数，则在表连接查询或者索引查询时，就越优先被优化器选择使用。
- 检查表
CHECK TABLE tbl_name [, tbl_name] ... [option] ... option = {QUICK | FAST | MEDIUM | EXTENDED | CHANGED}
MySQL中可以使用CHECK TABLE语句来检查表。CHECK TABLE语句能够检查InnoDB和MyISAM类型的表是否存在错误。CHECK TABLE语句在执行过程中也会给表加上只读锁。
- 优化表
OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...
MySQL中使用OPTIMIZE TABLE语句来优化表。但是，OPTILMIZE TABLE语句只能优化表中的VARCHAR、BLOB或TEXT类型的字段。一个表使用了这些字段的数据类型，若已经删除了表的一大部分数据，或者已经对含有可变长度行的表（含有VARCHAR、BLOB或TEXT列的表）进行了很多更新，则应使用OPTIMIZE TABLE来重新利用未使用的空间，并整理数据文件的碎片。
OPTIMIZE TABLE 语句对InnoDB和MyISAM类型的表都有效。该语句在执行过程中也会给表加上只读锁。
12.4、大表优化
限定查询的范围
禁止不带任何限制数据范围条件的查询语句。
读写分离
经典的数据库拆分方案，主库负责写，从库负责读。
- 一主一从
- 双主双从
垂直拆分
如果数据库中的数据表过多，可以采用 垂直分库 的方式，将关联的数据表部署在同一个数据库上。
如果数据表中的列过多，可以采用 垂直分表 的方式，将一张数据表分拆成多张数据表，把经常一起使用的列放到同一张表里。
水平拆分
尽量控制单表数据宜的大小，建议控制在1000万以内。1000万并不是MsQL数据库的限制，过大会造成修改表结构、备份、恢复都会有很大的问题。此时可以用历史数据归档（应用天日志数据)，水平分表（应用于业务数据）等手段来控制数据量大小。
这里我们主要考虑业务数据的水平分表策略。将大的数据表按照某个属性维度分拆成不同的小表，每张小表保持相同的表结构。比如你可以按照年份来划分，把不向年份的数据放到不同的数据表中。
水平分表仅是解决了单一表数据过大的问题，但由于表的数据还是在风一台机器上，其实对于提升MysQL并发能力没有什么意义，所以水平拆分最好分库，从而达到分布式的目的。
水平拆分能够支持非常大的数据量存储，应用端改造也少，但分片事务难以解决，跨节点Join性能较差，逻辑复杂。《Java工程师修炼之道》的作者推荐·尽量不要对数据进行分片，因为拆分会带来逻辑、部署、运维的各种复杂度，一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的。如果实在要分片，尽量选}客户端分片架构，这样可以减少一次和中间件的网络I/O。
12.5、其他调优策略
服务器语句超时处理
创建全局通用表空间
MySQL8.0新特性：隐藏索引对调优的帮助
十三、事务基础知识
13.1、数据库事务概述
13.1.1、基本概念
事务： 一组逻辑操作单元，使数据从一种状态变换到另一种状态。
事务处理的原则： 保证所有事务都作为一个工作单元来执行，即使出现了故障，都不能改变这种执行方式。当在一个事务中执行多个操作时，要么所有的事务都被提交(commit)，那么这些修改就永久地保存下来；要么数据库管理系统将放弃所作的所有修改，整个事务回滚(rollback)到最初状态。
13.1.2、事务的ACID特性
- 原子性（atomicity）：
原子性是指事务是一个不可分割的工作单位，要么全部提交，要么全部失败回滚。
- 一致性（consistency）：
一致性是指事务执行前后，数据从一个合法性状态变换到另外一个合法性状态。这种状态是语义上的而不是语法上的，跟具体的业务有关。
- 隔离型（isolation）：
事务的隔离性是指一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
- 持久性（durability）：
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来的其他操作和数据库故障不应该对其有任何影响。
持久性是通过事务日志来保证的。日志包括了重做日志和回滚日志。当我们通过事务对数据进行修改的时候，首先会将数据库的变化信息记录到重做日志中，然后再对数据库中对应的行进行修改。这样做的好处是，即使数据库系统崩溃，数据库重启后也能找到没有更新到数据库系统中的重做日志，重新执行，从而使事务具有持久性。
13.1.3、事务的状态
- 活动的（active）
事务对应的数据库操作正在执行过程中时，我们就说该事务处在活动的状态。
- 部分提交的（partially committed）
当事务中的最后一个操作执行完成，但由于操作都在内存中执行，所造成的影响并没有刷新到磁盘时，我们就说该事务处在部分提交的状态。
- 失败的（failed）
当事务处在活动的或者部分提交的状态时，可能遇到了某些错误（数据库自身的错误、操作系统错误或者直接断电等）而无法继续执行，或者人为的停止当前事务的执行，我们就说该事务处在失败的状态。
- 中止的（aborted）
如果事务执行了一部分而变为失败的状态，那么就需要把已经修改的事务中的操作还原到事务执行前的状态。换句话说，就是要撤销失败事务对当前数据库造成的影响。我们把这个撤销的过程称之为回滚。当回滚操作执行完毕时，也就是数据库恢复到了执行事务之前的状态，我们就说该事务处在了中止的状态。
- 提交的（committed）
当一个处在部分提交的状态的事务将修改过的数据都同步到磁盘上之后，我们就可以说该事务处在了提交的状态。
13.2、如何使用事务
13.2.1、显式事务
步骤1： START TRANSACTION或者BEGIN，作用是显式开启一个事务。
sql> BEGIN;
#或者
sql> START TRANSACTION;
START TRANSACTION语句相较于BEGIN特别之处在于，后边能跟随几个修饰符：
①READ ONLY：标识当前事务是一个只读事务，也就是属于该事务的数据库操作只能读取数据，而不能修改数据。
②READ WRITE：标识当前事务是一个读写事务，也就是属于该事务的数据库操作既可以读取数据，也可以修改数据。
③WITH CONSISTENT SNAPSHOT：启动一致性读。
步骤2：一系列事务中的操作（主要是DML，不含DDL）
步骤3：提交事务 或 中止事务（即回滚事务）
# 提交事务。当提交事务后，对数据库的修改是永久性的。
mysql> COMMIT;
# 回滚事务。即撤销正在进行的所有没有提交的修改
mysql> ROLLBACK;
# 将事务回滚到某个保存点。
mysql> ROLLBACK TO [SAVEPOINT]
其中关于SAVEPOINT相关操作有：
# 在事务中创建保存点，方便后续针对保存点进行回滚。一个事物中可以存在多个保存点。
SAVEPOINT 保存点名称;
# 删除某个保存点
RELEASE SAVEPOINT 保存点名称;
13.2.2、隐式事务
- 显式的的使用
START TRANSACTION或者BEGIN语句开启一个事务。这样在本次事务提交或者回滚前会暂时关闭掉自动提交的功能。 - 把系统变量
autocommit的值设置为OFF
13.2.3、隐式提交数据的情况
-
数据定义语言（Data definition language，缩写为：DDL）
-
隐式使用或修改mysql数据库中的表
-
事务控制或关于锁定的语句
- 当我们在一个事务还没提交或者回滚时就又使用
START TRANSACTION或者BEGIN语句开启了另一个事务时，会隐式的提交上一个事务。 - 当前的
autocommit系统变量的值为OFF，我们手动把它调为ON时，也会隐式的提交前边语句所属的事务。 - 使用
LOCK TABLES、UNLOCK TABLES等关于锁定的语句也会隐式的提交前边语句所属的事务。
- 当我们在一个事务还没提交或者回滚时就又使用
13.3、事务隔离级别
13.3.1、数据并发问题
- 脏写（
Dirty Write）
对于两个事务 Session A、Session B，如果事务Session A修改了另一个未提交事务Session B修改过的数据，那就意味着发生了脏写
- 脏读（
Dirty Read）
对于两个事务 Session A、Session B，Session A读取了已经被 Session B更新但还没有被提交的字段。之后若 Session B回滚，Session A读取的内容就是临时且无效的。
- 不可重复读（
Non-Repeatable Read）
对于两个事务Session A、Session B，Session A读取了一个字段，然后 Session B更新了该字段。 之后Session A再次读取同一个字段，值就不同了。那就意味着发生了不可重复读。
- 幻读（
Phantom）
对于两个事务Session A、Session B, Session A 从一个表中读取了一个字段, 然后 Session B 在该表中插入了一些新的行。 之后, 如果 Session A再次读取同一个表, 就会多出几行。那就意味着发生了幻读。
注意1：
有的同学会有疑问，那如果Session B中剔除了一些符合studentno > 0的记录而不是插入新记录，那么Session A之后再根据studentno > 0的条件读取的记录变少了，这种现象算不算幻读呢？这种现象不属于幻读，幻读强调的是一个事物按照某个相同条件多次读取记录时，后读取时读到了之前没有读到的记录。
注意2：
那对于先前已经读到的记录，之后又读取不到这种情况，算啥呢？这相当于对每一条记录都发生了不可重复读的现象。幻读只是重点强调了读取到之前读取没有获取到的记录。
13.3.2、SQL中的四种隔离级别
# 严重情况
脏写 > 脏读 > 不可重复读 > 幻读
SQL标准中设立了4个隔离级别：
-
READ UNCOMMITTED：读未提交，在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。不能避免脏读、不可重复读、幻读。 -
READ COMMITTED：读已提交，它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。可以避免脏读，但不可重复读、幻读问题仍然存在。 -
REPEATABLE READ：可重复读，事务A在读到一条数据之后，此时事务B对该数据进行了修改并提交，那么事务A再读该数据，读到的还是原来的内容。可以避免脏读、不可重复读，但幻读问题仍然存在。这是MySQL的默认隔离级别。 -
SERIALIZABLE：可串行化，确保事务可以从一个表中读取相同的行。在这个事务持续期间，禁止其他事务对该表执行插入、更新和删除操作。所有的并发问题都可以避免，但性能十分低下。能避免脏读、不可重复读和幻读。
不同的隔离级别有不同的现象，并有不同的锁和并发机制，隔离级别越高，数据库的并发性能就越差
13.3.3、MySQL的隔离级别
MySQL默认的隔离级别 REPEATABLE READ
# 查看隔离级别，MySQL5.7.20 之前
SHOW VARIABLES LIKE 'tx_isolation';
# 查看隔离级别，MySQL5.7.20版本及之后
SHOW VARIABLES LIKE 'transaction_isolation';
#不同MySQL版本中都可以使用的
SELECT @@transcation_isolation;
13.3.4、如何设置事务的隔离级别
SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL 隔离级别;
#其中，隔离级别格式：
> READ UNCOMMITTED
> READ COMMITTED
> REPEATABLE READ
> SERIALIZABLE
或者：
SET [GLOBAL|SESSION] TRANSACTION_ISOLATION = '隔离级别'
#其中，隔离级别格式：
> READ-UNCOMMITTED
> READ-COMMITTED
> REPEATABLE-READ
> SERIALIZABLE
十四、MySQL事务日志
事务有4种特性：原子性、一致性、隔离性和持久性。那么事务的四种特性到底是基于什么机制实现呢？
- 事务的隔离性由
锁机制实现。 - 而事务的原子性、一致性和持久性由事务的 redo 日志和undo 日志来保证。
- REDO LOG 称为
重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。 - UNDO LOG 称为
回滚日志，回滚行记录到某个特定版本，用来保证事务的原子性、一致性。
- REDO LOG 称为
有的DBA或许会认为UNDo是REDo的逆过程，其实不然。REDo和UNDO都可以视为是一种恢复操作，但是:
- redo log：是存储引擎层(innodb)生成的日志，记录的是"物理级别"上的页修改操作，比如页号xxx、偏移量y写入了’zzz’数据。主要为了保证数据的可靠性;
- undo log：是存储引擎层(innodb)生成的日志，记录的是逻辑操作日志，比如对某一行数据进行了INSERT语句操作，那么undo log就记录一条与之相反的DELETE操步。主要用于事务的回滚(undo log记录的是每个修改操作的逆操作)和一致性非锁定读(undo log回滚行记泵到某种特定的版本—MVCC，即多版本并发控制)。
14.1、redo日志
14.1.1、为什么需要REDO日志
一方面，缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟，checkpoint机制可以保证数据的最终落盘，然而由于checkpoint并不是每次变更的时候就触发的，而是master线程隔一段时间去处理的。所以最坏的情况就是事务提交后，刚写完缓冲池，数据库宕机了，那么这段数据就是丢失的，无法恢复。
另一方面，事务包含持久性的特性，就是说对于一个已经提交的事务，在事务提交后即使系统发生了崩溃，这个事务对数据库中所做的更改也不能丢失。
那么如何保证这个持久性呢？一个简单的做法：在事务提交完成之前把该事务所修改的所有页面都刷新到磁盘，但是这个简单粗暴的做法有些问题：
- 修改量与刷新磁盘工作量严重不成比例
- 随机IO刷新较慢
另一个解决的思路：我们只是想让已经提交了的事务对数据库中数据所做的修改永久生效，即使后来系统崩溃，在重启后也能把这种修改恢复出来。所以我们其实没有必要在每次事务提交时就把该事务在内存中修改过的全部页面刷新到磁盘，只需要把修改了哪些东西记录一下就好。比如，某个事务将系统表空间中第10号页面中偏移量为100处的那个字节的值1改成2。我们只需要记录一下：将第0号表空间的10号页面的偏移量为100处的值更新为 2 。
InnoDB引擎的事务采用了WAL技术( Write-Ahead Logging )，这种技术的思想就是先写日志，再写磁盘，只有日志写入成功，才算事务提交成功，这里的日志就是redo log。当发生宕机且数据未刷到孤盘的时候，可以通过redo log来恢复，保证ACID中的D，这就是redo log的作用。
14.1.2、REDO日志的好处、特点
- 好处
-
redo日志降低了刷盘频率
-
redo日志占用的空间非常小
- 特点
-
redo日志是顺序写入磁盘的
-
事务执行过程中，redo log不断记录
14.1.3、redo的组成
Redo log可以简单分为以下两个部分：
-
重做日志的缓冲 (redo log buffer)，保存在内存中，是易失的。
参数设置：innodb_log_buffer_size：
redo log buffer 大小，默认16M，最大值是4096M，最小值为1M。
-
重做日志文件 (redo log file)，保存在硬盘中，是持久的。
14.1.4、redo的整体流程
以一个更新事务为例，rego log流转过程：
第1步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝
第2步：生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值
第3步：当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log file采用追加写的方式
第4步：定期将内存中修改的数据刷新到磁盘中
Write-Ahead Log(预先日志持久化)：在持久化一个数据页之前，先将内存中相应的日志页持久化。
14.1.5、redo log的刷盘策略
redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘中去，只是刷入到文件系统缓存（page cache）中去（这是现代操作系统为了提高文件写入效率做的一个优化），真正的写入会交给系统自己来决定（比如page cache足够大了）。那么对于InnoDB来说就存在一个问题，如果交给系统来同步，同样如果系统宕机，那么数据也丢失了（虽然整个系统宕机的概率还是比较小的）。
针对这种情况，InnoDB给出innodb_flush_log_at_trx_commit参数，该参数控制 commit提交事务时，如何将 redo log buffer 中的日志刷新到 redo log file 中。它支持三种策略：
-
设置为0：表示每次事务提交时不进行刷盘操作。（系统默认master thread每隔1s进行一次重做日志的同步） -
设置为1：表示每次事务提交时都将进行同步，刷盘操作（默认值） -
设置为2：表示每次事务提交时都只把 redo log buffer 内容写入 page cache，不进行同步。由os自己决定什么时候同步到磁盘文件。
14.1.6、不同刷盘策略演示
- 流程图
Innodb_flush_log_at_trx_commit=1
小结：Innodb_flush_log_at_trx_commit=1
为1时，只要事务提交成功，redo log记录就一定在硬盘里，不会有任何数据丢失。
如果事务执行期间MySQL挂了或宕机，这部分日志丢了，但是事务并没有提交，所以日志丢了也不会有损失。可以保证ACID的D，数据绝对不会丢失，但是效率最差的。
建议使用默认值，虽然操作系统宕机的概率理论小于数据库宕机的概率，但是一般既然使用了事务，那么数据的安全相对来说更重些。
Innodb_flush_log_at_trx_commit=2
小结 Innodb_flush_log_at_trx_commit=2
为 2 时，只要事务提交成功，redo log buffer 中的内容只写入文件系统缓存（page cache）。
如果仅仅只是MySQL挂了不会有任何数据丢失，但是操作系统宕机可能会有 1 秒数据的丢失，这种情况下无法满足ACID中的D，但是数据 2 肯定是效率最高的。
Innodb_flush_log_at_trx_commit=0
小结：Innodb_flush_log_at_trx_commit=0
为 0 是，master thread中每1秒进行一次重做日志的fsync操作，因此实例crash最多丢失1秒钟内的事务。（master thread是负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性）
数值 0 的话，是一种折中的做法，它的 IO 效率理论是高于 1 的，低于 2 的，这种策略也有丢失数据的风险，也无法保证D。
1.7 写入redo log buffer过程
- 补充概念：Mini-Transaction
一个事务可以包含若干条语句，每一条语句其实是由若干个mtr组成，每一个mtr又可以包含若干条redo日志
- redo日志写入log buffer
不同的事务可能是并发执行的，所以事务T1、事务T2之间的mtr可能是交替执行的。
1.8 redo log file
- 相关参数设置
-
innodb_log_group_home_dir：指定 redo log 文件组所在的路径，默认值为./，表示在数据库的数据目录下。MySQL的默认数据目录（var/lib/mysql）下默认有两个名为ib_logfile0和ib_logfile1的文件，log buffer中的日志默认情况下就是刷新到这两个磁盘文件中。此redo日志文件位置还可以修改。 -
innodb_log_files_in_group：指明redo log file的个数，命名方式如：ib_logfile0，ib_logfile1… ib_logfilen。默认2个，最大100个。 -
innodb_flush_log_at_trx_commit：控制 redo log 刷新到磁盘的策略，默认为1。 -
innodb_log_file_size：单个 redo log 文件设置大小，默认值为 48M 。最大值为512G，注意最大值指的是整个 redo log 系列文件之和，即（innodb_log_files_in_group * innodb_log_file_size ）不能大于最大值512G。- 日志文件组
- checkpoint
如果 write pos 追上 checkpoint ，表示 日志文件组满了，这时候不能再写入新的 redo log记录，MySQL 得停下来，清空一些记录，把 checkpoint 推进一下。
14.1.9、小结
InnoDB的更新操作采用的是Write Ahead Log（预先日志持久化）策略，即先写日志，再写入磁盘。
14.2、Undo日志
redo log是事务持久性的保证，undo log是事务原子性的保证。在事务中更新数据的前置操作其实是要先写入一个 undo log 。
14.2.1、如何理解Undo日志
事务需要保证原子性，也就是事务中的操作要么全部完成，要么什么也不做。但有时候事务执行到一半会出现一些情况，比如：
- 情况一：事务执行过程中可能遇到各种错误，比如
服务器本身的错误，操作系统错误，甚至是突然断电导致的错误。 - 情况二：程序员可以在事务执行过程中手动输入
ROLLBACK语句结束当前事务的执行。
以上情况出现，我们需要把数据改回原先的样子，这个过程称之为回滚，这样就可以造成一个假象：这个事务看起来什么都没做，所以符合原子性要求。
每当我们要对一条记录做改动时(这里的改动可以指INSERT、 DELETE、UPDATE)，都需要"留一手"—―把回滚时所需的东西记下来。比如:
- 你插入一条记录时，至少要把这条记录的主键值记下来，之后回滚的时候只需要把这个主键值对应的记录删掉就好了。(对于每个INSERT,InnoDB存储引擎会完成一个PELETE)
- 你删除了一条记录，至少要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录插入到表中就好了。(对于每个DELETE,InnoDB存储引擎会执行一个INSERT)
- 你修改了一条记录，至少要把修改这条记录前的旧值都记录下来，这样之后回滚时再把这条记录更新为旧值就好了。(对于每个UPDATE，InnoDB存储引擎会执行一个相反的UPDATE，将修改前的行放回去)
MySQL把这些为了回滚而记录的这些内容称之为撤销日志或者回滚日志(即undo log )。注意，由于查询操作( SELECT ）并不会修改任何用户记录，所以在查询操作执行时，并不需要记录相应的undo日志。
此外，undo log 会产生redo log，也就是undo log的产生会伴随着redo log的产生，这是因为undo log也需要持久性的保护。
14.2.2、Undo日志的作用
- 作用1：回滚数据
用户对undo日志可能有误解:undo用于将数据库物理地恢复到执行语句或事务之前的样子。但事实并非如此。undo是逻辑日志，因此只是将数据库逻辑地恢复到原来的样子。所有修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能大不相同。
这是因为在多用户并发系统中，可能会有数十、数百甚至数千个并发事务。数据库的主要任务就是协调对数据记录的并发访问。比如，一个事务在修改当前一个页中某几条记录，同时还有别的事务在对同一个页中另几条记录进行修改。因此，不能将一个页回滚到事务开始的样子，因为这样会影响其他事务正在进行的工作。
- 作用2：MVCC（详情看第16章）
undo的另一个作用是MVCC，即在InnoDB存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。
14.2.3、undo的存储结构
- 回滚段与undo页
InnoDB对undo log的管理采用段的方式，也就是回滚段（rollback segment）。每个回滚段记录了1024个undo log segment，而在每个undo log segment段中进行undo页的申请。
undo页的重用
当我们开启一个事务需要写undo log的时候，就得先去undo log segment中去找到一个空闲的位置，当有空位的时候，就去申请undo页，在这个申请到的undo页中进行undo log的写入。我们知道mysql默认一页的大小是16k。
为每一个事务分配一个页，是非常浪费的（除非你的事务非常长)，假设你的应用的TPS(每秒处理的事务数目）为1000，那么1s就需要1000个页，大概需要16M的存储，1分钟大概需要1G的存储。如果照这样下去除非MySQL清理的非常勤快，否则随着时间的推移，磁盘空间会增长的非常快，而且很多空间都是浪费的。
于是undo页就被设计的可以重用了，当事务提交时，并不会立刻删除undo页。因为重用，所以这个undo页可能混杂着其他事务的undo log。undo log在commit后，会被放到一个链表中，然后判断undo页的使用空间是否小于3/4，如果小于3/4的话，则表示当前的undo页可以被重用，那么它就不会被回收，其他事务的undo log可以记录在当前undo页的后面。由于undo log是离散的，所以清理对应的磁盘空间时，效率不高。
-
回滚段与事务
-
每个事务只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事务。
-
当一个事务开始的时候，会制定一个回滚段，在事务进行的过程中，当数据被修改时，原始的数据会被复制到回滚段。
-
在回滚段中，事务会不断填充盘区，直到事务结束或所有的空间被用完。如果当前的盘区不够用，事务会在段中请求扩展下一个盘区，如果所有已分配的盘区都被用完，事务会覆盖最初的盘区或者在回滚段允许的情况下扩展新的盘区来使用。
-
回滚段存在于undo表空间中，在数据库中可以存在多个undo表空间，但同一时刻只能使用一个undo表空间。
-
当事务提交时，InnoDB存储引擎会做以下两件事情：
-
将undo log放入列表中，以供之后的purge操作
-
判断undo log所在的页是否可以重用，若可以分配给下个事务使用
-
-
-
回滚段中的数据分类
-
未提交的回滚数据(uncommitted undo information) ：该数据所关联的事务并未提交，用于实现读一致性，所以该数据不能被其他事务的数据覆盖。
-
已经提交但未过期的回滚数据(committed undo information) ：该数据关联的事务已经提交，但是仍受到undo retention参数的保持时间的影响。
-
事务已经提交并过期的数据(expired undo information) ：事务已经提交，而且数据保存时间已经超过undo retention参数指定的时间，属于已经过期的数据。当回滚段满了之后，会优先覆盖 事务已经提交并过期的数据。
事务提交后并不能马上删除undo log及undo log所在的页。这是因为可能还有其他事务需要通过undo log来得到记录之前的版本。故事务提交时将undo log放入一个链表中，是否可以最终删除undo log及undo log所在页由purge线程来判断。
-
14.2.4、undo的类型
在InnoDB存储引擎中，undo log分为：
-
insert undo log
insert undo log是指在insert操作中产生的undo log。因为insert操作的记录，只对事务本身可见，对其他事务不可见（这是事务隔离性的要求)，故该undo log可以在事务提交后直接删除。不需要进行purge操作。
-
update undo log
update undo log记录的是对delete和updale操作产生的undo log。该undo log可能需要提供MVcc机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。
14.2.5、undo log的生命周期
1. 简要生成过程
只有Buffer Pool的流程：
有了Redo Log和Undo Log之后：
2. 详细生成过程
当我们执行INSERT时：
begin;
INSERT INTO user (name) VALUES ("tom");
插入的数据都会生成一条insert undo log，并且数据的回滚指针会指向它，undo log 会记录undo log的序号、插入主键的列和值，那么在进行rollback的之后，通过主键直接把对应的数据删除即可
当我们执行UPDATE时：
对于更新的操作会产生update undo log，并且会分更新主键和不更新主键的
UPDATE user SET id=2 WHERE id=1;
3. undo log是如何回滚的
以上面的例子来说，假设执行rollback，那么对应的流程应该是这样：
- 通过undo no=3的日志把id=2的数据删除
- 通过undo no=2的日志把id=1的数据的deletemark还原成0
- 通过undo no=1的日志把id=1的数据的name还原成Tom
- 通过undo no=0的日志把id=1的数据删除
4. undo log的删除
- 针对于insert undo log
因为insert操作的记录，只对事务本身可见，对其他事务不可见。故该undo log可以在事务提交后直接删除，不需要进行purge操作。
- 针对于update undo log
该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。
14.2.6、小结
undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子。
redo log是物理日志，记录的是数据页的物理变化，undo log不是redo log的逆过程。
十五、锁
锁 是计算机协调多个进程或线程并发访问的机制。在程序开发中会存在多线程同步的问题，当多个线程并发访问某个数据的时候，尤其是针对一些敏感的数据（比如订单、金额等），我们就需要这个数据在任何时候 最多只有一个线程 在访问，保证数据的 完整性 和 一致性。在开发过程中加锁是为了保证数据的一致性，这个思想在数据库领域汇总同样很重要。
15.1、概述
在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。为保证数据的一致性，需要对并发操作进行控制，因此产生了锁。同时锁机制也为实现MySQL的各个隔离级别提供了保证。 锁冲突 也是影响数据库并发访问性能的一个重要因素。所以锁对数据库而言显得尤其重要，也更加复杂。
15.2、MySQL并发事务访问相同记录
15.2.1、读-读情况
读-读情况，即并发事务相继读取相同的记录。读取操作本身不会对记录有任何影响，并不会引起什么问题，所以允许这种情况的发生。
15.2.2、写-写情况
写-写情况，即并发事务相继对相同的记录做出改动。
在这种情况下会发生脏写的问题，任何一种隔离级别都不允许这种问题的发生。所以在多个未提交事务相继对一条记录做改动时，需要让它们排队执行，这个排队的过程其实是通过锁来实现的。 这个所谓的锁其实是一个内存中的结构，在事务执行前本来是没有锁的，也就是说一开始是没有 锁结构 和记录进行关联的。
当一个事务想对这条记录做改动时，首先会看看内存中有没有与这条记录关联的 锁结构，当没有的时候就会在内存中生成一个锁结构与之关联。
15.2.3、读-写或写-读情况
读-写或写-读，即一个事务进行读取操作，另一个进行改动操作。这种情况下可能发生脏读、不可重复读、幻读的问题。
15.2.4、并发问题的解决方案
怎么解决脏读、不可重复读、幻读这些问题呢？其实有两种可选的解决方案：
- 方案一：读操作利用多版本并发控制（
MVCC，下章讲解），写操作进行加锁。
所谓的MVCC，就是生成一个ReadView，通过ReadView找到符合条件的记录版本（历史版本由undo日志构建）。查询语句只能读到在生成ReadView之前已提交事务所做的更改，在生成ReadView之前未提交的事务或者之后才开启的事务所做的更改是看不到的。而写操作肯定针对的是最新版本的记录，读记录的历史版本和改动记录的最新版本本身并不冲突，也就是采用MVCC时，读-写操作并不冲突。
普通的SELECT语句在READ COMMITTED和REPEATABLE READ隔离级别下会使用到MVCC读取记录。
- 在
READ COMMITTED隔离级别下，一个事务在执行过程中每次执行SELECT操作时都会生成一个ReadView，ReadView的存在本身就保证了事务不可以读取到未提交的事务所做的更改，也就是避免了脏读现象；- 在
REPEATABLE READ隔离级别下，一个事务在执行过程中只有第一次执行SELECT操作才会生成一个ReadView，之后的SELECT操作都复用这ReadView，这样也就避免了不可重复读和幻读的问题。
- 方案二：读、写操作都采用
加锁的方式。
如果一些业务场景不允许读取记录的旧版本，而是每次都必须去读取记录的最新版本。这样在读取记录的时候就需要对其进行加锁操作，这样也就意味着浃操作和写操作也像写-写操作那样排队执行。
脏读 的产生是因为当前事务读取了另一个未提交事务写的一条记录，如果井一个事务在写论录的时候就给这条记录加锁，那么当前事务就无法继续读取该记录了，所以也就不会有脏读问题的产生了。
不可重复读 的产生是因为当前事务先读取一条记录，另外一个事务对该记录做了改动之后并提交之后,当前事务再次读取时会获得不同的值，如果在当前事务读取记录时就给该记录加锁,那么另一个事务就无法修改该记录，自然也不会发生不可重复读了。
幻读 问题的产生是因为当前事务读取了一个范围的记录，然后另外的事务向该范围内插入了新记录，当前事务再次读取该范围的记录时发现了新插入的新记录。采用加锁的方式解决幻读问题就有一些麻烦，因为当前事务在第一次读取记录时幻影记录并不存在，所以读取的时候加锁就有点尴尬（因为你并不知道给谁加锁)。
- 小结对比发现：
- 采用
MVCC方式的话，读-写操作彼此并不冲突，性能更高。 - 采用
加锁方式的话，读-写操作彼此需要排队执行，影响性能。
- 采用
一般情况下我们当然愿意采用MVCC来解决读-写操作并发执行的问题，但是业务在某些特殊情况下，要求必须采用加锁的方式执行。
15.3、锁的不同角度分类
3.1、从数据操作的类型划分：读锁、写锁
-
读锁：也称为共享锁、英文用S表示。针对同一份数据，多个事务的读操作可以同时进行而不会互相影响，相互不阻塞的。 -
写锁：也称为排他锁、英文用X表示。当前写操作没有完成前，它会阻断其他写锁和读锁。这样就能确保在给定的时间里，只有一个事务能执行写入，并防止其他用户读取正在写入的同一资源。
需要注意的是对于InnoDB引擎来说，读锁和写锁可以加在表上，也可以加在行上。
- 锁定读
在采用加锁方式解决脏读、不可重复读、幻读这些问题时，读取一条记录时需要获取该记录的S锁，其实是不严谨的，有时候需要在读取记录时就获取记录的X锁，来禁止别的事务读写该记录，为此MySQL提出了两种比较特殊的SELECT语句格式：
- 对读取的记录加
S锁：
SELECT ... LOCK IN SHARE MODE;
# 或
SELECT ... FOR SHARE; #(8.0新增语法)
- 对读取的记录加
X锁：
SELECT ... FOR UPDATE;
MySQL8.0新特性：
在5.7及之前的版本，SELECT ... FOR UPDATE，如果获取不到锁，会一直等待，直到innodb_lock_wait_timeout超时。
在8.0版本中，SELECT ... FOR UPDATE, SELECT ... FOR SHARE 添加NOWAIT、SKIP LOCKED语法，跳过锁等待，或者跳过锁定。
- NOWAIT：如果查询的行已经加锁，会立即报错返回
- SKIP LOCKED：如果查询的行已经加锁，只返回结果中不包含被锁定的行
- 写操作
-
DELETE：对一条记录做DELETE操作的过程其实是先在B+树中定位到这条记录的位置，然后获取这条记录的X锁，再执行delete mark操作。 -
UPDATE：在对一条记录做UPDATE操作时分为三种情况：- 情况1：未修改该记录的键值，并且被更新的列占用的存储空间在修改前后未发生变化。则先在
B+树中定位到这条记录的位置，然后再获取一下记录的X锁，最后在原纪录的位置进行修改操作。 - 情况2：未修改该记录的键值，并且至少有一个被更新的列占用的存储空间在修改前后发生变化。则先在
B+树中定位到这条记录的位置，然后获取一下记录的X锁，将该记录彻底删除掉（就是把记录彻底移入垃圾链表），最后再插入一条新记录。新插入的记录由INSERT操作提供的隐式锁进行保护。 - 情况3：修改该记录的键值，则相当于在原纪录上做
DELECT操作之后再来一次INSERT操作。
- 情况1：未修改该记录的键值，并且被更新的列占用的存储空间在修改前后未发生变化。则先在
-
INSERT：一般情况下，新插入一条记录的操作并不加锁，通过一种称之为隐式锁的结构来保护这条新插入的记录在本事务提交前不被别的事务访问。
3.2、从数据操作的粒度划分：表级锁、页级锁、行锁
- 表锁（Table Lock）
该锁会锁定整张表，它是MySQL中最基本的锁策略，并不依赖于存储引擎，并且表锁是开销最少的策略。由于表级锁一次会将整个表锁定，所以可以很好的避免死锁的问题。当然，锁的粒度大所带来最大的负面影响就是出现锁资源争用的概率也会最高，导致并发率大打折扣。
① 表级别的S锁、X锁
在对某个表执行SELECT、INSERT、DELETE、UPDATE语句时，InnoDB存储引擎是不会为这个表添加表级别的S锁或者X锁的。在对某个表执行一些诸如ALTER TABLE、DROP TABLE这类的DDL语句时，其他事务对这个表并发执行诸如SELECT、INSERT、DELETE、UPDATE的语句会发生阻塞。同理，某个事务中对某个表执行SELECT、INSERT、DELETE、UPDATE语句时，在其他会话中对这个表执行DDL语句也会发生阻塞。这个过程其实是通过在server层使用一种称之为元数据锁（英文名：Metadata Locks，简称MDL）结构来实现的。
一般情况下，不会使用InnoDB存储引擎提供的表级别的S锁和X锁。只会在一些特殊情况下，比方说崩溃恢复过程中用到。比如，在系统变量autocommit=0，innodb_table_locks = 1时，手动获取InnoDB存储引擎提供的表t 的S锁或者X锁可以这么写：
-
LOCK TABLES t READ：InnoDB存储引擎会对表t加表级别的S锁。 -
LOCK TABLES t WRITE：InnoDB存储引擎会对表t加表级别的X锁。
总结：MyISAM在执行查询语句（SELECT）前，会给涉及的所有表加读锁，在执行增删改操作前，会给涉及的表加写锁。InnoDB存储引擎是不会为这个表添加表级别的读锁或者写锁的。
② 意向锁 （intention lock）
InnoDB 支持多粒度锁（multiple granularity locking），它允许行级锁与表级锁共存，而 意向锁 就是其中的一种表锁。
1、意向锁的存在是为了协调行锁和表锁的关系，支持多粒度（表锁与行锁）的锁并存。
2、意向锁是一种不与行级锁冲突的表级锁，这一点非常重要。
3、表明“某个事务正在某些行持有了锁或该事务准备去持有锁”
意向锁分为两种：
- 意向共享锁 （intention shared lock, IS）：事务有意向对表中的某些行加 共享锁（S锁）
-- 事务要获取某些行的 S 锁，必须先获得表的 IS 锁。
SELECT column FROM table ... LOCK IN SHARE MODE;
- 意向排他锁 （intention exclusive lock, IX）：事务有意向对表中的某些行加 排他锁（X锁）
-- 事务要获取某些行的 X 锁，必须先获得表的 IX 锁。
SELECT column FROM table ... FOR UPDATE;
即：意向锁是由存储引擎自己维护的，用户无法手动操作意向锁，在为数据行加共享 / 排他锁之前，InooDB 会先获取该数据行所在数据表的对应意向锁。
- 意向锁要解决的问题
现在有两个事务，分别是T1和T2，其中T2试图在该表级别上应用共享或排它锁，如果没有意向锁存在，那么T2就需要去检查各个页或行是否存在锁；如果存在意向锁，那么此时就会受到由T1控制的表级别意向锁的阻塞。T2在锁定该表前不必检查各个页或行锁，而只需检查表上的意向锁。简单来说就是给更大一级级别的空间示意里面是否已经上过锁。
在数据表的场景中，如果我们给某一行数据加上了排它锁，数据库会自动给更大一级的空间，比如数据页或数据表加上意向锁，告诉其他人这个数据页或数据表已经有人上过排它锁了，这样当其他人想要获取数据表排它锁的时候，只需要了解是否有人已经获取了这个数据表的意向排它锁即可。
- 如果事务想要获取数据表中某些记录的共享锁，就需要在数据表上
添加意向共享锁 - 如果事务想要获取数据表中某些记录的排它锁，就需要在数据表上
添加意向排他锁
这时，意向锁会告诉其他事务已经有人锁定了表中的某些记录。
③ 自增锁（AUTO-INC锁 ）
- “Simple inserts” （简单插入）
可以预先确定要插入的行数（当语句被初始处理时）的语句。包括没有嵌套子查询的单行和多行INSERT...VALUES()和REPLACE语句。
- “Bulk inserts” （批量插入）
事先不知道要插入的行数（和所需自动递增值的数量）的语句。比如INSERT ... SELECT，REPLACE ... SELECT和LOAD DATA语句，但不包括纯INSERT。 InnoDB在每处理一行，为AUTO_INCREMENT列分配一个新值。
- “Mixed-mode inserts” （混合模式插入）
这些是“Simple inserts”语句但是指定部分新行的自动递增值。例如INSERT INTO teacher (id,name) VALUES (1,'a'), (NULL,'b'), (5,'c'), (NULL,'d');只是指定了部分id的值。另一种类型的“混合模式插入”是INSERT ... ON DUPLICATE KEY UPDATE。
对于上面数据插入的案例，MySQL采用了自增锁的方式来实现，AUTO-INT锁是当向使用含有AUTO_INCREMENT列的表中插入数据时需要获取的一种特殊的表级锁 ，在执行插入语句时就在表级别加一个AUTO-INT锁，然后为每条待插入记录的AUTO_INCREMENT修饰的列分配递增的值，在该语句执行结束后，再把AUTO-INT锁释放掉。 一个事务在持有AUTO-INC锁的过程中，其他事务的插入语句都要被阻塞 ，可以保证一个语句中分配的递增值是连续的。也正因为此，其并发性显然并不高， 当我们向一个有AUTO_INCREMENT关键字的主键插入值的时候，每条语句都要对这个表锁进行竞争 ，这样的并发潜力其实是很低下的，所以innodb通过innodb_autoinc_lock_mode的不同取值来提供不同的锁定机制，来显著提高SQL语句的可伸缩性和性能。
innodb_autoinc_lock_mode有三种取值，分别对应与不同锁定模式：
（1）innodb_autoinc_lock_mode = 0(“传统”锁定模式)
在此锁定模式下，所有类型的insert语句都会获得一个特殊的表级AUTO-INC锁，用于插入具有AUTO_INCREMENT列的表。这种模式其实就如我们上面的例子，即每当执行insert的时候，都会得到一个表级锁(AUTO-INC锁)，使得语句中生成的auto_increment为顺序，且在binlog中重放的时候，可以保证master与slave中数据的auto_increment是相同的。因为是表级锁，当在同一时间多个事务中执行insert的时候，对于AUTO-INC锁的争夺会限制并发能力。
（2）innodb_autoinc_lock_mode = 1(“连续”锁定模式)
在 MySQL 8.0 之前，连续锁定模式是默认的。
在这个模式下，“bulk inserts”仍然使用AUTO-INC表级锁，并保持到语句结束。这适用于所有INSERT … SELECT，REPLACE … SELECT和LOAD DATA语句。同一时刻只有一个语句可以持有AUTO-INC锁。
对于“Simple inserts”（要插入的行数事先已知），则通过在mutex（轻量锁）的控制下获得所需数量的自动递增值来避免表级AUTO-INC锁， 它只在分配过程的持续时间内保持，而不是直到语句完成。不使用表级AUTO-INC锁，除非AUTO-INC锁由另一个事务保持。如果另一个事务保持AUTO-INC锁，则“Simple inserts”等待AUTO-INC锁，如同它是一个“bulk inserts”。
（3）innodb_autoinc_lock_mode = 2(“交错”锁定模式)
从 MySQL 8.0 开始，交错锁模式是默认设置。
在这种锁定模式下，所有类INSERT语句都不会使用表级AUTO-INC锁，并且可以同时执行多个语句。这是最快和最可拓展的锁定模式，但是当使用基于语句的复制或恢复方案时， 从二进制日志重播SQL语句时，这是不安全的。
在此锁定模式下，自动递增值保证在所有并发执行的所有类型的insert语句中是唯一且单调递增的。但是，由于多个语句可以同时生成数字（即，跨语句交叉编号）， 为任何给定语句插入的行生成的值可能不是连续的。
④ 元数据锁（MDL锁）
MySQL5.5引入了meta data lock，简称MDL锁，属于表锁范畴。MDL 的作用是，保证读写的正确性。比如，如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做变更，增加了一列，那么查询线程拿到的结果跟表结构对不上，肯定是不行的。
因此， 当对一个表做增删改查操作的时候，加MDL读锁；当要对表做结构变更操作的时候，加MDL写锁。
- InnoDB中的行锁
行锁（Row Lock）也称为记录锁，顾名思义，就是锁住某一行（某条记录row）。需要注意的是，MySQL服务器层并没有实现行锁机制， 行级锁只在存储引擎层实现。
-
优点： 锁定力度小，发生
锁冲突概率低，可以实现的并发度高 -
缺点： 对于
锁的开销比较大，加锁会比较慢，容易出现死锁情况
InnoDB与MyISAM的最大不同有两点：一是支持事务；二是采用了行级锁。
① 记录锁（Record Locks）
记录锁也就是仅仅把一条记录锁上，官方的类型名称为：LOCK_REC_NOT_GAP。
记录锁是有S锁和X锁之分的，称之为S型记录锁和X型记录锁。
- 当一个事务获取了一条记录的S型记录锁后，其他事务也可以继续获取该记录的S型记录锁，但不可以继续获取X型记录锁；
- 当一个事务获取了一条记录的X型记录锁后，其他事务既不可以继续获取该记录的S型记录锁，也不可以继续获取X型记录锁。
② 间隙锁（Gap Locks）
MySQL在REPEATABLE READ隔离级别下是可以解决幻读问题的，解决方案有两种，可以使用MVCC方案解决，也可以采用加锁方案解决。但是在使用加锁方案解决时有个大问题，就是事务在第一次执行读取操作时，那些幻影记录尚不存在，我们无法给这些幻影记录加上记录锁。InnoDB提出了一种称之为Gap Locks的锁，官方的类型名称为：LOCK_GAP，我们可以简称为gap锁。
gap锁的提出仅仅是为了防止插入幻影记录而提出的 。虽然有共享gap锁和独占gap锁这样的说法，但是它们起到的作用是相同的。而且如果对一条记录加了gap锁（不论是共享gap锁还是独占gap锁），并不会限制其他事务对这条记录加记录锁或者继续加gap锁。
③ 临键锁（Next-Key Locks）
有时候我们既想锁住某条记录，又想阻止其他事务在该记录前边的间隙插入新记录，所以InnoDB就提出了一种称之为Next-Key Locks的锁，官方的类型名称为：LOCK_ORDINARY，我们也可以简称为next-key锁。Next-Key Locks是在存储引擎innodb、事务级别在可重复读的情况下使用的数据库锁，innodb默认的锁就是Next-Key locks。
begin;
select * from student where id <=8 and id > 3 for update;
④ 插入意向锁（Insert Intention Locks）
我们说一个事务在插入一条记录时需要判断一下插入位置是不是被别的事务加了gap锁（next-key锁也包含gap锁），如果有的话，插入操作需要等待，直到拥有gap锁的那个事务提交。但是InnoDB规定事务在等待的时候也需要在内存中生成一个锁结构 ，表明有事务想在某个间隙中插入新记录，但是现在在等待。InnoDB就把这种类型的锁命名为Insert Intention Locks，官方的类型名称为：LOCK_INSERT_INTENTION，我们称为插入意向锁。插入意向锁是一种Gap锁，不是意向锁，在insert操作时产生。
插入意向锁是在插入一条记录行前，由INSERT 操作产生的一种间隙锁。
事实上 插入意向锁并不会阻止别的事务继续获取该记录上任何类型的锁。
- 页锁
页锁就是在页的粒度上进行锁定，锁定的数据资源比行锁要多，因为一个页中可以有多个行记录。当我们使用页锁的时候，会出现数据浪费的现象，但这样的浪费最多也就是一个页上的数据行。 页锁的开销介于表锁和行锁之间，会出现死锁。锁定粒度介于表锁和行锁之间，并发度一般。
每个层级的锁数量是有限制的，因为锁会占用内存空间，锁空间的大小是有限的。当某个层级的锁数量超过了这个层级的阈值时，就会进行锁升级。锁升级就是用更大粒度的锁替代多个更小粒度的锁，比如InnoDB 中行锁升级为表锁，这样做的好处是占用的锁空间降低了，但同时数据的并发度也下降了。
3.3、从对待锁的态度划分:乐观锁、悲观锁
从对待锁的态度来看锁的话，可以将锁分成乐观锁和悲观锁，从名字中也可以看出这两种锁是两种看待数据并发的思维方式。需要注意的是，乐观锁和悲观锁并不是锁，而是锁的设计思想。
- 悲观锁（Pessimistic Locking）
悲观锁是一种思想，顾名思义，就是很悲观，对数据被其他事务的修改保持保守态度，会通过数据库自身的锁机制来实现，从而保证数据操作的排他性。
悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（ 共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程 ）。比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
注意：**select … for update 语句执行过程中所有扫描的行都会被锁上，因此在MySQL中用悲观锁必须确定使用了索引，而不是全表扫描，否则将会把整个表锁住。 **
- 乐观锁（Optimistic Locking）
乐观锁认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，也就是不采用数据库自身的锁机制，而是通过程序来实现 。在程序上，我们可以采用版本号机制或者CAS机制实现。 乐观锁适用于多读的应用类型，这样可以提高吞吐量 。在Java中包下的原子变量类就是使用了乐观锁的一种实现方式：CAS实现的。
- 乐观锁的版本号机制
在表中设计一个版本字段 version，第一次读的时候，会获取 version 字段的取值。然后对数据进行更新或删除操作时，会执行UPDATE ... SET version=version+1 WHERE version=version。此时如果已经有事务对这条数据进行了更改，修改就不会成功。
- 乐观锁的时间戳机制
时间戳和版本号机制一样，也是在更新提交的时候，将当前数据的时间戳和更新之前取得的时间戳进行比较，如果两者一致则更新成功，否则就是版本冲突。
你能看到乐观锁就是程序员自己控制数据并发操作的权限，基本是通过给数据行增加一个戳（版本号或者时间戳），从而证明当前拿到的数据是否最新。
- 两种锁的适用场景
从这两种锁的设计思想中，我们总结一下乐观锁和悲观锁的适用场景：
-
乐观锁适合读操作多的场景，相对来说写的操作比较少。它的优点在于程序实现，不存在死锁问题，不过适用场景也会相对乐观，因为它阻止不了除了程序以外的数据库操作。 -
悲观锁适合写操作多的场景，因为写的操作具有排它性。采用悲观锁的方式，可以在数据库层面阻止其他事务对该数据的操作权限，防止读 - 写和写 - 写的冲突。
3.4、按加锁的方式划分：显式锁、隐式锁
- 隐式锁
-
情景一： 对于聚簇索引记录来说，有一个
trx_id隐藏列，该隐藏列记录着最后改动该记录的事务id。那么如果在当前事务中新插入一条聚簇索引记录后，该记录的trx_id隐藏列代表的的就是当前事务的事务id，如果其他事务此时想对该记录添加S锁或者X锁时，首先会看一下该记录的trx_id隐藏列代表的事务是否是当前的活跃事务，如果是的话，那么就帮助当前事务创建一个X锁（也就是为当前事务创建一个锁结构，is_waiting属性是false），然后自己进入等待状态（也就是为自己也创建一个锁结构，is_waiting属性是true）。 -
情景二： 对于二级索引记录来说，本身并没有
trx_id隐藏列，但是在二级索引页面的Page Header部分有一个PAGE_MAX_TRX_ID属性，该属性代表对该页面做改动的最大的事务id，如果PAGE_MAX_TRX_ID属性值小于当前最小的活跃事务id，那么说明对该页面做修改的事务都已经提交了，否则就需要在页面中定位到对应的二级索引记录，然后回表找到它对应的聚簇索引记录，然后再重复情景一的做法。
即：一个事务对新插入的记录可以不显示的加锁（生成一个锁结构），但是由于事务id的存在，相当于加了一个隐式锁。别的事务在对这条记录加S锁或者X锁时，由于隐式锁的存在，会先帮助当前事务生成一个锁结构，然后自己再生成一个锁结构后进入等待状态。隐式锁是一种延迟加锁的机制，从而来减少加锁的数量。
- 显式锁
通过特定的语句进行加锁，我们一般称之为显示加锁。
3.5、其它锁之：全局锁
全局锁就是对整个数据库实例加锁。当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。全局锁的典型使用场景是：做全库逻辑备份。
全局锁的命令：
Flush tables with read lock
3.6、其它锁之：死锁
两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁。
死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环。
产生死锁的必要条件
- 两个或者两个以上事务
- 每个事务都已经持有锁并且申请新的锁
- 锁资源同时只能被同一个事务持有或者不兼容
- 事务之间因为持有锁和申请锁导致彼此循环等待
如何处理死锁？
方式1： 等待，直到超时（innodb_lock_wait_timeout=50s）
即当两个事务互相等待时，当一个事务等待时间超过设置的阈值时，就将其回滚，另外事务继续进行。
方式2： 使用死锁检测进行死锁处理
发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务（将持有最少行级排他锁的事务进行回滚），让其他事务得以继续执行。
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。
一旦检测到死锁、有死锁，这时候InnoDB存储引擎会选择 回滚undo量最小的事务 ，让其他事务继续执行（innodb_deadlock_detect=on表示开启这个逻辑）
缺点：每个新的被阻塞的线程，都要判断是不是由于自己的加入导致了死锁，这个操作时间复杂度是O(n)。
如何解决？
- 方式1：关闭死锁检测，但意味着可能会出现大量的超时，会导致业务有损。
- 方式2：控制并发访问的数量。比如在中间件中实现对于相同行的更新，在进入引擎之前排队，这样在InnoDB内部就不会有大量的死锁检测工作。
如何避免死锁
- 合理设计索引，使业务SQL尽可能通过索引定位更少的行，减少锁竞争
- 调整业务逻辑SQL执行顺序，避免update/delete长时间持有锁的SQL在事务前面。
- 避免大失误，尽量将大事务拆成多个小事务来处理，小事务缩短锁定资源的时间，发生锁冲突的几率也更小。
- 在并发比较高的系统中，不要显示加锁，特别是是在事务里显示加锁。如select … for update 语句，如果是在事务里运行了start transaction 或设置了 autocommit 等于0，那么就会锁定锁查找到的记录。
- 降低隔离级别。如果业务允许，将隔离级别调低也是较好的选择，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁造成的死锁。
15.4、锁的内存结构
结构解析：
1. 锁所在的事务信息：
不论是表锁还是行锁，都是在事务执行过程中生成的，哪个事务生成了这个 锁结构 ，这里就记录这个事务的信息。
此锁所在的事务信息在内存结构中只是一个指针，通过指针可以找到内存中关于该事务的更多信息，比方说事务id等。
2. 索引信息：
对于行锁来说，需要记录一下加锁的记录是属于哪个索引的。这里也是一个指针。
3. 表锁／行锁信息：
表锁结构和行锁结构在这个位置的内容是不同的：
- 表锁：记载着是对哪个表加的锁，还有其他的一些信息。
- 行锁：记载了三个重要的信息：
- Space ID ：记录所在表空间。
- Page Number ：记录所在页号。
- n_bits ：对于行锁来说，一条记录就对应着一个比特位，一个页面中包含很多记录，用不同的比特位来区分到底是哪一条记录加了锁。为此在行锁结构的末尾放置了一堆比特位，这个n_bits 属性代表使用了多少比特位。
n_bits的值一般都比页面中记录条数多一些。主要是为了之后在页面中插入了新记录后也不至于重新分配锁结构
4. type_mode：
这是一个32位的数，被分成了lock_mode、lock_type和rec_lock_type三个部分，如图所示：
- 锁的模式（
lock_mode），占用低4位，可选的值如下：-
LOCK_IS（十进制的0）：表示共享意向锁，也就是IS锁。 -
LOCK_IX（十进制的1）：表示独占意向锁，也就是IX锁。 -
LOCK_S（十进制的2）：表示共享锁，也就是S锁。 -
LOCK_X（十进制的3）：表示独占锁，也就是X锁。 -
LOCK_AUTO_INC（十进制的4）：表示AUTO-INC锁。
-
在InnoDB存储引擎中，LOCK_IS，LOCK_IX，LOCK_AUTO_INC都算是表级锁的模式，LOCK_S和 LOCK_X既可以算是表级锁的模式，也可以是行级锁的模式。
- 锁的类型（
lock_type），占用第5～8位，不过现阶段只有第5位和第6位被使用：-
LOCK_TABLE（十进制的16），也就是当第5个比特位置为1时，表示表级锁。 -
LOCK_REC（十进制的32），也就是当第6个比特位置为1时，表示行级锁。
-
- 行锁的具体类型（
rec_lock_type），使用其余的位来表示。只有在lock_type的值为LOCK_REC时，也就是只有在该锁为行级锁时，才会被细分为更多的类型：-
LOCK_ORDINARY（十进制的0）：表示next-key锁。 -
LOCK_GAP（十进制的512）：也就是当第10个比特位置为1时，表示gap锁。 -
LOCK_REC_NOT_GAP（十进制的1024）：也就是当第11个比特位置为1时，表示正经记录锁。 -
LOCK_INSERT_INTENTION（十进制的2048）：也就是当第12个比特位置为1时，表示插入意向锁。其他的类型：还有一些不常用的类型我们就不多说了。
-
-
is_waiting属性呢？基于内存空间的节省，所以把 is_waiting 属性放到了 type_mode 这个32位的数字中：-
LOCK_WAIT（十进制的256） ：当第9个比特位置为1时，表示is_waiting为true，也就是当前事务尚未获取到锁，处在等待状态；当这个比特位为0时，表示is_waiting为false，也就是当前事务获取锁成功。
-
5. 其他信息：
为了更好的管理系统运行过程中生成的各种锁结构而设计了各种哈希表和链表。
6. 一堆比特位：
如果是行锁结构的话，在该结构末尾还放置了一堆比特位，比特位的数量是由上边提到的n_bits属性表示的。InnoDB数据页中的每条记录在记录头信息中都包含一个 heap_no 属性，伪记录Infimum的heap_no值为0，Supremum的heap_no值为1，之后每插入一条记录，heap_no值就增1。锁结构最后的一堆比特位就对应着一个页面中的记录，一个比特位映射一个heap_no，即一个比特位映射到页内的一条记录。
15.5、锁监控
mysql> show status like 'innodb_row_lock%';
- Innodb_row_lock_current_waits：当前正在等待锁定的数量；
-
Innodb_row_lock_time：从系统启动到现在锁定总时间长度；（等待总时长） -
Innodb_row_lock_time_avg：每次等待所花平均时间；（等待平均时长） - Innodb_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间；
-
Innodb_row_lock_waits：系统启动后到现在总共等待的次数；（等待总次数）
其他监控方法：
MySQL把事务和锁的信息记录在了information_schema库中，涉及到的三张表分别是INNODB_TRX、INNODB_LOCKS和INNODB_LOCK_WAITS。
MySQL5.7及之前，可以通过information_schema.INNODB_LOCKS查看事务的锁情况，但只能看到阻塞事务的锁；如果事务并未被阻塞，则在该表中看不到该事务的锁情况。
MySQL8.0删除了information_schema.INNODB_LOCKS，添加了performance_schema.data_locks，可以通过performance_schema.data_locks查看事务的锁情况，和MySQL5.7及之前不同，performance_schema.data_locks不但可以看到阻塞该事务的锁，还可以看到该事务所持有的锁。
同时，information_schema.INNODB_LOCK_WAITS也被performance_schema.data_lock_waits所代替。
十六、多版本并发控制
16.1、什么是MVCC
MVCC （Multiversion Concurrency Control），多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的并发控制。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。
MVCC没有正式的标准，在不同的DBMS中MVCC的实现方式可能是不同的。
16.2、快照读与当前读
MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读，而这个读指的就是快照读，而非当前读。当前读实际上是一种加锁的操作，是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。
16.2.1、快照读
快照读又叫一致性读，读取的是快照数据。 不加锁的简单的SELECT都属于快照读，即不加锁的非阻塞读。
之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于MVCC，它在很多情况下，避免了加锁操作，降低了开销。
既然是基于多版本，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。
快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。
16.2.2、当前读
当前读读取的是记录的最新版本（最新数据，而不是历史版本的数据），读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。加锁的 SELECT，或者对数据进行增删改都会进行当前读。
SELECT * FROM student LOCK IN SHARE MODE; #共享锁
SELECT * FROM student FOR UPDATE; # 排他锁
INSERT INTO student values ... #排他锁
DELETE FROM student WHERE ... #排他锁
UPDATE sutdent SET ... #排他锁
16.3、复习
16.3.1、再谈隔离级别
我们知道事务有 4 个隔离级别，可能存在三种并发问题：
在MySQL中，默认的隔离级别是可重复读，可以解决脏读和不可重复读的问题，如果仅从定义的角度来看，它并不能解决欢度问题。如果想要解决幻读问题，就需要采用串行化的方式，也就是将隔离级别提升到最高，但这样一来就会大幅度降低数据库的事务并发能力。
MVCC可以不采用锁机制，而是通过乐观锁的方式来解决不可重复读和幻读问题！它可以在大多数情况下替代行级锁，降低系统的开销。
16.3.2、隐藏字段、Undo Log版本链
回顾一下undo日志的版本链，对于使用InnoDB存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列。
-
trx_id：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务id赋值给trx_id 隐藏列。 -
roll_pointer：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到 undo日志 中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。
16.4、MVCC实现原理之ReadView
MVCC 的实现依赖于： 隐藏字段、Undo Log、Read View。
16.4.1、什么是ReadView
ReadView就是事务在使用MVCC机制进行快照读操作时产生的读视图。当事务启动时，会生成数据库系统当前的一个快照，InnoDB为每个事务构造了一个数组，用来记录并维护系统当前活跃事务的ID（“活跃”指的就是，启动了但还没提交）。
16.4.2、设计思路
使用READ UNCOMMITTED隔离级别的事务，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了。
使用SERIALIZABLE隔离级别的事务，InnoDB规定使用加锁的方式来访问记录。
使用READ COMMITTED和REPEATABLE READ隔离级别的事务，都必须保证读到已经提交了的事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的，这是ReadView要解决的主要问题。
这个ReadView中主要包含4个比较重要的内容，分别如下：
-
creator_trx_id，创建这个 Read View 的事务 ID。说明：只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会为事务分配事务id，否则在一个只读事务中的事务id值都默认为0。
-
trx_ids，表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。 -
up_limit_id，活跃的事务中最小的事务 ID。 -
low_limit_id，表示生成ReadView时系统中应该分配给下一个事务的id值。low_limit_id 是系统最大的事务id值，这里要注意是系统中的事务id，需要区别于正在活跃的事务ID。注意：low_limit_id并不是trx_ids中的最大值，事务id是递增分配的。比如，现在有id为1， 2，3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成ReadView时，trx_ids就包括1和2，up_limit_id的值就是1，low_limit_id的值就是4。
16.4.3、ReadView的规则
有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见。
- 如果被访问版本的trx_id属性值与ReadView中的
creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。 - 如果被访问版本的trx_id属性值小于ReadView中的
up_limit_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。 - 如果被访问版本的trx_id属性值大于或等于ReadView中的
low_limit_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。 - 如果被访问版本的trx_id属性值在ReadView的
up_limit_id和low_limit_id之间，那就需要判断一下trx_id属性值是不是在 trx_ids 列表中。- 如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问。
- 如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。
16.4.4、MVCC整体操作流程
了解了这些概念之后，我们来看下当查询一条记录的时候，系统如何通过MVCC找到它：
-
首先获取事务自己的版本号，也就是事务 ID；
-
获取 ReadView；
-
查询得到的数据，然后与 ReadView 中的事务版本号进行比较；
-
如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照；
-
最后返回符合规则的数据。
如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性，一次类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对该事务完全不可见，查询结果就不包含该记录。
InnoDB中，MVCC是通过Undo Log + Read View 进行数据读取，Undo Log 保存了历史快照，而Read View规则帮我们判断当前版本的数据是否可见。
在隔离级别为读已提交（Read Committed）时，一个事务中的每一次 SELECT 查询都会重新获取一次Read View。
注意，此时同样的查询语句都会重新获取一次Read View，这时如果Read View不同，就可能产生不可重复读或者幻读的情况。
当隔离级别为可重复读的时候，就避免了不可重复读，这是因为一个事务只在第一次SELECT的时候会获取一次Read View，而后面所有的SELECT都会复用这个Read View，如表所示：
注意，此时同样的查询语句都会重新获取一次 Read View，这时如果 Read View 不同，就可能产生不可重复读或者幻读的情况。
当隔离级别为可重复读的时候，就避免了不可重复读，这是因为一个事务只在第一次 SELECT 的时候会获取一次 Read View，而后面所有的 SELECT 都会复用这个 Read View，如下表所示：
14.5、举例说明
假设现在student表中只有一条由事务id为8的事务插入的一条记录:
mysql> SELECT * FROM student;
+---------+----------+---------+
| id | name | class |
+---------+----------+---------+
| 1 | 张三 | 一班 |
+---------+----------+---------+
1 row in set (8.07 sec)
MVCC只能在READ COMMTTED和REPEATABLE READ两个隔离级别下工作。
14.5.1、READ COMMITTED隔离级别下
READ COMMITTED：每次读取数据前都生成一个ReadView。
现在有网个事务id分别为10、20的事务在执行:
# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
# Transaction 20
BEGIN;
#更新了一些别的表的记录
...
说明：事务执行过程中，只有在第一真正修改记录时（比如使用INSERT、DELETE、UPDATE语句），才会被分配一个单独的事务id，这个事务id是递增的。所以我们才在事务2中更新一些别的表的记录，目的是让他分配事务id。
此刻，表student中id为1的记录得到的版本链表如下所示：
假设现在有一个使用READ COMMITTED隔离级别的事务开始执行:
# 使用READ COMMITTED隔离级别的事务
BEGIN;
#SELECT1:Transaction 10、2日未提交
SELECT * FROM student WHERE id = 1;# 得到的列name的值为'张三'
这个SELECT1的执行过程如下:
步骤1：在执行SELECT语句时会先生成一个ReadView ，ReadView的trx_ids列表的内容就是[10，20]，up_limit_id为10，low_limit_id为21, creator_trx_id为0。
步骤2：从版本链中挑选可见的记录，从图中看出，最新版本的列name的内容是’王五’，该版本的trx_id值为10，在trx_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
步骤3：下一个版本的列name的内容是‘李四’，该版本的trx_id值也为10，也在trx_ids列表内，所以也不符合要求，继续跳到下一个版本。
步骤4：下一个版本的列name的内容是’张三’，该版本的trx_id值为8，小于ReadView中的up_limit_id值10，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为‘张三’的记录。
之后，我们把事务id为10的事务提交一下:
#Transaction 10
BEGIN;
UPDATE student SET name="李四"WHERE id=1;
UPDATE student SET name="王五"WHERE id=1;
COMMIT;
然后再到事务id为20的事务中更新一下表student中id为1的记录:
#Transaction 20
BEGIN;
#更新了一些别的表的记录
UPDATE student SET name="钱七"WHERE id=1;
UPDATE student SET name="宋八"WHERE id=1 ;
此刻，表student 中 id 为 1 的记录的版本链就长这样:
然后刚才使用 READ COMMITTED 隔离级别的事务中继续查找这个 id 为 1 的记录，如下：
#使用READ COMMITTED隔离级别的事务
BEGIN;
#SELECT1:Transaction 10、28均未提交
SELECT * FROM student WHERE id = 1;#得到的列name的值为'张三'
# SELECT2:Transaction 10提交，Transaction 20未提交
SELECT * FROM student WHERE id = 1;#得到的列name的值为'王五'
这个SELECT2的执行过程如下:
步骤1：在执行SELECT语句时会又会单独生成一个ReadView，该ReadView的trx_ids列表的内容就是[20]，up_limit_id为20，low_limit_id为21,creator_trx_id为0。
步骤2：从版本链中挑选可见的记录，从图中看出，最新版本的列name的内容是’宋八’，该版本的trx_id值为20，在trx_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
步骤3：下一个版本的列name的内容是’钱七’，该版本的trx_id值为20，也在trx_ids列表内，所以也不符合要求，继续跳到下一个版本。
步骤4：下一个版本的列name的内容是’王五’，该版本的trx_id值为10，小于ReadView中的up_limit_id值20，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为’王五’的记录。
以此类推，如果之后事务id为20的记录也提交了，再次在使用READ COMMITTED隔离级别的事务中查询表student中id值为1的记录时，得到的结果就是‘宋八’了，具体流程我们就不分析了。
强调:使用READ COMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的ReadView.
14.5.2、REPEATABLE READ隔离级别下
使用REPEATABLE READ隔离级别的事务来说，只会在第一次执行查询语句时生成一个 ReadView ，之后的查询就不会重复生成了。
14.5.3、如何解决幻读
假设现在表 student 中只有一条数据，数据内容中，主键 id=1，隐藏的 trx_id=10，它的 undo log 如下图所示。
假设现在有事务 A 和事务 B 并发执行，事务 A的事务 id 为20，事务 B的事务 id 为30。
步骤1：事务 A 开始第一次查询数据，查询的 SQL 语句如下。
select * from student where id >= 1;
在开始查询之前，MySQL 会为事务 A 产生一个 ReadView，此时 ReadView 的内容如下：trx_ids= [20,30]，up_limit_id=20，low_limit_id=31，creator_trx_id=20。
由于此时表 student 中只有一条数据，且符合 where id>=1 条件，因此会查询出来。然后根据 ReadView机制，发现该行数据的trx_id=10，小于事务 A 的 ReadView 里 up_limit_id，这表示这条数据是事务 A 开启之前，其他事务就已经提交了的数据，因此事务 A 可以读取到。
结论：事务 A 的第一次查询，能读取到一条数据，id=1。
步骤2：接着事务 B(trx_id=30)，往表 student 中新插入两条数据，并提交事务。
insert into student(id,name) values(2,'李四');
insert into student(id,name) values(3,'王五');
此时表student 中就有三条数据了，对应的 undo 如下图所示：
步骤3：接着事务 A 开启第二次查询，根据可重复读隔离级别的规则，此时事务 A 并不会再重新生成ReadView。此时表 student 中的 3 条数据都满足 where id>=1 的条件，因此会先查出来。然后根据ReadView 机制，判断每条数据是不是都可以被事务 A 看到。
1）首先 id=1 的这条数据，前面已经说过了，可以被事务 A 看到。
2）然后是 id=2 的数据，它的 trx_id=30，此时事务 A 发现，这个值处于 up_limit_id 和 low_limit_id 之间，因此还需要再判断 30 是否处于 trx_ids 数组内。由于事务 A 的 trx_ids=[20,30]，因此在数组内，这表示 id=2 的这条数据是与事务 A 在同一时刻启动的其他事务提交的，所以这条数据不能让事务 A 看到。
3）同理，id=3 的这条数据，trx_id 也为 30，因此也不能被事务 A 看见。
结论：最终事务 A 的第二次查询，只能查询出 id=1 的这条数据。这和事务 A 的第一次查询的结果是一样的，因此没有出现幻读现象，所以说在 MySQL 的可重复读隔离级别下，不存在幻读问题。
6. 总结
这里介绍了MVCC在READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行快照读操作时访问记录的版本链的过程。这样使不同事务的读-写、写-读操作并发执行，从而提升系统性能。
核心点在于 ReadView 的原理，READ COMMITTD、REPEATABLE READ这两个隔离级别的一个很大不同就是生成ReadView的时机不同：
-
READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView -
REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复使用这个ReadView就好了。
说明：我们之前说执行DELETE语句或者更新主键的UPDATE语句并不会立即把对应的记录完全从页面中删除，而是执行一个所谓的delete mark操作，相当于只是对记录打上了一个删除标志位，这主要就是为MVCC服务的。
通过MVCC我们可以解决：
- 读写之间阻塞的问题。通过MVCC可以让读写互相不阻塞，即读不阻塞写，写不阻塞读，这样就可以提升事务并发处理能力。
- 降低了死锁的概率。这是因为MVCC采用了乐观锁的方式，读取数据时并不需要加锁，对于写操作，也只锁定必要的行。
- 解决快照读的问题。当我们查询数据库在某个时间点的快照时，只能看到这个时间点之前事务提交更新的结果，而不能看到这个时间点之后事务提交的更新结果。
十七、其它数据库日志
MySQL8.0官网日志地址: /doc/refman/8.0/en/
17.1、MySQL支持的日志
1.1、日志类型
MySQL有不同类型的日志文件，用来存储不同类型的日志，分为二进制日志、错误日志、通用查询日志和慢查询日志，这也是常用的4种。MySQL 8又新增两种支持的日志：中继日志和数据定义语句日志。使用这些日志文件，可以查看MySQL内部发生的事情。
-
慢查询日志： 记录所有执行时间超过long_query_time的所有查询，方便我们对查询进行优化。
-
通用查询日志： 记录所有连接的起始时间和终止时间，以及连接发送给数据库服务器的所有指令，对我们复原操作的实际场景、发现问题，甚至是对数据库操作的审计都有很大的帮助。
-
错误日志： 记录MySQL服务的启动、运行或停止MySQL服务时出现的问题，方便我们了解服务器的状态，从而对服务器进行维护。
-
二进制日志： 记录所有更改数据的语句，可以用于主从服务器之间的数据同步，以及服务器遇到故障时数据的无损失恢复。
-
中继日志： 用于主从服务器架构中，从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容，来同步主服务器上的操作。
-
数据定义语句日志： 记录数据定义语句执行的元数据操作。
除二进制日志外，其他日志都是文本文件。默认情况下，所有日志创建于MySQL数据目录中。
1.2、日志的弊端
-
日志功能会
降低MySQL数据库的性能。 -
日志会
占用大量的磁盘空间。
17.2、通用查询日志(general query log)
通用查询日志用来记录用户的所有操作，包括启动和关闭MySQL服务、所有用户的连接开始时间和截止时间、发给 MySQL 数据库服务器的所有 SQL 指令等。当我们的数据发生异常时， 查看通用查询日志，还原操作时的具体场景 ，可以帮助我们准确定位问题。
2.1、查看当前状态
mysql> SHOW VARIABLES LIKE '%general%';
2.2、启动日志
方式1：永久性方式
修改或者配置文件来设置
[mysqld]
general_log=ON
general_log_file=[path[filename]] #日志文件所在目录路径，filename为日志文件名
# 如果不指定目录和文件名，通用查询日志将默认存储在MySQL数据目录中的文件中，hostname表示主机名。
方式2：临时性方式
SET GLOBAL general_log=on; # 开启通用查询日志
SET GLOBAL general_log_file=’path/filename’; # 设置日志文件保存位置
SET GLOBAL general_log=off; # 关闭通用查询日志
SHOW VARIABLES LIKE 'general_log%'; # 查看设置后情况
2.3、停止日志
方式1：永久性方式
[mysqld]
general_log=OFF
方式2：临时性方式
SET GLOBAL general_log=off;
SHOW VARIABLES LIKE 'general_log%';
17.3、错误日志(error log)
通过错误日志可以查看系统的运行状态，便于即使发现故障、修复故障。如果MySQL服务出现异常，错误日志是发现问题、解决故障的首选。
3.1、启动日志
在MySQL数据库中，错误日志功能是默认开启的。而且，错误日志无法被禁止。
[mysqld]
log-error=[path/[filename]] #path为日志文件所在的目录路径，filename为日志文件名
# 默认情况下，错误日志存储在MySQL数据的数据文件夹下，名称默认为
3.2、查看日志
mysql> SHOW VARIABLES LIKE 'log_err%';
3.3、删除\刷新日志
install -omysql -gmysql -m0644 /dev/null /var/log/
mysqladmin -uroot -p flush-logs
- MySQL5.5.7以前的版本，flush-logs将错误日志文件重命名为filename.err_old，并创建新的日志文件。
- 从MySQL5.5.7开始，flush-logs只是重新打开日志文件，并不做日志备份和创建的操作。
- 如果日志文件不存在，MySQL启动或者执行flush-logs时会自动创建新的日志文件。重新创建错误日志，大小为0字节。
17.4、二进制日志(bin log)
binlog是MySQL中比较重要的日志了，它记录了数据库所有执行的DDL和DML等数据库更新时间的语句，但是不包含没有修改任何数据的语句。
binlog主要应用场景:
- 一是用于数据恢复，如果MySQL数据库意外停止，可以通过二进制日志文件来查看用户执行了哪些操作，对数据库服务器文件做了哪些修改，然后根据二进制日志文件中的记录来恢复数据库服务器.
- 二是用于数据复制，由于日志的延续性和时效性，master把它的二进制日志传递给slaves来达到hestpr-tlave教据一致的目的。
可以说MysQL数据库的数据备份、主备、主主、主从都离不开binlog，需要依靠binlog来同步数据，保证数据一致性。
4.1、查看默认情况
mysql> show variables like '%log_bin%';
4.2、日志参数设置
方式1：永久性方式
[mysqld]
#启用二进制日志
log_bin=binlog
binlog_expire_logs_seconds=600
max_binlog_size=100M
设置带文件夹的bin-log日志存放目录
[mysqld]
log-bin="/var/lib/mysql/binlog/atguigu-bin"
注意：新建的文件夹需要使用mysql用户，使用下面的命令即可。
chown -R -v mysql:mysql binlog
方式2：临时性方式
# global 级别
mysql> set global sql_log_bin=0;
ERROR 1228 (HY000): Variable 'sql_log_bin' is a SESSION variable and can`t be used with SET GLOBAL
# session级别
mysql> SET sql_log_bin=0;
Query OK, 0 rows affected (0.01 秒)
4.3、查看日志
mysqlbinlog -v "/var/lib/mysql/binlog/atguigu-bin.000002"
# 不显示binlog格式的语句
mysqlbinlog -v --base64-output=DECODE-ROWS "/var/lib/mysql/binlog/atguigu-bin.000002"
# 可查看参数帮助
mysqlbinlog --no-defaults --help
# 查看最后100行
mysqlbinlog --no-defaults --base64-output=decode-rows -vv atguigu-bin.000002 |tail -100
# 根据position查找
mysqlbinlog --no-defaults --base64-output=decode-rows -vv atguigu-bin.000002 |grep -A20 '4939002'
上面这种办法读取出binlog日志的全文内容比较多，不容易分辨查看到pos点信息，下面介绍一种更为方便的查询命令：
mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
-
IN 'log_name'：指定要查询的binlog文件名（不指定就是第一个binlog文件） -
FROM pos：指定从哪个pos起始点开始查起（不指定就是从整个文件首个pos点开始算） -
LIMIT [offset]：偏移量(不指定就是0) -
row_count:查询总条数（不指定就是所有行）
mysql> show binlog events in 'atguigu-bin.000002';
4.4、使用日志恢复数据
mysqlbinlog恢复数据的语法如下：
mysqlbinlog [option] filename|mysql –uuser -ppass;
-
filename：是日志文件名。 -
option：可选项，比较重要的两对option参数是–start-date、–stop-date 和 --start-position、-- stop-position。-
--start-date 和 --stop-date：可以指定恢复数据库的起始时间点和结束时间点。 -
--start-position和--stop-position：可以指定恢复数据的开始位置和结束位置。
-
注意：使用mysqlbinlog命令进行恢复操作时，必须是编号小的先恢复，例如atguigu-bin.000001必须在atguigu-bin.000002之前恢复。
4.5、删除二进制日志
- PURGE MASTER LOGS：删除指定日志文件
PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名’
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期’
- RESET MASTER：删除所有二进制文件
RESET MASTER;
17.5、再谈二进制日志(binlog)
5.1、写入机制
binlog的写入时机也非常简单，事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。因为一个事务的binlog不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为binlog cache。
write和fsync的时机，可以由参数sync_binlog控制，默认是 0。为0的时候，表示每次提交事务都只write，由系统自行判断什么时候执行fsync。虽然性能得到提升，但是机器宕机，page cache里面的binglog 会丢失。如下图：
为了安全起见，可以设置为1，表示每次提交事务都会执行fsync，就如同redo log刷盘流程 一样。最后还有一种折中方式，可以设置为N(N>1)，表示每次提交事务都write，但累积N个事务后才fsync。
在出现IO瓶颈的场景里，将sync_binlog设置成一个比较大的值，可以提升性能。同样的，如果机器宕机，会丢失最近N个事务的binlog日志。
5.2、binlog与redolog对比
- redo log 它是
物理日志，记录内容是“在某个数据页上做了什么修改”，属于 InnoDB 存储引擎层产生的。 - 而 binlog 是
逻辑日志，记录内容是语句的原始逻辑，类似于“给 ID=2 这一行的 c 字段加 1”，属于MySQL Server 层。 - 虽然它们都属于持久化的保证，但是侧重点不同。
- redo log 让InnoDB存储引擎拥有了崩溃恢复能力。
- binlog保证了MySQL集群架构的数据一致性
5.3、两阶段提交
在执行更新语句过程，会记录redo log与binlog两块日志，以基本的事务为单位，redo log在事务执行过程中可以不断写入，而binlog只有在提交事务时才写入，所以redo log与binlog的写入时机不一样。
为了解决两份日志之间的逻辑一致问题，InnoDB存储引擎使用 两阶段提交 方案。
使用 两阶段提交 后，写入binlog时发生异常也不会有影响，因为MySQL根据redo log日志恢复数据时，发现redo log还处于prepare阶段，并且没有对应binlog日志，就会回滚该事务。
另一个场景，redo log设置commit阶段发生异常，那会不会回滚事务呢？
并不会回滚事务，它会执行上图框住的逻辑，虽然redo log是处于prepare阶段，但是能通过事务id找到对应的binlog日志，所以MySQL认为是完整的，就会提交事务恢复数据。
17.6、中继日志(relay log)
6.1、介绍
中继日志只在主从服务器架构的从服务器上存在 。从服务器为了与主服务器保持一致，要从主服务器读取二进制日志的内容，并且把读取到的信息写入本地的日志文件中，这个从服务器本地的日志文件就叫中继日志。然后，从服务器读取中继日志，并根据中继日志的内容对从服务器的数据进行更新，完成主从服务器的数据同步。
6.2、恢复的典型错误
如果从服务器宕机，有的时候为了系统恢复，要重装操作系统，这样就可能会导致你的服务器名称与之前不同。而中继日志里是包含从服务器名的。在这种情况下，就可能导致你恢复从服务器的时候，无法从宕机前的中继日志里读取数据，以为是日志文件损坏了，其实是名称不对了。
解决的方法也很简单，把从服务器的名称改回之前的名称。
十八、主从复制
18.1、主从复制概述
1.1、如何提升数据库并发能力
在实际工作中，常常将Redis作为缓存与MySQL配合来使用，当有请求的时候，首先会从缓存中进行查找，如果存在就直接取出。如果不存在再访问数据库，这样就提升了读取的效率，也减少了对后端数据库的访问压力。Redis的缓存架构是高并发架构中非常重要的一环。
一般应用对数据库而言都是“读多写少”，也就说对数据库读取数据的压力比较大，有一个思路就是采用数据库集群的方案，做主从架构、进行读写分离，这样同样可以提升数据库的并发处理能力。但并不是所有的应用都需要对数据库进行主从架构的设置，毕竟设置架构本身是有成本的。
如果我们的目的在于提升数据库高并发访问的效率，那么首先考虑的是如何优化SQL和索引，这种方式简单有效；其次才是采用缓存的策略，比如使用 Redis将热点数据保存在内存数据库中，提升读取的效率；最后才是对数据库采用主从架构，进行读写分离。
1.2、主从复制的作用
第1个作用：读写分离。
第2个作用就是数据备份。
第3个作用是具有高可用性。
18.2、主从复制的原理
2.1、原理剖析
三个线程
实际上主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中，会基于3 个线程来操作，一个主库线程，两个从库线程。
二进制日志转储线程（Binlog dump thread）是一个主库线程。当从库线程连接的时候， 主库可以将二进制日志发送给从库，当主库读取事件（Event）的时候，会在 Binlog 上加锁，读取完成之后，再将锁释放掉。
从库 I/O 线程会连接到主库，向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分，并且拷贝到本地的中继日志 （Relay log）。
从库 SQL 线程会读取从库中的中继日志，并且执行日志中的事件，将从库中的数据与主库保持同步。
注意：
不是所有版本的MySQL都默认开启服务器的二进制日志。在进行主从同步的时候，我们需要先检查服务器是否已经开启了耳机二进制文件。
除非特殊指定，默认情况下从服务器会执行所有主服务器中保存的事件。也可以通过配置，使从服务器执行特定的事件。
复制三步骤
步骤1：Master将写操作记录到二进制日志（binlog）。
步骤2：Slave将Master的binary log events拷贝到它的中继日志（relay log）；
步骤3：Slave重做中继日志中的事件，将改变应用到自己的数据库中。 MySQL复制是异步的且串行化的，而且重启后从接入点开始复制。
复制的最大问题：延时
2.2、复制的基本原则
-
每个
Slave只有一个Master -
每个
Slave只能有一个唯一的服务器ID -
每个
Master可以有多个Slave
18.3、同步数据一致性问题
主从同步的要求：
-
读库和写库的数据一致(最终一致)；
-
写数据必须写到写库；
-
读数据必须到读库(不一定)；
3.1、理解主从延迟问题
进行主从同步的内容是二进制日志，它是一个文件，在进行网络传输的过程中就一定会存在主从延迟（比如 500ms），这样就可能造成用户在从库上读取的数据不是最新的数据，也就是主从同步中的数据不一致性问题。
3.2、主从延迟问题原因
在网络正常的时候，日志从主库传给从库所需的时间是很短的，即T2-T1的值是非常小的。即，网络正常情况下，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。
主备延迟最直接的表现是，从库消费中继日志（relay log）的速度，比主库生产binlog的速度要慢。 造成原因：
1、从库的机器性能比主库要差
2、从库的压力大
3、大事务的执行
3.3、如何减少主从延迟
若想要减少主从延迟的时间，可以采取下面的办法：
-
降低多线程大事务并发的概率，优化业务逻辑
-
优化SQL，避免慢SQL，
减少批量操作，建议写脚本以update-sleep这样的形式完成。 -
提高从库机器的配置，减少主库写binlog和从库读binlog的效率差。 -
尽量采用
短的链路，也就是主库和从库服务器的距离尽量要短，提升端口带宽，减少binlog传输的网络延时。 -
实时性要求的业务读强制走主库，从库只做灾备，备份。
3.4、如何解决一致性问题
读写分离情况下，解决主从同步中数据不一致的问题， 就是解决主从之间 数据复制方式 的问题，如果按照数据一致性 从弱到强 来进行划分，有以下 3 种复制方式。
方法1：异步复制
异步模式就是客户端提交commit之后不需要再等从库返回任何结果，而是直接将结果返回给客户端，这样做的好处是不会影响主库写的效率，但可能会存在主库宕机，而Binlog还没有同步到从库的情况，也就是此时的主库和从库数据不一致。这时候从从库中选择一个作为新主，那么新主则可能缺少原来主服务器中已提交的事务。所以，这种复制模式下的数据一致性是最弱的。
方法2：半同步复制
MySQL5.5版本之后开始支持半同步复制的方式。原理是在客户端提交CcOMMIT之后不直接将结果返回给客户端,而是等待至少有一个从库接收到了Binlog，并且写入到中继日志中，再返回给客户端。
这样做的好处就是提高了数据的一致性，当然相比于异步复制来说，至少多增加了一个网络连接的延迟，降低了主库写的效率。
在MySQL5.7版本中还增加了一个rpl_semi_sync_master_wait.for_slave.count参数，可以对应答的从库数量进行设置，默认为1，也就是说只要有1个从库进行了响应，就可以返回给客户端。如果将这个参数调大，可以提升数据一致性的强度，但也会增加主库等待从库响应的时间。
方法3：组复制
首先我们将多个节点共同组成一个复制组，在执行读写（RW）事务的时候，需要通过一致性协议层（Consensus 层）的同意，也就是读写事务想要进行提交，必须要经过组里“大多数人”（对应 Node 节点）的同意，大多数指的是同意的节点数量需要大于（N/2+1），这样才可以进行提交，而不是原发起方一个说了算。而针对只读（RO）事务则不需要经过组内同意，直接 COMMIT 即可。
在主从架构的配置中，如果想要采取读写分离的策略，可以自己编写程序，也可以通过第三方的中间件来实现。
十九、数据库备份与恢复
19.1、物理备份与逻辑备份
物理备份 ：备份数据文件，转储数据库物理文件到某一目录。物理备份恢复速度比较快，但占用空间比较大，MySQL中可以用xtrabackup工具来进行物理备份。
逻辑备份 ：对数据库对象利用工具进行导出工作，汇总入备份文件内。逻辑备份恢复速度慢，但占用空间小，更灵活。MySQL 中常用的逻辑备份工具为mysqldump。逻辑备份就是备份sql语句，在恢复的时候执行备份的sql语句实现数据库数据的重现。
19.2、mysqldump实现逻辑备份
2.1、备份一个数据库
mysqldump –u 用户名称 –h 主机名称 –p密码 待备份的数据库名称[tbname, [tbname...]]> 备份文件名称.sql
mysqldump -uroot -p atguigu> #备份文件存储在当前目录下
mysqldump -uroot -p atguigudb1 > /var/lib/mysql/
2.2、备份全部数据库
mysqldump -uroot -pxxxxxx --all-databases > all_database.sql
mysqldump -uroot -pxxxxxx -A > all_database.sql
2.3、备份部分数据库
mysqldump –u user –h host –p --databases [数据库的名称1 [数据库的名称2...]] > 备份文件名称.sql
mysqldump -uroot -p --databases atguigu atguigu12 >two_database.sql
mysqldump -uroot -p -B atguigu atguigu12 > two_database.sql
2.4、备份部分表
mysqldump –u user –h host –p 数据库的名称 [表名1 [表名2...]] > 备份文件名称.sql
mysqldump -uroot -p atguigu book>
#备份多张表
mysqldump -uroot -p atguigu book account > 2_tables_bak.sql
2.5、备份单表的部分数据
mysqldump -uroot -p atguigu student --where="id < 10 " > student_part_id10_low_bak.sql
2.6、排除某些表的备份
mysqldump -uroot -p atguigu --ignore-table= > no_stu_bak.sql
2.7、只备份结构或只备份数据
- 只备份结构
mysqldump -uroot -p atguigu --no-data > atguigu_no_data_bak.sql
- 只备份数据
mysqldump -uroot -p atguigu --no-create-info > atguigu_no_create_info_bak.sql
2.8、备份中包含存储过程、函数、事件
mysqldump -uroot -p -R -E --databases atguigu > fun_atguigu_bak.sql
19.3、mysql命令恢复数据
mysql –u root –p [dbname] <
3.1、单库备份中恢复单库
#备份文件中包含了创建数据库的语句
mysql -uroot -p <
#备份文件中不包含了创建数据库的语句
mysql -uroot -p atguigu4<
3.2、全量备份恢复
mysql –u root –p <
3.3、从全量备份中恢复单库
sed -n '/^-- Current Database: `atguigu`/,/^-- Current Database: `/p' all_database.sql >
#分离完成后我们再导入即可恢复单个库
3.4、从单库备份中恢复单表
cat | sed -e '/./{H;$!d;}' -e 'x;/CREATE TABLE `class`/!d;q' > class_structure.sql
cat | grep --ignore-case 'insert into `class`' > class_data.sql
#用shell语法分离出创建表的语句及插入数据的语句后 再依次导出即可完成恢复
use atguigu;
mysql> source class_structure.sql;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> source class_data.sql;
Query OK, 1 row affected (0.01 sec)
19.4、表的导出与导入
4.1、表的导出
- 使用SELECT…INTO OUTFILE导出文本文件
SHOW GLOBAL VARIABLES LIKE '%secure%';
SELECT * FROM account INTO OUTFILE "/var/lib/mysql-files/";
- 使用mysqldump命令导出文本文件
mysqldump -uroot -p -T "/var/lib/mysql-files/" atguigu account
# 或
mysqldump -uroot -p -T "/var/lib/mysql-files/" atguigu account --fields-terminated- by=',' --fields-optionally-enclosed-by='\"'
- 使用mysql命令导出文本文件
mysql -uroot -p --execute="SELECT * FROM account;" atguigu> "/var/lib/mysql-files/"
4.2、表的导入
- 使用LOAD DATA INFILE方式导入文本文件
LOAD DATA INFILE '/var/lib/mysql-files/account_0.txt' INTO TABLE atguigu.account;
# 或
LOAD DATA INFILE '/var/lib/mysql-files/account_1.txt' INTO TABLE atguigu.account FIELDS TERMINATED BY ',' ENCLOSED BY '\"';
- 使用mysqlimport方式导入文本文件
mysqlimport -uroot -p atguigu '/var/lib/mysql-files/' --fields-terminated- by=',' --fields-optionally-enclosed-by='\"'
19.5、数据库迁移
数据迁移(data migration)是指选择、准备、提取和转换数据，并将数据从一个计算机存储系统永久地传输到另一个计算机存储系统的过程。此外，验证迁移数据的完整性和退役原来旧的数据存储，也被认为是整个数据迁移过程的一部分。
数据库迁移的原因是多样的，包括服务器或存储设备更换、维护或升级，应用程序迁移，网站集成，灾难恢复和数据中心迁移。
根据不同的需求可能要采取不同的迁移方案，但总体来讲，MySQL-数据迁移方案大致可以分为物理迁移和逻辑迁移两类。通常以尽可能自动化的方式执行，从而将人力资源从繁琐的任务中解放出来。
迁移方案
- 物理迁移
物理迁移适用于大数据量下的整体迁移。使用物理迁移方案的优点是比较快速，但需要停机迁移并且要求MySQL版本及配置必须和原服务器相同，也可能引起未知问题。
物理迁移包括拷贝数据文件和使用XtraBackup备份工具两种。
不同服务器之间可以采用物理迁移，我们可以在新的服务器上安装好同版本的数据库软件，创建好相同目录，建议配置文件也要和原数据库相同，然后从原数据库方拷贝来数据文件及日志文件，配置好文件组权限，之后在新服务器这边使用mysqld命令启动数据库。
- 逻辑迁移
逻辑迁移适用范围更广，无论是部分迁移还是全量迁移，都可以使用逻辑迁移。逻辑迁移中使用最多的就是通过mysqldump 等备份工具。
迁移注意点
- 相同版本的数据库之间迁移注意点
指的是在主版本号相同的MySQL数据库之间进行数据库移动。
方式1:因为迁移前后MysQL数据库的主版本号相同，所以可以通过复制数据库目录来实现数据库迁移，但是物理迁移方式只适用于MylISAM引擎的表。对于InnoDB表，不能用直接复制文件的方式备份数据库。
方式2:最常见和最安全的方式是使用mysqldump命令导出数据，然后在目标数据库服务器中使用MySQL命令导入。
- 不同版本的数据库之间迁移注意点
例如，原来很多服务器使用5.7版本的MysQL数据库，在版本推出来以后，改进了5.7版本的很多缺陷，因此需要把数据库升级到版本
旧版本与新版本的MysQL可能使用不同的默认字符集，例如有的旧版本中使用latin1作为默认字符集，而最新版本的MysQL默认字符集为utf8mb4。如果数据库中有中文数据，那么迁移过程中需要对默认字符集进行修改，不然可能无法正常显示数据。
高版本的MysQL数据库通常都会兼容低版本，因此可以从低版本的MySQL数据库迁移到高版本的MySQL数据库。
- 不同数据库之间迁移注意点
不同数据库之间迁移是指从其他类型的数据库迁移到MysQL数据库，或者从MysQL数据库迁移到其他类型的数据库。这种迁移没有普适的解决方法。
迁移之前，需要了解不同数据库的架构，比较它们之间的差异。不同数据库中定义相同类型的数据的关键字可能会不同。例如，MySQL中日期字段分为DATE和TIME两种，而ORACLE日期字段只有DATE； SQL Server数据库中有ntext、lmage等数据类型，MySQL数据库没有这些数据类型;MySQL支持的ENUM和SET类型，这些SQL Server数据库不支持。
另外，数据库厂商并没有完全按照SQL标准来设计数据库系统，导致不同的数据库系统的SQL语句有差别。例如，微软的SQL Server软件使用的是T-SQL语句，T-SQL中包含了非标准的SQL语句，不能和MySQL的SQL语句兼容。
不同类型数据库之间的差异造成了互相迁移的困难，这些差异其实是商业公司故意造成的技术壁垒。但是不同类型的数据库之间的迁移并不是完全不可能。例如，可以使用MyODBC实现MysQL和SQL Server之间的迁移。MySQL官方提供的工具MySQL Migration Toolkit也可以在不同数据之间进行数据迁移。MySQL迁移到oracle时，需要使用mysqldump命令导出sql文件，然后，手动更改sql文件中的CREATE语句。
19.6、删库了不敢跑，能干点啥?
传统的高可用架构是不能预防误删数据的，因为主库的一个drop table命令，会通过binlog传给所有从库和级联从库，进而导致整个集群的实例都会执行这个命令。
为了找到解决误删数据的更高效的方法，我们需要先对和MySQL相关的误删数据，做下分类:
- 使用delete语句误删数据行;
- 使用drop table或者truncate table语句误删数据表;
- 使用drop database语句误删数据库;
- 使用rm命令误删整个MySQL实例。8.1
delete：误删行
处理措施1:数据恢复
使用Flashback工具恢复数据。
原理：修改binlog内容，拿回原库重放。如果误删数据涉及到了多个事务的话，需要将事务的顺序调过来再执行。
使用前提: binlog_format=row和binlog_row_image=FULL。
处理措施2:预防
- 代码上线前，必须SQL审查、审计。
- 建议可以打开安全模式，把sql_safe_updates参数设置为on。强制要求加where条件且where后需要是索引字段，否则必须使用limit。否则就会报错。
truncate/drop：误删库/表
这种情况下恢复数据，需要使用全量备份与增量日志结合的方式。方案的前提:有定期的全量备份，并且实时备份binlog。
# 举例：有人误删了一个库，时间为下午3点。步骤如下:
1. 取最近一次全量备份。假设设置数据库库是一天一备，最近备份数据是当天凌晨2点;
2. 用备份恢复出一个临时库;(注意:这里选择临时库，而不是直接操作主库)
3. 取出凌晨2点之后的binlog日志;
4. 剔除误删除数据的语句外，其它语句全部应用到临时库。(前面讲过binlog的恢复)
5. 最后恢复到主库
预防使用truncate /drop误删库/表
（1）权限分离
- 限制帐户权限，核心的数据库，一般都不能随便分配写权限，想要获取写权限需要审批。比如只给业务开发人员DML权限，不给truncate/drop权限。即使是DBA团队成员，日常也都规定只使用只读账号，必要的时候才使用有更新权限的账号。
- 不同的账号，不同的数据之间要进行权限分离，避免一个账号可以删除所有库。
（2）制定操作规范
比如在删除数据表之前，必须先对表做改名操作（比如加_to_be_deleted )。然后，观察一段时间，确保对业务无影响以后再删除这张表。
（3）设置延迟复制备库
简单的说延迟复制就是设置一个固定的延迟时间，比如1个小时，让从库落后主库一个小时。出现误删除操作1小时内，到这个备库上执行stop slave，再通过之前介绍的方法，跳过误操作命令，就可以恢复出需要的数据。这里通过CHANGE MASTER TO MASTER_DELAY = N命令，可以指定这个备库持续保持跟主库有N秒的延迟。比如把N设置为3600，即代表1个小时。