1、简介
相当于linux文件系统，比文件系统强大
2、存储引擎种类
主要就是INNODB和MYISAM
show engines;
存储引擎是作用在表上的，也就意味着，不同的表可以有不同的存储引擎类型。
PerconaDB:默认是XtraDB
MariaDB:默认是InnoDB
其他的存储引擎支持:
TokuDB
RocksDB
MyRocks
以上三种存储引擎的共同点:压缩比较高,数据插入性能极高
现在很多的NewSQL,使用比较多的功能特性.
3、innodb和myisam区别
事务（Transaction）
MVCC（Multi-Version Concurrency Control多版本并发控制）
行级锁(Row-level Lock)
ACSR（Auto Crash Safey Recovery）自动的故障安全恢复
支持热备份(Hot Backup)
Replication: Group Commit , GTID (Global Transaction ID) ,多线程(Multi-Threads-SQL )
4、存储引擎查看和设置
SELECT @@default_storage_engine;
会话级别:
set default_storage_engine=myisam;
全局级别(仅影响新会话):
set global default_storage_engine=myisam;
写入配置文件
[mysqld]
default_storage_engine=myisam
存储引擎是表级别的,每个表创建时可以指定不同的存储引擎,但是我们建议统一为innodb
(1)查看表的存储引擎
SHOW CREATE TABLE City\G;
SHOW TABLE STATUS LIKE 'test1'\G
(2)INFORMATION_SCHEMA 确认每个表的存储引擎
[world]>select table_schema,table_name ,engine from information_schema.tables where table_schema not in ('sys','mysql','information_schema','performance_schema');
(3)修改一个表的存储引擎
alter table t1 engine innodb; #可以多次执行，可以进行innodb表的碎片整理
(4)如何批量修改
需求:将qingchen库中的所有表,innodb替换为tokudb
select concat("alter table qingchen.",table_name," engine tokudb;") from
information_schema.tables where table_schema='qingchen' into outfile '/tmp/qingchen.sql';
5、InnoDB存储引擎物理存储结构
ibdata1：系统数据字典信息(统计信息)，UNDO表空间等数据
ib_logfile0 ~ ib_logfile1: REDO日志文件，事务日志文件。
ibtmp1： 临时表空间磁盘位置，存储临时表
frm：存储表的列信息
ibd：表的数据行和索引
(1)表空间(Tablespace)--共享表空间
需要将所有数据存储到同一个表空间中 ，管理比较混乱
5.5版本出现的管理模式，也是默认的管理模式。
5.6版本以，共享表空间保留，只用来存储:数据字典信息,undo,临时表。
5.7 版本,临时表被独立出来了
8.0版本,undo也被独立出去了
共享表空间设置(在搭建MySQL时，初始化数据之前设置到参数文件中)
select @@innodb_data_file_path;
show variables like '%extend%';
可以写进配置文件
innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend
innodb_autoextend_increment=64
(2)独立表空间
从5.6，默认表空间不再使用共享表空间，替换为独立表空间。
主要存储的是用户数据
存储特点为：一个表一个ibd文件，存储数据行和索引信息
基本表结构元数据存储：
元数据 数据行+索引
mysql表数据 =（ibdataX+frm）+ibd(段、区、页)
MySQL的存储引擎日志：
Redo Log: ib_logfile0 ib_logfile1，重做日志
Undo Log: ibdata1 ibdata2(存储在共享表空间中)，回滚日志
临时表:ibtmp1，在做join union操作产生临时数据，用完就自动
独立表空间设置
select @@innodb_file_per_table;
如果改为0，则后续创建的表会使用共享表空间
6、mysql无法启动，根据data目录的ibd数据加全表表结构，恢复数据
(1)创建和原来一模一样的表
(2)新表表空间删除
select concat('alter table ',table_schema,'.',table_name,' discard tablespace;') from information_schema.tables where table_schema='qingchen' into outfile '/tmp/discard.sql';
source /tmp/discard.sql
set foreign_key_checks=0 跳过外键检查。
(3)拷贝旧环境所有表的ibd文件拷贝到准备好的环境中
select concat('alter table ',table_schema,'.',table_name,' import tablespace;') from information_schema.tables where table_schema='qingchen' into outfile '/tmp/import.sql';
source /tmp/import.sql
(4)验证数据
7、事务的ACID特性
Atomic（原子性）
所有语句作为一个单元全部成功执行或全部取消。不能出现中间状态。
Consistent（一致性）
如果数据库在事务开始时处于一致状态，则在执行该事务期间将保留一致状态。
Isolated（隔离性）
事务之间不相互影响。
Durable（持久性）
事务成功完成后，所做的所有更改都会准确地记录在数据库中。所做的更改不会丢失。
8、事务的生命周期（事务控制语句）
(1)事务的开始
begin
说明:在5.5 以上的版本，不需要手工begin，只要你执行的是一个DML，会自动在前面加一个begin命令。
(2)事务的结束
commit：提交事务
完成一个事务，一旦事务提交成功 ，就说明具备ACID特性了。
rollback ：回滚事务
将内存中，已执行过的操作，回滚回去
(3)自动提交策略（autocommit）
select @@autocommit;
set autocommit=0;
set global autocommit=0;
自动提交是否打开，一般在有事务需求的MySQL中，将其关闭
不管有没有事务需求，我们一般也都建议设置为0，可以很大程度上提高数据库性能
set autocommit=0;
set global autocommit=0;
写进配置文件
[mysqld]
autocommit=0
(4)隐式提交语句
用于隐式提交的 SQL 语句：
begin
a
b
begin
(5)导致提交的非事务语句：
DDL语句： （ALTER、CREATE 和 DROP）
DCL语句： （GRANT、REVOKE 和 SET PASSWORD）
锁定语句：（LOCK TABLES 和 UNLOCK TABLES）
导致隐式提交的语句示例：
TRUNCATE TABLE
LOAD DATA INFILE
SELECT FOR UPDATE
9、InnoDB 事务的ACID如何保证
redo log ---> 重做日志 ib_logfile0~1 50M , 轮询使用
redo log buffer ---> redo内存区域
ibd ----> 存储 数据行和索引
buffer pool --->缓冲区池,数据和索引的缓冲
LSN : 日志序列号
磁盘数据页,redo文件,buffer pool,redo buffer
MySQL 每次数据库启动,都会比较磁盘数据页和redolog的LSN,必须要求两者LSN一致数据库才能正常启动
WAL : write ahead log 日志优先写的方式实现持久化
脏页: 内存脏页,内存中发生了修改,没写入到磁盘之前,我们把内存页称之为脏页.
CKPT:Checkpoint,检查点,就是将脏页刷写到磁盘的动作
TXID: 事务号,InnoDB会为每一个事务生成一个事务号,伴随着整个事务.
(1)redo log
redo,顾名思义“重做日志”，是事务日志的一种。
在事务ACID过程中，实现的是“D”持久化的作用。对于AC也有相应的作用
redo的日志文件：iblogfile0 iblogfile1
(2)redo buffer
redo的buffer:数据页的变化信息+数据页当时的LSN号
LSN：日志序列号 磁盘数据页、内存数据页、redo buffer、redolog
(3)redo的刷新策略
commit;
刷新当前事务的redo buffer到磁盘
还会顺便将一部分redo buffer中没有提交的事务日志也刷新到磁盘
(4)MySQL CSR——前滚
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的"前滚操作"
(5)undo 回滚日志
undo,顾名思义“回滚日志”
在事务ACID过程中，实现的是“A” 原子性的作用，另外CI也依赖于Undo
在rolback时,将数据恢复到修改之前的状态
在CSR实现的是,将redo当中记录的未提交的时候进行回滚.
undo提供快照技术,保存事务修改之前的数据状态.保证了MVCC,隔离性,mysqldump的热备
10、锁
在事务ACID过程中，“锁”和“隔离级别”一起来实现“I”隔离性和"C" 一致性 (redo也有参与).
悲观锁:行级锁定(行锁)
谁先操作某个数据行,就会持有<这行>的(X)锁.
乐观锁: 没有锁
11、隔离级别
影响到数据的读取,默认的级别是 RR模式.
transaction_isolation 隔离级别(参数)
配置
[mysqld]
transaction_isolation=repeatable-read
负责的是,MVCC,读一致性问题
RU(read-uncommitted) : 读未提交,可脏读,一般部议叙出现
RC(read-committed) : 读已提交,可能出现幻读,可以防止脏读.
RR(repeatable-read) : 可重复读,功能是防止"幻读"现象 ,利用的是undo的快照技术+GAP(间隙锁)+NextLock(下键锁)
SR(serializable) : 可串行化,可以防止死锁,但是并发事务性能较差
补充: 在RC级别下,可以减轻GAP+NextLock锁的问题,但是会出现幻读现象,一般在为了读一致性会在正常select后添加for update语句.但是,请记住执行完一定要commit 否则容易出现所等待比较严重.
例如:
select * from city where id=999 for update;
commit;
12、InnoDB存储引擎核心特性
(1)查看存储引擎
show engines;
show variables like 'default_storage_engine';
select @@default_storage_engine;
(2)如何指定和修改存储引擎
通过参数设置默认引擎
建表的时候进行设置
alter table t1 engine=innodb;
(3)共享表空间
innodb_data_file_path
一般是在初始化数据之前就设置好
例子:
innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend
(4)独立表空间
show variables like 'innodb_file_per_table';
(5)缓冲区池
select @@innodb_buffer_pool_size;
show engine innodb status\G
innodb_buffer_pool_size
一般建议最多是物理内存的 75-80%
(6)innodb_flush_log_at_trx_commit (双一标准之一)
主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点，取值分别为0、1、2三个。
select @@innodb_flush_log_at_trx_commit;
1，每次事物的提交都会引起日志文件写入、flush磁盘的操作，确保了事务的ACID；flush 到操作系统的文件系统缓存 fsync到物理磁盘.
0，表示当事务提交时，不做日志写入操作，而是每秒钟将log buffer中的数据写入文件系统缓存并且秒fsync磁盘一次；
2，每次事务提交引起写入文件系统缓存,但每秒钟完成一次fsync磁盘操作。
(7)Innodb_flush_method=(O_DIRECT,,fdatasync,O_DSYNC)
控制的是,log buffer 和data buffer,刷写磁盘的时候是否经过文件系统缓存
show variables like '%innodb_flush%';
O_DIRECT :数据缓冲区写磁盘,不走OS buffer
fsync :日志和数据缓冲区写磁盘,都走OS buffer
O_DSYNC :日志缓冲区写磁盘,不走OS buffer
最高安全模式
innodb_flush_log_at_trx_commit=1
Innodb_flush_method=O_DIRECT
最高性能:
innodb_flush_log_at_trx_commit=0
Innodb_flush_method=fsync
(8)redo日志有关的参数
innodb_log_buffer_size=16777216
innodb_log_file_size=50331648
innodb_log_files_in_group = 3
