mysql内部结构和InnoDB底层原理

一、mysql内部结构

mysql总体上分为客户端、Server层、引擎层，具体如下图：

1、连接器

一般客户端通过jdbc、navicat等工具发送请求连接到mysql服务端，完成TCP三次握手后，连接器就开始认证身份，如果身份认证成功，所有操作将依赖此时读取到的权限，因此权限的确定是一连接就读取确认了，为什么不实时读取权限，因为如果并发量大的情况下，势必要暂停用户请求，然后才能更改权限，性能上会有很大的损耗

CREATE USER 'username'@'host' IDENTIFIED BY 'password'; #创建新用户
grant all privileges on *.* to 'username'@'%'; #赋权限,%表示所有(host)
flush privileges #刷新数据库
update user set password=password('123456') where user='root';#(设置用户名密码)
show grants for root@"%"; #查看当前用户的权限
show processlist;#查看连接状态命令
kill Id值#关闭连接命令

2、查询缓存

server端的查询缓存，存储结构是key、value形式，key是sql语句，value是查询的结果集，每次对表执行一次更新操作，这个表所有的查询缓存都会失效，所以缓存很难命中，基本不用，mysql8这个功能已经被去除了；一般对于不需要经常修改的字典表可以用这个功能（现在一般用redis做字典缓存），可以在my.cnf文件设置query_cache_type=DEMAND

在mysql8版本以下的可以在my.cnf中配置：

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

select SQL_CACHE * from test where ID=5;#query_cache_type为2的用法

show global variables like "%query_cache_type%";#查看当前mysql实例是否开启缓存机制

3、分析器

词法分析：MySQL 从你输入的"select"这个关键字识别出来，这是一个查询语句。它也要把字符串“T”识别成“表名 T”，把字符串“ID”识别成“列 ID”

语法分析：根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。如果你的语句不对，就会收到“You have an error in your SQL syntax”的错误提醒

4、优化器

mysql会根据内部计算是否要选索引，或者join查询时选择哪个是驱动表，以及mysql其它的优化

5、执行器

判断是否有当前表的权限，如果没有，就会返回没有权限的错误，如果有权限，mysql就会打开表，根据表设置的存储引擎类型调用对应的存储引擎接口（如果是在查询缓存中命中，会在查询缓存返回结果时做权限认证）

二、InnoDB底层原理与mysql日志机制

1、undo log

InnoDB对undo log文件的管理采用段的方式，也就是回滚段（rollback segment）。每个回滚段记录了1024个undo log segment，每个事务只会使用一个undo log segment

在mysql5.5的时候，只有一个回滚段，那么最大同时支持的事务为1024个。在mysql5.6开始，InnoDB支持最大128个回滚段，故其支持同时在线的事务限制提高到了128*1024

innodb_undo_directory：设置undo log文件所在的路径。该参数的默认值为"./"，即innodb数据文件存储位置，目录下ibdata1文件就是undo log存储的位置。
innodb_undo_logs: 设置undo log文件内部回滚段的个数，默认值为128。
innodb_undo_tablespaces: 设置undo log文件的数量，这样回滚段可以较为平均地分布在多个文件中。设置该参数后，会在路径innodb_undo_directory看到undo为前缀的文件。

undo log日志什么时候删除

新增类型的，在事务提交之后就可以清除掉了。

修改类型的，事务提交之后不能立即清除掉，这些日志会用于mvcc。只有当没有事务用到该版本信息时才可以清除。

2、redo log

innodb_log_buffer_size，查看redo log buffer大小参数，默认16M，最大值4096M，最小值1M

show variables like '%innodb_log_buffer_size%';

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

show variables like '%innodb_log_group_home_dir%';

innodb_log_files_in_group：查看redo log文件的个数，命名方式如：ib_logfile0,ib_logfile1...ib_logfilen。默认两个，最大100个

show variables like '%innodb_log_files_in_group%';

innodb_log_file_size：查看单个redo log文件大小，默认值为48M。最大值为512G，注意最大值指的是整个redo log系列文件之和，即（innodb_log_file_in_group*innodb_log_file_size）不能大于最大值512G

show variables like '%innodb_log_file_size%';

redo log磁盘写入过程：

redo log从头开始写，写完一个文件继续写另一个文件，写到最后一个文件末尾就又回到第一个文件开头循环写，如下面这个图所示

write pos是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头

checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件里

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里面的数据还没来得及写入磁盘文件的话就会丢失数据

InnoDB有一个后台线程，每隔1秒，就会把redo log buffer中的日志，调用操作系统函数write

写到文件系统page cache，然后调用操作系统函数fsync持久化到磁盘文件

redo log写入策略参看下图：

# 查看innodb_flush_log_at_trx_commit参数值：
show variables like 'innodb_flush_log_at_trx_commit';
# 设置innodb_flush_log_at_trx_commit参数值(也可以在my.ini或my.cnf文件里配置)：
set global innodb_flush_log_at_trx_commit=1;

3、binlog

binlog二进制日志记录保存了所有执行过程的修改操作语句，不保存查询操作。如果mysql服务意外停止，可通过二进制日志文件排查，用户操作或表结构操作，从而来恢复数据库数据

启动binlog记录功能，会影响服务器性能，但是如果需要恢复数据或主从复制功能，则好处大于对服务器的影响

# 查看binlog相关参数
show variables like '%log_bin%';

 mysql5.7默认是关闭的，8.0默认是打开的。上图的log_bin的值是OFF就代表binlog是关闭状态，打开binlog功能，需要修改配置文件my.ini(windows)或my.cnf(linux)，然后重启数据库

在配置文件中的[mysqld]部分增加如下配置：

