1.简介

相当于Linux文件系统，只不过比文件系统强大

2.功能

数据读写
数据安全和一致性
提高性能
热备份
自动故障恢复
高可用方面支持
等.

3. 存储引擎

3.1 (orcle mysql)存储引擎种类

InonDB
MylSAM
CSV
BLACKHOLE
MEMORY

3.2 引擎查看方法

show engines;
注: 存储引擎是作用在表上的,也就意味着,不同的表可以用不同的引擎类型.
perconaDB :默认xtradb
MariaDB : 默认 Innodb
其他引擎:
tokudb
rocksdb
myrocks
注: 以上3中存储引擎的共同特点: 压缩比较高 ,数据插入性能极高
现在很多的newsql,使用比较多的功能特性
select @@default_storage_engine;  #查看数据库的默认引擎
show table status;   #查看所在的库里所有表的状态的存储引擎

3.3 引擎修改方法

修改当前会话窗口的默认引擎(重启失效)      set default_storage_engine=myisam; 
全局变量,但之影响新建会话,对本会话不起作用 (重启失效)    ste   global   default_storage_engine=myisam;
永久生效:    vim /etc/my.cnf
[mysqld]
dafault_storage_engine=myisam

3.3.1 修改一个表的存储引擎

alter table t1 engine innodb;
注意：此命令我们经常使用他，可以进行innodb表的碎片整理
在进行修改或整理时会锁表(DDL)

4. innodb存储引擎物理存储结构

ibdata1：系统数据字典信息(统计信息)，UNDO表空间等数据
ib_logfile0 ~ ib_logfile1: REDO日志文件，事务日志文件。
ibtmp1：临时表空间磁盘位置，存储临时表
frm：存储表的列信息
ibd：表的数据行和索引

4.1 表空间(Tablespace)

4.1.1 共享表空间

将所有的数据储存到同一个表空间中,但管理起来比较混乱
5.6版只用于存储:数据字典信息,undo,和临时表.
5.7版只用于存储:数据字典信息和undo.
8.0版只用于存储:数据字典信息,

4.1.2 共享表空间设置

共享表空间设置(在搭建MySQL时，初始化数据之前设置到参数文件中)
[(none)]>select @@innodb_data_file_path; #查看ibdata1大小
[(none)]>show variables like '%extend%'; #ibdata1每次增长的大小
innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend #初始化数据库时设置2个每个512m大小
innodb_autoextend_increment=64

4.1.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操作产生临时数据，用完就自动删除

4.1.4 独立表空间管理

alter table 表名 discard tablespace;
# 删除当前表的.ibd文件
alter table 表名 import tablespace;
#把复制过来的.ibd文件导入到表中,

set foreign_key_checks=0 跳过外键检查。

5. innodb (事务)

5.1 事务的ACID特性

5.1.1Atomic（原子性)

所有语句作为一个单元全部成功执行或全部取消。不能出现中间状态。

5.1.2 Consistent（一致性)

如果数据库在事务开始时处于一致状态，则在执行该事务期间将保留一致状态。

5.1.3 Isolated（隔离性)

事务之间不相互影响. (锁)

5.1.4 Durable（持久性)

事务成功完成后，所做的所有更改都会准确地记录在数据库中。所做的更改不会丢失。

5.2事务的生命周期

5.2.1 事务的开始

DDL DCL 每一句都是一个事务
DML语句以begin 开始的(5.5以上版本,只要执行DML,就会自动在前面添加一个begin 命令)

5.2.2 事务结束

commit: 提交事务
完成一个事务,一旦事务提交成功,就说明具备ACID的特性了
rollback:回滚事务
将内存中,已经执行过的操作,回滚回去

5.2.3 查看事务策略

select @@autocommit;  (默认是开启的)
1   自动提交功能是开启的  (每执行一条语句就提交一次commit)
0   自动提交功能是关闭的
注：
自动提交是否打开，一般在有事务需求的MySQL中，将其关闭
不管有没有事务需求，我们一般也都建议设置为0，可以很大程度上提高数据库性能
(1)临时关闭(重启后失效)
set autocommit=0;     #当前窗口关闭
set global autocommit=0;  #之后开启的窗口关闭
(2)  永久关闭(重启后生效)
vim /etc/my.cnf
autocommit=0

5.2.4 隐式提交语句

