Innodb底层原理与Mysql日志机制深入剖析

news2024/11/29 5:34:59

1.MySQL的内部组件结构

在这里插入图片描述
客户端执行sql语句，这时mysql会把sql语句发给server层连接器，连接器通过账号密码端口号进行连接数据库，验证成功后，然后在权限表里查询相应的权限，然后依赖于此时读取权限，连接器把sql语句发给词法分析器，词法分析分析词是否有问题，没有问题再分析语法有没有问题，没有问题在sql分发给优化器，此时sql语句通过成本计算，是否走索引，没有问题再把sql发给执行进行执行，返回结果给客户端。

1.1.连接器

主要验证客户端账号密码端口号是否正确，验证成功后，会去权限表里面获取对应的权限，比如建表权限，查询权限，修改权限等等。

1.2.查询缓存

客户端执行查询sql，首先查看查询缓存中是否有这个数据，有这个数据将会直接从缓存中取出数据（缓存的数据key-value形式进行存储，key为执行sql语句，value执行的结果值），然后返回给客户端，假如缓存中没有，执行完成后，把执行结果存在查询缓存中。
说明：查询缓存在数据发生更新，插入后查询缓存会被清空，所以查询缓存的命中率十分的低，在my.cnf里面客户设置

## my.cnf
#query_cache_type有3个值 0代表关闭查询缓存OFF，1代表开启ON，2（DEMAND）代表当sql语句中有SQL_CACHE关## 键
## 词时才缓存
query_cache_type=2

1.3.分析器

主要分析词法是否正确，语法是否正确，然后生成一个语法树
在这里插入图片描述

1.4.优化器

决定是否走索引，各个表进行关联，决定没有表的连接顺序。

1.5.执行器

查看用户是否执行权限，有权限进行执行，无权限报错。想·

2.Innodb底层原理与Mysql日志机制

在这里插入图片描述
分析：通过主键进行加载，查看缓存池中是否有数据，假如没有缓存池中没有数据，通过读取.idb文件中page页数据读取到buffer pool中（假如没有，这步就不执行，直接向下执行），然后在UNDO日志中保存当前的修改的日志，然后修改buffer pool中的数据，执行器，接着在REDO log buffer中写入日志，然后通过顺序写的形式，写入redo 日志中，主要进行物理修改，接着执行器，执行写binlog日志写入磁盘中，当binlog日志写完后，会在redo日志中打上commit的标识，接着计算机，会在空闲的时候，把buffer pool池中的数据写入到磁盘中。

2.1 redo log重做日志关键参数

2.1.1 innodb_log_buffer_size：

设置redo log buffer大小参数，默认16M ，最大值是4096M，最小值为1M

show variables like '%innodb_log_buffer_size%';

2.1.2 innodb_log_group_home_dir：

设置redo log文件存储位置参数，默认值为"./"，即innodb数据文件存储位置，其中的 ib_logfile0 和 ib_logfile1 即为redo log文件。

show variables like '%innodb_log_group_home_dir%';

在这里插入图片描述

2.1.3 innodb_log_files_in_group：

设置redo log文件的个数，命名方式如: ib_logfile0, iblogfile1… iblogfileN。默认2
个，最大100个。

show variables like '%innodb_log_files_in_group%';

2.1.4 innodb_log_file_size：

设置单个redo log文件大小，默认值为48M。最大值为512G，注意最大值指的是整个 redo
log系列文件之和，即(innodb_log_files_in_group * innodb_log_file_size)不能大于最大值512G。

show variables like '%innodb_log_file_size%';

2.2 redo log 写入磁盘过程分析：

redo log 从头开始写，写完一个文件继续写另一个文件，写到最后一个文件末尾就又回到第一个文件开头循环写，如
下面这个图所示。
在这里插入图片描述
write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。
check point 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件里。
write pos 和 checkpoint 之间的部分就是空着的可写部分，可以用来记录新的操作。如果 write pos 追上
checkpoint，表示redo log写满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。

innodb_flush_log_at_trx_commit：这个参数控制 redo log 的写入策略，它有三种可能取值：

设置为0：表示每次事务提交时都只是把 redo log 留在 redo log buffer 中，数据库宕机可能会丢失数
据。
设置为1(默认值)：表示每次事务提交时都将 redo log 直接持久化到磁盘，数据最安全，不会因为数据库
宕机丢失数据，但是效率稍微差一点，线上系统推荐这个设置。
设置为2：表示每次事务提交时都只是把 redo log 写到操作系统的缓存page cache里，这种情况如果数
据库宕机是不会丢失数据的，但是操作系统如果宕机了，page cache里的数据还没来得及写入磁盘文件的话就
会丢失数据。

在这里插入图片描述

3 binlog二进制归档日志

binlog二进制日志记录保存了所有执行过的修改操作语句，不保存查询操作。如果 MySQL 服务意外停止，可通过二进制日志文件排查，用户操作或表结构操作，从而来恢复数据库数据。
启动binlog记录功能，会影响服务器性能，但如果需要恢复数据或主从复制功能，则好处则大于对服务器的影响。

show variables like '%log_bin%';

当log_bin为off时需要配置my.ini参数

#log‐bin设置binlog的存放位置，可以是绝对路径，也可以是相对路径，这里写的相对路径，则binlog文件默认会放在
data数据目录下
 log‐bin=mysql‐binlog
# Server Id是数据库服务器id，随便写一个数都可以，这个id用来在mysql集群环境中标记唯一mysql服务器，集群环
境中每台mysql服务器的id不能一样，不加启动会报错
server‐id=1
# 其他配置
binlog_format = row # 日志文件格式，下面会详细解释
expire_logs_days = 15 # 执行自动删除binlog日志文件的天数， 默认为0， 表示不自动删除
max_binlog_size = 200M # 单个binlog日志文件的大小限制，默认为 1GB

3.1 binlog日志相关操作

1.存放的位置

一般存放在data目录下，叫mysql-binlog.000001的文件
在这里插入图片描述

2.查看binlog日志里面执行的语句

mysqlbinlog --no-defaults -v --base64-output=decode-rows D:\softWare\mysql\MySQLServer8.0\data\mysql-binlog.000001

在这里插入图片描述

3.binlog日志恢复数据

在这里插入图片描述

mysqlbinlog --no-defaults --start-position=650 --stop-position=1073 --database=test D:\softWare\mysql\MySQLServer8.0\data\mysql-binlog.000002 | mysql -uroot -proot -v test

在这里插入图片描述
说明：这里根据序号进行恢复，恢复序号之间的数据，–start-position=数据开始，–stop-position=数据结束

mysqlbinlog  --no-defaults --start-datetime="2023-05-29 08:33:23"  --stop-datetime="2023-05-29 08:39:04" --database=test D:\softWare\mysql\MySQLServer8.0\data\mysql-binlog.000002 | mysql -uroot -proot -v test

在这里插入图片描述

说明：第二种方案，通过时间进行恢复数据。