# 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 # 执行自动删除距离当前15天以前的binlog日志文件的天数， 默认为0， 表示不自动删除
max_binlog_size = 200M # 单个binlog日志文件的大小限制，默认为 1GB


log_bin：binlog日志是否打开状态
log_bin_basename：是binlog日志的基本文件名，后面会追加标识来表示每一个文件，binlog日志文件会滚动增加
log_bin_index：指定的是binlog文件的索引文件，这个文件管理了所有的binlog文件的目录。
sql_log_bin：sql语句是否写入binlog文件，ON代表需要写入，OFF代表不需要写入。如果想在主库上执行一些操作，但不复制到slave库上，可以通过修改参数sql_log_bin来实现。比如说，模拟主从同步复制异常。

 重启数据库后我们再去看data数据目录会多出两个文件，第一个就是binlog日志文件，第二个是binlog文件的索引文件，这个文件管理了所有的binlog文件的目录

当然也可以执行命令查看有多少binlog文件

show binary logs;
#查看当前正在使用的是哪一个binlog文件
show master status;

binlog的日志格式

用参数binlog_format可以设置binlog日志的记录格式，mysql支持三种格式类型：

• STATEMENT：基于sql语句的复制，每一条会修改数据的sql都会记录到master机器的binlog中，这种方式日志量小，节约IO开销，提高性能，但是对于一些执行过程中才能确定结果的函数，比如UUID()、SYSDATE()等函数如果随sql同步到slave机器去执行，则结果根master机器执行的不一样
• ROW：基于行的复制，日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改记录下每一行数据修改的细节，可以解决函数、存储过程等在slave机器的复制问题，但这种方式日志量较大，性能不如STATEMENT。举个例子，假设update语句更新10行数据，STATEMENT方式就是记录这条update语句，ROW方式记录被修改的10行数据
• MIXED：混合模式复制，实际就是前两种模式的结合，在MIXED模式下，mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在STATEMENT和ROW之间选择一种，如果sql里有函数或一些执行时才知道结果的情况，会选择ROW，其它情况选择STATEMENT，推荐使用这一种

binlog写入磁盘机制

binlog写入磁盘机制主要通过sync_binlog参数控制，默认值是0

• 为0的时候，表示每次提交事务都只write到page cache，由系统自行判断什么时候执行fsync写入磁盘。虽然性能得到提升，但是机器宕机，page cache里面的binlog会丢失
• 为1时，表示每次提交事务都会执行fsync写入磁盘，这种方式最安全
• 还有一种方式，可以设置为N(N>1)，表示每次提交事务都write到page cache，但积累N个事务后才fsync写入磁盘，这种如果机器宕机会丢失N个事务的binlog

删除binlog日志文件

删除当前的binlog文件
reset master;
# 删除指定日志文件之前的所有日志文件，下面这个是删除6之前的所有日志文件，当前这个文件不删除
purge master logs to 'mysql-binlog.000006';
# 删除指定日期前的日志索引中binlog日志文件
purge master logs before '2023-01-21 14:00:00';

查看binlog日志文件

可以使用mysql自带的工具命令mysqlbinlog查看binlog日志内容

# 查看bin-log二进制文件（命令行方式，不用登录mysql）
mysqlbinlog --no-defaults -v --base64-output=decode-rows D:/dev/mysql-5.7.25-winx64/data/mysql-binlog.000007 

# 查看bin-log二进制文件（带查询条件）
mysqlbinlog --no-defaults -v --base64-output=decode-rows D:/dev/mysql-5.7.25-winx64/data/mysql-binlog.000007 start-datetime="2023-01-21 00:00:00" stop-datetime="2023-02-01 00:00:00" start-position="5000" stop-position="20000"

binlog日志文件恢复数据

当前表数据如下图：

删除两条数据后再来查询

 如果不清楚binlog放在哪可以用show variables like '%log_bin%';查一下，查看binlog内容：

mysqlbinlog --no-defaults -v --base64-output=decode-rows /var/lib/mysql/binlog.000001

 对于# at 720就是要恢复位置，SET TIMESTAMP要恢复的时间，需要把时间戳转换成时间格式

 位置号恢复

mysqlbinlog  --no-defaults --start-position=311 --stop-position=751 --database=test /var/lib/mysql/binlog.000001 | mysql -uroot -p123456 -v test

如果有这个警告恢复不了可以这样写

mysqlbinlog  --no-defaults --start-datetime="2023-06-27 22:24:47" --stop-datetime="2023-06-27 22:25:41" --database=test /var/lib/mysql/binlog.000001 | mysql -uroot -p -v test

还可以使用mysqldump命令工具每天凌晨的时候定时备份数据，备份出来的文件是具体的sql，最近一次的全量备份再加上binlog提交的事务来恢复数据

mysqldump -u root 数据库名>备份文件名;
mysqldump -u root 数据库名 表名字>备份文件名;  #备份整个表

例：
mysqldump -u root -p test>test.sql; test.sql生成出来的sql文件

为什么会有redo log和binlog两份日志呢？

mysql早期使用的是myisam存储引擎，要保证crash-safe（任何时间服务器异常重启，保证事务的完整型），只能使用InnoDB存储的redo log和undo log来实现

假设一条数据被删了，事务一提交redo log就无法找回了，只能通过binlog

4、错误日志

当数据库故障导致无法运行时使用下面命令

# 查看错误日志存放位置
show variables like '%log_error%';

5、通用日志查询

通用日志查询会记录用户的所有操作，一般不开启，定位问题时临时开启

show variables like '%general_log%';
# 打开通用查询日志
SET GLOBAL general_log=on;