用于隐式提交的 SQL 语句：
begin 
a
b
begin

set autocomit =1 

导致提交的非事务语句：
DDL语句:  (alter create 和 drop)
DCL语句:  (grant revoke 和 set password)
锁定语句:  (lock  tables  和  unlock  tables)
导致隐式提交的语句
truncate   table
load data infile
select for update

5.2.5 开始事务流程

1、检查autocommit是否为关闭状态
select @@autocommit;
或者：
show variables like 'autocommit';
2、开启事务,并结束事务
begin
delete from student where name='alexsb';
update student set name='alexsb' where name='alex';
rollback;

begin
delete from student where name='alexsb';
update student set name='alexsb' where name='alex';
commit;

6 InnoDB 事务的ACID保证

1.) redo log ---> 重做日志
         ib_logfile0~1   默认48M   , 轮询使用    
        在事务ACID过程中，实现的是“D”持久化的作用。对于AC也有相应的作用
2.) redo log buffer ---> redo内存区域
        redo的buffer主要记录数据页的变化信息+数据页当时的LSN号
         LSN : 日志序列号  (磁盘数据页,redo文件,buffer pool,redo buffer)

3.) ibd     ----> 存储 数据行和索引 
4.) buffer pool --->缓冲区池,数据和索引的缓冲
5.) MySQL 每次数据库启动,都会比较磁盘数据页和redolog的LSN,必须要求两者LSN一致数据库才能正常启动
6.) WAL : write ahead log 日志优先写的方式实现持久化
7.) 脏页: 内存脏页,内存中发生了修改,没写入到磁盘之前,我们把内存页称之为脏页.
8.) CKPT:Checkpoint,检查点,就是将脏页刷写到磁盘的动作
9.) TXID: 事务号,InnoDB会为每一个事务生成一个事务号,伴随着整个事务.

6.1 redo的刷新策略

commit;
刷新当前事务的redo buffer到磁盘
还会顺便将一部分redo buffer中没有提交的事务日志也刷新到磁盘

6.2 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的"前滚操作"

6.3 undo 回滚日志

在事务ACID过程中，实现的是“A” 原子性的作用
另外CI也依赖于Undo
在rolback时,将数据恢复到修改之前的状态
在CSR实现的是,将redo当中记录的未提交的时候进行回滚.
undo提供快照技术,保存事务修改之前的数据状态.保证了MVCC,隔离性,mysqldump的热备

7 锁

锁”顾名思义就是锁定的意思。
“锁”的作用是什么？
在事务ACID过程中，“锁”和“隔离级别”一起来实现“I”隔离性和"C" 一致性 (redo也有参与).
悲观锁:行级锁定(行锁)
谁先操作某个数据行,就会持有<这行>的(X)锁.
乐观锁: 没有锁

image.png

7.1 InnoDB行锁实现方式

InnoDB行锁是通过索引上的索引项来实现的，这一点ＭySQL与Oracle不同，后者是通过在数据中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味者：只有通过索引条件检索数据，InnoDB才会使用行级锁，否则，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。

8. 隔离级别

影响到数据的读取,默认的级别是 RR模式.
transaction_isolation   隔离级别(参数)
负责的是,MVCC,读一致性问题
RU  （Read uncommitted): 读未提交,可脏读,一般部议叙出现
RC  (Read committed): 读已提交,可能出现幻读,可以防止脏读.
RR  （Repeatable read): 可重复读,功能是防止"幻读"现象 ,利用的是undo的快照技术+GAP(间隙锁)+NextLock(下键锁)
SR   （Serializable): 可串行化,可以防止死锁,但是并发事务性能较差
补充: 在RC级别下,可以减轻GAP+NextLock锁的问题,但是会出现幻读现象,一般在为了读一致性会在正常select后添加for update语句.但是,请记住执行完一定要commit 否则容易出现所等待比较严重.
例如:
[world]>select * from city where id=999 for update;(防止出现幻读)
[world]>commit;

9. 缓冲区池

select @@innodb_buffer_pool_size;
show engine innodb status\G
看 innodb_buffer_pool_size 
一般建议最多是物理内存的 75-80%

10. innodb_flush_log_at_trx_commit (双一标准之一)

主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点，可设置为0、1、2。

10.1 查询

select @@innodb_flush_log_at_trx_commit;

