MySQL存储引擎的核心特性
欢迎来到 来到大浪涛天的博客 !
一、MySQL存储引擎的核心特性
1. MySQL存储引擎介绍与分类
- MySQL相当于Linux文件系统,比文件系统强大且复杂
- MySQL的功能介绍:
- 数据读写
- 数据安全和一致性
- 提高性能
- 热备份
- 自动故障恢复
- 高可用方面支持等.
- MySQL的存储引擎类似于插入式的,支持多种引擎,有点像linux文件系统可以将磁盘格式化为ext或者xfs文件系统一样,不过数据库是以表空间来设置使用哪种引擎来操作存储。
- CSV
- MRG_MYISAM
- MyISAM
- BLACKHOLE
- PERFORMANCE_SCHEMA
- MEMORY
- ARCHIVE
- InnoDB
- FEDERATED
- 各大版本的MySQL发行版本的默认引擎
MySQL:默认是InnoDB
PerconaDB:默认是XtraDB
MariaDB:默认是InnoDB - 第三方的存储引擎,压缩比较高,数据的插入性能高.其他功能和InnoDB没有大的差别,包含如下
- RocksDB
- MyRocks
- TokuDB
2. InnoDB 存储引擎核心特性说明
- 事务
- 行锁
- MVCC
- 外键
- ACSR自动故障恢复
- 热备
- 复制(多线程,GTID,MTS)
2-1. 查看存储引擎设置
2-2. 查看表存储引擎状态
2-3. 存储引擎的修改
mysql> alter table t111 engine=innodb;
mysql> show create table t111;
注意修改表的引擎同时会有清理碎片的功能,但是会有短时间锁表,建议凌晨数据量小的时候操作
mysql> alter table t111 engine=innodb;
2-4. 利用concat批量修改多个表的引擎
例如zabbix库 100多张表的引擎为 innodb需要批量修改为tokudb:
alter table zabbix.a engine=tokudb;
select concat("alter table ",table_schema,".",table_name," engine=tokudb;") from information_schema.tables
where table_schema='zabbix';
2-5. InnoDB存储引擎物理存储结构
最直观的存储方式(/data/mysql/data)
ibdata1:系统数据字典信息(统计信息),UNDO表空间等数据
ib_logfile0 ~ ib_logfile1: REDO日志文件,事务日志文件。
ibtmp1: 临时表空间磁盘位置,存储临时表
frm:存储表的列信息
ibd:表的数据行和索引
2-5-1. 表空间(Tablespace)
2-5-1-1. 表空间数据问题
ibdata1 : 整个库的统计信息+Undo
ibd : 数据行和索引
2-5-1-2. 共享表空间(ibdata1~N)
1. 5.5 版本的默认模式,5.6中转换为了独立表空间
需要将所有数据存储到同一个表空间中 ,管理比较混乱
2. 5.5版本出现的管理模式,也是默认的管理模式。
3. 5.6版本以,共享表空间保留,只用来存储:数据字典信息,undo,临时表。
4. 5.7 版本,临时表被独立出来了
5. 8.0版本,undo也被独立出去了
具体变化参考官方文档:
https://dev.mysql.com/doc/refman/5.6/en/innodb-architecture.html
https://dev.mysql.com/doc/refman/5.7/en/innodb-architecture.html
https://dev.mysql.com/doc/refman/5.8/en/innodb-architecture.html
2-5-1-3. 共享表空间设置(在搭建MySQL时,初始化数据之前设置到参数文件中)
[(none)]>select @@innodb_data_file_path;
[(none)]>show variables like '%extend%';
innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend
innodb_autoextend_increment=64
注意,设置的时候需要在初始化之前在/etc/my.cnf上添加如下设置,然后再进行初始化:
innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend
mysqld --initialize-insecure --user=mysql --basedir=xxxxxx......
2-5-1-4. 独立表空间
从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操作产生临时数据,用完就自动
2-5-1-5. 表空间的概述:
一张InnoDB表= frm+idb+ibdata1
MySQL的存储引擎日志:
Redo Log: ib_logfile0 ib_logfile1,重做日志
Undo Log: ibdata1 ibdata2(存储在共享表空间中),回滚日志
临时表:ibtmp1,在做join union操作产生临时数据,用完就自动清理
2-5-1-6. 独立表空间设置问题
mysql> select @@innodb_file_per_table;
+-------------------------+
| @@innodb_file_per_table |
+-------------------------+
| 1 |
+-------------------------+
1 row in set (0.00 sec)
2-5-1-6-1. 独立表空间迁移
(1)创建和原表结构一致的空表
(2)将空表的ibd文件删除
alter table city dicard tablespace;
(3)将原表的ibd拷贝过来,并且修改权限
(4)将原表ibd进行导入
alter table city import tablespace;
例如:在5.7.26版本的mysql(旧)中需要将test数据库中的t100w表迁移到另外一个(新)MySQL同版本的数据库中
1. 在旧的数据库中找到t100w的建表语句
mysql> show create table t100w;
2. 在新的的MySQL创建一个库以及原来相同的结构的表
mysql> CREATE TABLE `t100w` (... ...)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
3. 将空表中的ibd文件删除
mysql> alter table t100w discard tablespace;
4. 将原表的ibd文件拷贝过来,并注意权限
[root@test02 test01]# cp -a /data/3307/data/test01/t100w.ibd .
5. 将原表的ibd文件进行导入
mysql> alter table t100w import tablespace;
Query OK, 0 rows affected, 1 warning (0.72 sec)
mysql> select count(*) from t100w;
+----------+
| count(*) |
+----------+
| 1030345 |
+----------+
2-6. innodb的核心特性事务
2-6-1. 事务的ACID特性
A代表Atomic(原子性)
所有语句作为一个单元全部成功执行或全部取消。不能出现中间状态。
C代表Consistent(一致性)
如果数据库在事务开始时处于一致状态,则在执行该事务期间将保留一致状态。
I代表Isolated(隔离性)
事务之间不相互影响。
Durable(持久性)
事务成功完成后,所做的所有更改都会准确地记录在数据库中。所做的更改不会丢失。
2-6-2. 事务的生命周期(标准的事务控制语句)
2-6-2-1. 开启事务
开启事务一般执行begin,就开始一个事务,commit就提交一个事务,但是5.7版本的的begin可以省略
begin ;
2-6-2-2. 标准的事务语句
DML :
insert
update
delete
mysql> use world;
mysql> update city set countrycode='CHN' where id=1;
mysql> update city set countrycode='CHN' where id=2;
mysql> update city set countrycode='CHN' where id=3;
2-6-2-3. 事务的结束
提交:
commit;
回滚:
rollback;
2-6-2-4. 自动提交机制(autocommit)
5.7版本的MySQL会自动提交,但是这种往往容易出错,所以一般来说为们要把自动提交关闭。
mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
| 1 |
+--------------+
在线修改参数:
(1) 会话级别:
mysql> set autocommit=0;
及时生效,只影响当前登录会话
(2)全局级别:
mysql> set global autocommit=0;
断开窗口重连后生效,影响到所有新开的会话
永久修改(重启生效)
vim /etc/my.cnf
autocommit=0
2-6-2-5. 隐式提交的情况
触发隐式提交的语句:
begin
a
b
create database
导致提交的非事务语句:
DDL语句: (ALTER、CREATE 和 DROP)
DCL语句: (GRANT、REVOKE 和 SET PASSWORD)
锁定语句:(LOCK TABLES 和 UNLOCK TABLES)
导致隐式提交的语句示例:
TRUNCATE TABLE
LOAD DATA INFILE
SELECT FOR UPDATE
2-6-3. 事务的ACID如何保证?
我们做了一个事务,begin;update;commit。
- 在begin ,会立即分配一个TXID=tx_01.
- update时,会将需要修改的数据页(dp_01,LSN=101),加载到data buffer中
- DBWR线程,会进行dp_01数据页修改更新,并更新LSN=102
- LOGBWR日志写线程,会将dp_01数据页的变化+LSN+TXID存储到redobuffer
- 执行commit时,LGWR日志写线程会将redobuffer信息写入redolog日志文件中,基于WAL原则,在日志完全写入磁盘后,commit命令才执行成功,(会将此日志打上commit标记)
- 假如此时宕机,内存脏页没有来得及写入磁盘,内存数据全部丢失
- 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的"前滚操作"
2-6-3-1. ACID的概念及一些名称
1. redo log: 重做日志
ib_logfile0~1 默认50M , 轮询使用
2. redo log buffer :
redo内存区域,redo缓存
ibd :
存储 数据行和索引
3. data buffer pool :
缓冲区池,数据和索引的缓冲
4. LSN : 日志序列号 ,含有LSN的组件包含如下:
ibd ,redolog ,data buffer pool, redo buffer
MySQL 每次数据库启动,都会比较磁盘数据页和redolog的LSN,必须要求两者LSN一致数据库才能正常启动
4. WAL (持久化):
write ahead log 日志优先写的方式实现持久化
日志是优先于数据写入磁盘的.
5. 脏页:
内存脏页,内存中发生了修改,没写入到磁盘之前,我们把内存页称之为脏页.
6. CKPT:
Checkpoint,检查点,就是将脏页刷写到磁盘的动作
7. TXID:
事务号,InnoDB会为每一个事务生成一个事务号,伴随着整个事务.
2-6-3-2. 事务日志-- redo 重做日志
- redo重做日志主要功能是保证 D(持久性) , A(原子性) C(一致性)也有一定得作用
(1)记录了内存数据页的变化.
(2)提供快速的持久化功能(WAL)
(3)CSR过程中实现前滚的操作(磁盘数据页和redo日志LSN一致)
- redo日志位置
redo的日志文件:iblogfile0 iblogfile1
2-6-3-3. redo buffer
- redo的buffer的作用是记录数据页的变化信息+数据页当时的LSN号
- redo的刷写策略,执行了commit,刷新当前事务的redo buffer到磁盘,还会顺便将一部分redo buffer中没有提交的事务日志也刷新到磁盘
- MySQL : 在启动时,必须保证redo日志文件和数据文件LSN必须一致, 如果不一致就会触发CSR,最终保证一致
2-6-3-4. undo
回滚日志,作用: 在 ACID特性中,主要保证A(原子性)的特性,同时对C(一致性)I(隔离性)也有一定功效
(1)记录了数据修改之前的状态
(2)rollback 将内存的数据修改恢复到修改之前
(3)在CSR中实现未提交数据的回滚操作
(4)实现一致性快照,配合隔离级别保证MVCC,读和写的操作不会互相阻塞
2-6-3-5. 锁
实现了事务之间的隔离功能,InnoDB中实现的是行级锁。
row-level lock
gap
next-lock
2-6-3-6. 隔离级别
隔离级别参数:transaction_isolation
mysql> select @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ |
+-------------------------+
RU : 读未提交,可脏读,一般部议叙出现
RC : 读已提交,可能出现幻读,可以防止脏读.
RR : 可重复读,功能是防止"幻读"现象 ,利用的是undo的快照技术+GAP(间隙锁)+NextLock(下键锁)
SR : 可串行化,可以防止死锁,但是并发事务性能较差
补充: 在RC级别下,可以减轻GAP+NextLock锁的问题,但是会出现幻读现象,一般在为了读一致性会在正常select后添加for update语句.但是,请记住执行完一定要commit 否则容易出现所等待比较严重.
如果需要更改隔离级别则更改如下参数
transaction_isolation=read-uncommitted
transaction_isolation=read-committed
transaction_isolation=REPEATABLE-READ
MVCC ---> undo 快照
2-7. InnoDB的核心参数
2-7-1. 存储引擎相关
2-7-2. 查看系统使用哪种引擎,以及设置存储引擎
show engines;
show variables like 'default_storage_engine';
select @@default_storage_engine;
(1) 通过参数设置默认引擎
(2) 建表的时候进行设置
(3) alter table t1 engine=innodb
2-7-3. 共享表空间与独立表空间
innodb_data_file_path
一般是在初始化数据之前就设置好
例子:
innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend
show variables like 'innodb_file_per_table';
2-7-4. 缓冲区池
2-7-4-1. 查询
select @@innodb_buffer_pool_size;
show engine innodb statusG
innodb_buffer_pool_size
一般建议最多是物理内存的 75-80%
2-7-5. innodb_flush_log_at_trx_commit (双一标准之一)
作用:主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点,取值分别为0、1、2三个。
2-7-6. 查询
select @@innodb_flush_log_at_trx_commit;
2-7-7. 参数说明
1,每次事物的提交都会引起日志文件写入、flush磁盘的操作,确保了事务的ACID;flush到操作系统的文件系统缓存 fsync到物理磁盘.
0,表示当事务提交时,不做日志写入操作,而是每秒钟将log buffer中的数据写入文件系统缓存并且秒fsync磁盘一次;
2,每次事务提交引起写入文件系统缓存,但每秒钟完成一次fsync磁盘操作。
--------
The default setting of 1 is required for full ACID compliance. Logs are written and flushed to disk at each transaction commit.
With a setting of 0, logs are written and flushed to disk once per second. Transactions for which logs have not been flushed can be lost in a crash.
With a setting of 2, logs are written after each transaction commit and flushed to disk once per second. Transactions for which logs have not been flushed can be lost in a crash.
-------
2-7-8. Innodb_flush_method=(O_DIRECT, fdatasync)
https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_method
2-7-9. 作用
控制的是,log buffer 和data buffer,刷写磁盘的时候是否经过文件系统缓存
2-7-10. 查看
show variables like '%innodb_flush%';
2-7-11. 参数值说明
O_DIRECT :数据缓冲区写磁盘,不走OS buffer
fsync :日志和数据缓冲区写磁盘,都走OS buffer
O_DSYNC :日志缓冲区写磁盘,不走 OS buffer
2-7-12. 使用建议
最高安全模式
innodb_flush_log_at_trx_commit=1
Innodb_flush_method=O_DIRECT
最高性能:
innodb_flush_log_at_trx_commit=0
Innodb_flush_method=fsync
2-7-13. redo相关的参数
innodb_log_buffer_size=16777216
innodb_log_file_size=50331648
innodb_log_files_in_group = 3
2-7-14. 锁的说明
RR模式(对索引进行删除时):
GAP: 间隙锁
next-lock: 下一键锁定
例子:
id(有索引)
1 2 3 4 5 6
GAP:
在对3这个值做变更时,会产生两种锁,一种是本行的行级锁,另一种会在2和4索引键上进行枷锁
next-lock:
对第六行变更时,一种是本行的行级锁,在索引末尾键进行加锁,6以后的值在这时是不能被插入的。
总之:
GAP、next lock都是为了保证RR模式下,不会出现幻读,降低隔离级别或取消索引,这两种锁都不会产生。