一. 存储引擎简介
mysql存储引擎相当于Linux文件系统，但是比其更加复杂
二. 存储引擎功能
- 进行数据读写
- 保证数据安全和一致性
- 提高数据库性能
- 进行数据热备份
- 进行自动故障恢复
- 对高可用方面有支持
三. 存储引擎种类(Oracle MySQL)《笔试》
InnoDB #5.5版本之后默认存储引擎，提高可靠性和高性能，修改快并且支持事务
MyISAM #5.5版本之前默认存储引擎，插入块，查询快
MEMORY #MySQL特殊的存储引擎，用存储在内存中的内容创建表，并且数据都放在内存中
ARCHIVE #MySQL应用，只允许插入查询，不允许修改删除的一种引擎
FEDERATED
EXAMPLE
BLACKHOLE
MERGE
NDBCLUSTER
CSV
四. 存储引擎种类查看（存储引擎是作用在表上的，也就意味着，不同的表可以有不同的存储引擎类型）
1. show engines;
--查询当前数据库所有的存储引擎
--show table status;（查询表状态也可以看）
--show create table city\G;（查询建表语句也可以看当时指定的存储引擎）
--SHOW TABLE STATUS LIKE 'CountryLanguage'\G
2.select @@default_storage_engine;
--查询当前数据库默认的存储引擎
3. select table_name,engine from information_schema.tables where table_schema='word';
--查询world库中虚拟库中各个表的存储引擎
4. 补充
PerconaDB:默认是XtraDB
MariaDB:默认是InnoDB
其他的存储引擎支持:
TokuDB
RocksDB
MyRocks
以上三种存储引擎的共同点:压缩比较高,数据插入性能极高
现在很多的NewSQL,使用比较多的功能特性
五. 修改存储引擎
1. set修改：
set session default_storage_engine=myisam;（回话级别）
--直接修改默认引擎为myisam，只影响当前回话
set global default_storage_engine=myisam（全局级别）
--只影响新回话，不影响当前回话
2. 写入配置文件（/etc/my.cnf）
[mysqld]
default_storage_engine=myisam
重启永久生效，但是不建议
3. alter table world.t1 engine=myisam;
--把world库中的t1表的存储引擎改为myisam，同时此命令还可以整理delete命令操作后的碎片
（不会立即释放）业务清闲时操作
optimize table 表名;
4. 批量修改（子句拼接，CONCAT子句）
--select concat("alter table zabbix.",table_name," engine tokudb;")
from information_schema.tables
where table_schema='zabbix'
into outfile '/tmp/tokudb.sql';
六. InonoDB存储引擎介绍
image.png
在MySQL5.5版本之后，默认的存储引擎，提供高可靠性和高性能
6.1InonoDB存储引擎优点
1、支持事务（Transaction）
2、MVCC（Multi-Version Concurrency Control多版本并发控制）
3、行级锁(Row-level Lock) 行级锁（记录锁）+表锁（InonoDB引擎）——表锁（MyISAM引擎）
4、ACSR（Auto Crash Safey Recovery）自动的故障安全恢复
5、支持热备份(Hot Backup)
6、Replication: Group Commit , GTID (Global Transaction ID) ,多线程(Multi-Threads-SQL )
七. InonoDB存储引擎的物理存储结构
7.1 InonoDB最直观的存储方式
1. ibdata1：5.7版本：系统数据字典信息(统计信息,状态，权限，配置等)，UNDO表空间等数据（8.0版本独立）
2. ib_logfile0 ~ ib_logfile1: REDO日志文件，事务日志文件。
3. ibtmp1： 5.7版本：临时表空间磁盘位置，存储临时表（group by，join on，union，having子句应用的临时存储表）
4. city.frm：存储表的列信息,表定义
5. city.ibd：表的数据行和索引
6. ib_buffer_pool：缓存区池的映射文件
7.2 InonoDB的表空间管理模式
示义：表---独立表空间---表空间数据文件（ibd）---段，区，页
7.2.1 共享表空间模式
需要将所有数据存储到同一个表空间中 ，管理比较混乱
5.5版本出现的管理模式，也是默认的管理模式。
5.6版本以后，共享表空间保留，只用来存储:数据字典信息,undo,临时表。
5.7 版本,临时表（ibtmp）被独立出来了
8.0版本,undo回滚数据也被独立出去了
--此模式目前依然保留，用来存储系统数据（ibdata1）。数据存储在磁盘当中，但是磁盘容量是有限的，
若数据大于整个磁盘的存储空间是不能分开存储的，所以在两者之间构建一个逻辑空间。而这个逻辑空间
可以是多个磁盘存储量的和。当存储不够时可以继续添加磁盘来扩充容量，保证了数据存储量足够大。
--但是会把所有的数据存储在一起，导致混乱，数据量过大。
7.2.2 共享表空间的设置
1. select @@innodb_data_file_path;
---查看ibdata1文件大小，默认12M，后边的autoextend为自动增长
2. show variables like '%extend%';
---查看到（innodb_autoextend_increment）的值，就是ibdata1文件自动增长空间，文件默认为12M
占满后每次自动增加多大（64M）
3. 配置文件写入
vim /etc/my.cnf
[mysqld]
innodb_data_file_path=ibdata1:512M;ibdata2:512M:autoextend
---定义ibdata文件（两个），大小设定为512M，第一个沾满后切换到第二个，并设置自动增长
（自动增长默认就好），但是此步骤是在安装MySQL进行初始化之前就应该进行配置的（先配置，再初始化）
7.2.3 独立表空间模式
从5.6，默认表空间不再使用共享表空间，替换为独立表空间。
主要存储的是用户数据
存储特点为：一个表一个ibd文件，相当于把数据与磁盘之间的逻辑空间分块，存储数据行和索引信息
基本表结构元数据存储：
xxx.frm
最终结论：
元数据 数据行+索引
mysql表数据 =（ibdataX+frm）+ibd(段、区、页)
DDL DML+DQL
MySQL的存储引擎日志：
Redo Log: ib_logfile0 ib_logfile1，重做日志
Undo Log: ibdata1 ibdata2(存储在共享表空间中)，回滚日志
临时表:ibtmp1，在做join union操作产生临时数据，用完就自动
7.2.4 独立表空间的设置
1. select @@innodb_file_per_table;
---查看当前表空间模式（1为独立表空间模式，0为共享表空间模式）
2. set global innodb_file_per_table=0;
---把当前独立表空间模式改为共享表空间模式（在共享表空间模式下创建的表是没有表的ibd文件的，即
使再次改回独立表空间模式，在共享表空间模式下创建的表的性质也不会更改回来）
7.2.5 独立表空间迁移
1. 按照原备份在测试库将之前的建表语句提取，进行创建一模一样的表（获得frm与ibd）
2. 将新创建的表空间删除
- select concat('alter table ',table_schema,'.'table_name,' discard tablespace;')
from information_schema.tables
where table_schema='confluence'
into outfile '/tmp/discad.sql';
- source /tmp/discard.sql
3. 执行过程中发现由于主外键关系有的表执行不成功，只能一个一个分析表结构
set foreign_key_checks=0 跳过外键检查
最后把有问题的表进行删除
4. 拷贝生产中confulence库下的所有表的ibd文件拷贝到准备好的环境中
- select concat('alter table ',table_schema,'.'table_name,' import tablespace;')
from information_schema.tables
where table_schema='confluence'
into outfile '/tmp/discad.sql';
- source /tmp/discad.sql
5. 验证数据
表都可以访问了，数据挽回到了出现问题时刻的状态，个别表恢复不了。
八. 事务的ACID特性
8.1 事务简介
事务保证在一个完整的业务逻辑中，所有涉及到的语句要么执行全部成功，要么全部失败
8.2 事务特性
8.2.1 Atomic：原子性
所有语句作为一个单元全部执行或者全部取消，不可以出现中间状态
8.2.2 Consistent：一致性
如果数据库在事务开始时处于一致状态，则在执行该事务期间将保留一致状态
8.2.3 Isolated：隔离性
事务之间不可以相互影响
8.2.4 Durable：持久性
事务成功完成后，所做的更改都会准确的记录在数据库中，所做更改不会丢失
九. 事务的生命周期（事务控制语句）
9.1 事务的开启
- begin;
- start transaction;
在数据库中执行SQL语句之间加上这两条（之一）标志事务开启
9.2 标准事务语句
begin; ---事务开始
DML语句（delete，insert，update） ---事务事宜
rollback;/commit; ---事务结束
9.3 事务的结束
1. rollback;（回滚数据）
回滚操作，取消事务操作，反悔上诉的DML语句，之前执行的事务都不生效，
断电或突然退出，默认都是回滚
2. commit;（提交数据）
提交，事务操作事宜完成后进行此操作代表着此事务的完成，提交过的事务不可以再回滚
9.4 自动提交功能
1. select @@autocommit;
显示事务是否自动提交，若为1则为自动提交，0则为手动提交。意思是默认不写begin，
直接写一条DML语句，回车之后则进行了提交。手动提交则需要加commit才行
（提示：最好设置为手动，有些业务应用，防止误操作）
2. 临时修改提交形式
1. set autocommit=0; #（回话级别）
2. set global autocommit=0; #（全局级别）
自动提交是否打开取决于具体业务，但是一般在有事务需求的MySQL中都将其关闭。不管有没有事务需求，
都建议设置为0，可以很大程度上提高数据库性能，也能防止误操作。
3. 配置文件永久修改
--- vim /etc/my.cnf
[mysqld]
autocommit=0
9.5 隐式提交的语句
9.5.1 用于隐式提交的SQL语句
1. 例一：
begin; #事务开头
a; #DML语句1
b; #DML语句2
begin; #再次事务开头
---在事务开头执行后，继续执行事务事宜，之后突然再次进行事务开头，此时会进行隐式提交
2. 例二：
begin;
a;
b;
set autocommit=1;
--- 再执行事务开头后，继续执行事务项，之后进行了set语句也会隐式提交
9.5.2 导致提交的非事务语句
- DDL语句：alter，create，drop
- DCL语句：grant，revoke，set password
- 锁定语句：lock tables，unlock tables
十. InnoDB事务的ACID如何保证
10.1 一些概念
1. redo log---（磁盘）
---重做日志，记录数据页变化，像ib_logfile0~N，都是重做事务日志
2. redo log buffer---（内存）
---是redo log在内存部分的缓冲区
3. ibd---（磁盘）
---表空间的数据文件，以段区页的方式规划存储的数据和索引
4. innodb_buffer_pool---（内存）
---数据页的缓冲区（数据与索引的缓冲区）是数据库中最大的缓冲区
5. LSN：log seq no
---日志序列号，redo log，redo log buffer，ibd，innodb_buffer_pool中都有
6. WAL：write ahead log
---日志优先写的方式实现持久化（对应redo log buffer（内存）向redo log（磁盘）刷写的过程）
7. 脏页：dirty page
---内存脏页，内存中发生的修改没有写入磁盘之前，把内存页的数据页称为脏页
（对应从磁盘ibd中提取的数据页到内存的innodb_buffer_pool中进行修改的过程）
8. CKPT：checkpoint
---检查点，就是将脏页刷写到磁盘的动作
（对应将内存中innodb_buffer_pool中修改的数据页写入磁盘ibd的过程）
9. TXID：transaction id
---事务号，innodb会为每一个事物生成一个事务号，伴随整个事务
image.png
10.2 redo具体介绍
10.2.1 redo简介
重做日志，是事务日志的一种，位置一般在iblogfile0 iblogfile1
10.2.2 redo功能
1. redo的buffer:记录数据页的变化信息+数据页当时的LSN号
2. 主要保证ACID中“D”的持久化功能，对于AC也有保证
3. redo的刷新策略（commit;），刷新当前事务的redo buffer到磁盘，还会顺便将一部分redo buffer
中没有提交的事务日志也刷新到磁盘。加快commit命令速度，提高事务并发
4. 并且实现了MySQL Crash异常宕机时，ACSR中前滚的功能
10.2.3 redo事务分析
MySQL : 在启动时,必须保证redo日志文件和数据文件LSN必须一致, 如果不一致就会触发CSR,最终保证一致
情况一:
我们做了一个事务,begin;update;commit.
1.在begin ,会立即分配一个TXID=tx_01.
2.update时,会将需要修改的数据页(dp_01,LSN=101),加载到data buffer中
3.DBWR线程,会进行dp_01数据页修改更新,并更新LSN=102
4.LOGBWR日志写线程,会将dp_01数据页的变化+LSN+TXID存储到redobuffer
5. 执行commit时,LGWR日志写线程会将redobuffer信息写入redolog日志文件中,基于WAL原则,
在日志完全写入磁盘后,commit命令才执行成功,(会将此日志打上commit标记)
6.假如此时宕机,内存脏页没有来得及写入磁盘,内存数据全部丢失
7.MySQL再次重启时,必须要redolog和磁盘数据页的LSN是一致的.但是,此时dp_01,TXID=tx_01磁盘是LSN=101,dp_01,TXID=tx_01,redolog中LSN=102
MySQL此时无法正常启动,MySQL触发CSR.在内存追平LSN号,触发ckpt,将内存数据页更新到磁盘,从而保证磁盘数据页和redolog LSN一值.这时MySQL正长启动
以上的工作过程,我们把它称之为基于REDO的"前滚操作"
10.3 undo具体介绍
10.3.1 undo简介
回滚日志，位置在ibdata1文件，8.0版本undo单独存储，记录着一些逆操作
10.3.2 undo功能
1. 在事务ACID过程中，实现的是“A” 原子性的作用,另外CI也依赖于Undo
2. 在rolback时,将数据恢复到修改之前的状态
3. 在CSR实现的是,将redo当中记录的未提交的时候进行回滚.
4. undo提供快照技术,保存事务修改之前的数据状态.保证了MVCC,隔离性,mysqldump的热备
10.3.3 undo事务分析（暂略）
十一. 隔离级别（transaction_isolation）
11.1 事务的并发问题
1. 脏读
脏读是指一个事务正在访问数据时对此数据进行了修改，但是这种修改并没有提交到数据库落盘。这时，另一个事务也访问了这个数据，而他读取到的是前一个事务更改后的数据。对此，前一个事务由于某种原因对数据修改进行了回滚，此时第二个事务访问到的就是脏数据，它进行了依次脏读
2. 不可重复度
A事务对同一数据进行多次访问，此时A事务还没有结束，而B事务在A事务两次访问之间对这一数据进行了修改，这就导致A事务对于同一事物访问获取到的数据时不一样的，这种现象称为不可重复度，因为B事务对数据修改进行了提交
3. 幻读
A，B两事务访问同一数据,A事务对于这一事务进行了范围修改。B事务在A事务的修改范围内插入一条新数据，此时进行提交A事务与B事务。此时，再次查看这一修改过的数据，发现修改后的只有在元数据的基础上进行了修改，而对于新插入的数据并没有任何影响，也就是说，修改内容只影响修改之前的元数据，而对于之后插入的数据并没有影响
11.2 隔离级别的功能
1. 负责的是,MVCC,读一致性问题.主要提供了ACID中“I”隔离性的功能，对C一致性也有影响
2. 影响到数据的读取,默认的级别是 RR模式.
3. 控制的是数据读的机制，数据物理层面的隔离机制，任何数据的增删改查都会受隔离级别影响
11.3 MySQL 事务隔离级别
事务隔离级别 脏读 不可重复读 幻读
RU模式（read-uncommitted）：读未提交 是 是 是
RC模式（read-committed）：读已提交 否 是 是
RR模式（repeatable-read）：不可重复读 否 否 是
SR模式（serializable）：串行化 否 否 否
补充：RR模式优化
- 利用undo的快照技术防止不可重复读现象
- 利用GAP（间隙锁）+Netlock（下一键锁）防止幻读现象
11.4 隔离级别查询与修改
1. 隔离级别查询
select @@tx_isolation;
select @@transaction_isolation;
show variables like '%tx%';
2. 隔离级别修改
vim /etc/my.cnf
[mysqld]
transaction_isolation=REPEATABLE-READ
十二. InonoDB引擎的锁
12.1 锁的作用
在事务ACID过程中，“锁”和“隔离级别”一起来实现“I”隔离性和"C" 一致性 (redo也有参与)
12.2 锁的介绍
1. Record Locks：记录锁，行级锁
这一锁总会去锁定主键，非空的唯一性索引对应的索引记录。若在创建innodb表时没有创建任何索引，innobd会对6字节的rowid的主键进行锁定（这个是默认的），一般RU级别都是用此方式进行加锁。行级锁的作用是防止不同事物版本的数据修改提交时造成的数据冲突情况（也就是说对于统一数据不能进行同时进行，一个事务完成之后才能开启另一个事务）
2. Gap locks:间隙锁
间隙锁只存在于RR隔离级别下的辅助索引中，只锁定一个范围，不包含记录本身。记录锁避免了别的事务插入数据，从而避免了不可重复读现象。
3. Next-key lock：下一键锁
此锁使用也应用于RR隔离级别下，相当于上述两锁的结合，形成了一个带有闭合区间的一个范围锁定。此锁解决了RR隔离级别下的幻读现象
十三. InnoDB引擎核心参数介绍
13.1 default_storage_engine：默认存储引擎
1. 查看方式：
- show engines;
- show variables like 'default_storage_engine';
- select @@default_storage_engine;
2. 修改方式：
(1) 通过参数设置默认引擎
(2) 建表的时候进行设置
(3) alter table t1 engine=innodb;
3. 补充：
- MySQL的5.5版本之后默认存储引擎为InnoDB
- Percona数据库默认为XtraDB
- MariaDB数据库默认为InnoDB（与mysql不同），隶属MySQL TokDB
13.2 表空间
1. 共享表空间：innodb_data_file_path
- innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend（一般是在初始化数据之前就设置好）
2. 独立表空间：innodb_file_per_table
- set global innodb_file_per_table=0；
13.3 缓冲区池：innodb_buffer_pool_size
1. 此参数指缓冲区池的大小，占用空间
2. 在配置文件（/etc/my.cnf）修改，innodb_buffer_pool_size=具体大小
3. 官方建议最多95%，生成建议不超80% ，一般在50%---70%。业务够用即可，公司硬件要有预留，MySQL还可能用额外的内存结构或者公司做的多实例都会影响。
4. show engine innodb status\G;
13.4 innodb_flush_log_at_trx_commit (双一标准之一)
1. 作用：
- 主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点，取值分别为0、1、2三个
2. 查询：
- select @@innodb_flush_log_at_trx_commit;
3. 数字“1”代表在提交事务时，数据在内存的redo log buffer立即写入OS buffer（cache）中，然后
再立即写入redo log磁盘中
4. 数字“0”代表在提交事务时，数据在内存的redo log buffer每秒写入OS buffer（cache）中，然后
再每秒写入redo log磁盘中
5. 数字“2”代表在提交事务时，数据在内存的redo log buffer立即写入OS buffer（cache）中，然后
再每秒写入redo log磁盘中
13.5 Innodb_flush_method=(O_DIRECT, fsync,O_DSYNC)
image.png
1. 参数作用：
- 控制InnoDB_buffer_pool向ibd（CKPT）动作的刷盘策略和redo_log_buffer向redo_log（提交时）
动作的刷盘策略（控制的是,log buffer 和data buffer,刷写磁盘的时候是否经过文件系统缓存）
2. 查询方式：
- show variables like '%innodb_flush%';
3. 配置建议（/etc/my.cnf）
最高安全模式
innodb_flush_log_at_trx_commit=1
Innodb_flush_method=O_DIRECT
最高性能:
innodb_flush_log_at_trx_commit=0
Innodb_flush_method=fsync
4. 参数值说明：
（1）：O_DIRECT :
数据缓冲区写磁盘,不走OS buffer（innodb_buffer_pool----->ibd）
日志则先走OS buffer再到磁盘（innodb_log_buffer---->OS buffer---->redo log）
（2）fsync :
日志和数据缓冲区写磁盘,都走OS buffer，在刷磁盘
（innodb_buffer_pool----->ibd）
（innodb_log_buffer---->redo log）
（3）O_DSYNC :
日志缓冲区写磁盘,不走 OS buffer，直接到磁盘
（innodb_log_buffer---->redo log）
数据缓冲去先走OS buffer再到磁盘
（innodb_buffer_pool---->OS buffer---->ibd）
13.6 redo日志有关的参数
1. innodb_log_buffer_size=16777216
---指内存中innodb_log_buffer(redo_log_buffer)的占用空间
---select @@innodb_log_buffer_size;
---配置文件（/etc/my.cnf）进行查看
2. innodb_log_file_size=50331648/innodb_log_files_in_group = 3r
---指磁盘中innodb_log（redo log）文件占用的空间以及有几个这样的文件（ib_logfile0~1）
---show variables like '%innodb_log_file%';查看