10.2 参数说明

1，每次事物的提交都会引起日志文件写入、flush磁盘的操作，确保了事务的ACID；flush 到操作系统的文件系统缓存 fsync到物理磁盘.
0，表示当事务提交时，不做日志写入操作，而是每秒钟将log buffer中的数据写入文件系统缓存并且秒fsync磁盘一次；
2，每次事务提交引起写入文件系统缓存,但每秒钟完成一次fsync磁盘操作。

11. Innodb_flush_method=

log buffer 和data buffer,刷写磁盘的时候是否经过文件系统缓存

11.1 查看状态

show variables like '%innodb_flush%';

11.2 常用参数

fsync :日志和数据缓冲区写磁盘,都走OS buffer
O_DSYNC  :日志缓冲区写磁盘,不走 OS buffer
O_DIRECT  :数据缓冲区写磁盘,不走OS buffer

image.png

11.3 使用模式

最高安全模式
innodb_flush_log_at_trx_commit=1
Innodb_flush_method=O_DIRECT
最高性能:
innodb_flush_log_at_trx_commit=0
Innodb_flush_method=fsync

11.4 redo日志有关的参数

innodb_log_buffer_size=16777216    #redo内存大小
innodb_log_file_size=50331648    #redo 文件大小
innodb_log_files_in_group = 3     #redo 文件个数

mariadb tokudb引擎安装

1.)更新mariadb源
vim /etc/yum.repos.d/MariaDB.repo(我系统安装的是mariadb10.4)
`#` MariaDB 10.4 CentOS repository list - created 2019-06-08 13:17 UTC `#`  [http://downloads.mariadb.org/mariadb/repositories/](http://downloads.mariadb.org/mariadb/repositories/) [mariadb] name = MariaDB baseurl = [http://yum.mariadb.org/10.4/centos7-amd64](http://yum.mariadb.org/10.4/centos7-amd64) gpgkey=[https://yum.mariadb.org/RPM-GPG-KEY-MariaDB](https://yum.mariadb.org/RPM-GPG-KEY-MariaDB) gpgcheck=1

2.) 下载tokudb存储引擎
yum install MariaDB-tokudb-engine

3.)检查Transparent Hugepages的状态：
cat /sys/kernel/mm/transparent_hugepage/enabled
如果路径不存在，则没有启用“透明大小页”，您可以继续。
或者，将返回以下内容：
always madvise [never]
指示透明Hugepages未启用，您可以继续。

如果返回以下内容：
[always] madvise never
则透明Hugepages已启用，您需要禁用它们。

临时关闭：
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

 永久关闭：
在 /etc/default/grub文件中添加 GRUB_CMDLINE_LINUX_DEFAULT="transparent_hugepage=never"

更新grub（引导加载程序）：
grub2-mkconfig -o /boot/grub2/grub.cfg

锁

https://www.cnblogs.com/chenqionghe/p/4845693.html

存储引擎

1.简介

2.功能

3. 存储引擎

3.1 (orcle mysql)存储引擎种类

3.2 引擎查看方法

3.3 引擎修改方法

3.3.1 修改一个表的存储引擎

4. innodb存储引擎物理存储结构

4.1 表空间(Tablespace)

4.1.1 共享表空间

4.1.2 共享表空间设置

4.1.3 独立表空间

4.1.4 独立表空间管理

5. innodb (事务)

5.1 事务的ACID特性

5.1.1Atomic（原子性)

5.1.2 Consistent（一致性)

5.1.3 Isolated（隔离性)

5.1.4 Durable（持久性)

5.2事务的生命周期

5.2.1 事务的开始

5.2.2 事务结束

5.2.3 查看事务策略

5.2.4 隐式提交语句

5.2.5 开始事务流程

6 InnoDB 事务的ACID保证

6.1 redo的刷新策略

6.2 MySQL CSR——前滚

6.3 undo 回滚日志

7 锁

7.1 InnoDB行锁实现方式

8. 隔离级别

9. 缓冲区池

10. innodb_flush_log_at_trx_commit (双一标准之一)

10.1 查询

10.2 参数说明

11. Innodb_flush_method=

11.1 查看状态

11.2 常用参数

11.3 使用模式

11.4 redo日志有关的参数

mariadb tokudb引擎安装

锁

你可能感兴趣的:(存储引擎)