MySQL持久化和主从复制

发布时间：2023-12-19 14:06:13 所属栏目：MySql 来源：DaWei

导读： MySQL持久化和主从复制 MySQL执行过程

连接器

负责和客户端的通信，是半双工模式，所以某一时刻只能客户端向服务端请求或服务端向客户端发送数据，不能同时进行。mysql通过TCP/IP连接

MySQL持久化和主从复制 MySQL执行过程

连接器

负责和客户端的通信，是半双工模式，所以某一时刻只能客户端向服务端请求或服务端向客户端发送数据，不能同时进行。mysql通过TCP/IP连接到客户端。

验证用户账户和密码是否正确，如果正确会在mysql自带的权限表中查询用户权限

分析器

将客户端发过来的sql语句进行分析，包括预处理和解析过程。解析sql语句，关键词和非关键词提取解析，生成解析树

优化器

sql语句的优化，根据执行计划进行最优选择，匹配合适索引。

执行器

调用存储引擎的API

存储引擎

MySQL常用的存储引擎：InnoDB和MyISAM

两者区别：

1.InnoDB支持事务，MyISAM不支持事务.InnoDB默认将每条语句封装为事务，自动提交，这样会影响效率，可以将多条SQL放在begin和commit之间，封装成一个事务。

2.InnoDB支持外键，MyISAM不支持，将带有外键的InnoDB转换为MyISAM会失败。

3.InnoDB是聚集索引，索引和数据存在一个文件中。辅助索引要查询两次，叶子节点存储的是主键，再通过主键查询。MyISAM是非聚集索引，叶子节点存储的是数据文件的指针。MyISAM有三个文件：*.firm 表结构文件 .MYD 数据文件 .MYI 索引文件。

4.InnoDB不保存具体的行数，select count()时要扫描全表，速度较慢。MyISAM保存具体的行数，可直接查询。

【

InnoDB为什么没有这个特性？

因为InnoDB支持事务，由于事务特性，在同一时刻，表中的行数可能对不同事务不同。

InnoDB对count()的优化？

InnoDB中以索引组织表形式存储数据，主键索引树上叶子节点存放所有数据，辅助索引叶子节点上只存放主键，所以辅助索引树比主键索引树小很多，但数量是一样的，所以MySQL优化器会找最小的索引树进行遍历查询，减少加载次数，提高效率。

】

5.InnoDB不支持全文索引，5.7之后支持全文索引，MyISAM支持全文索引。

【

全文索引有两个变量，最小搜索长度和最大搜索长度。InnoDB默认最小搜索长度为3，MyISAM默认为4，所以只会对大于等于3或4的词语建立索引。

两种全文索引：

1.自然语言的全文索引：计算每个文档对象和查询的相关度，相关度是基于匹配的关键词的个数，以及关键词在文档中出现的次数。整个索引中出现次数越少的词语，匹配时相关度越高。如果一个词语超过50%的记录中出现了，自然语言的搜索将不会搜索该词语。

2.布尔搜索，在查询中自定义某个被搜索的词的相关度，可用一些前缀修饰符来修饰。

】

6.InnoDB支持行锁，表锁，MyISAM只支持表锁。

MySQL持久化 redo log重做日志

MySQL通过redo log完成事务的持久化。防止出现故障时，尚有未写入的脏页，在重启MySQL时，可通过redo log来恢复，达到事务持久性。

redo log的内容：物理日志文件，记录物理数据页面修改信息，redo log文件是顺序写入redo log file中。

redo log开始时间：事务开始之后产生redo log，在事务执行过程中写入redo log文件。

释放时间：当对应事务的脏页写入磁盘后，redo log占用空间可以被重用。

redo log写盘时间：在事务开始之后逐步写盘，而不是事务提交后写盘。redo log有一个缓存区innodb_log_buffer，默认8M，InnoDB引擎先将重做日志写在innodb_log_buffer中，然后通过三种方式将innodB日志缓冲区的日志刷新到磁盘。【1.master thread每秒执行一次；2.每个事务提交时；3.当重做日志缓冲区可用空间少于一半时】事务为提交前已经不断将日志刷新到磁盘，事务提交速度快。

undo log回滚日志

保存了事务发生之前的数据的版本，可以用于回滚，同时可以提供多版本控制下的读（MVCC），即非锁定锁。

内容：逻辑日志，仅仅将数据从逻辑上恢复成事务提交前的，而不是从物理上，跟redo log不一样。

开始时间：事务开始前，将当前版本生成undo log，生成undo log时也会产生redo log，保证undo log的可靠性。

释放时间：事务提交后不能马上清除undo log，而是放入待清理链表，由purge线程判断是否有其他事务在使用undo段中表的上一个版本信息，决定是否清理undo log的日志空间。

默认情况下undo log保存在共享表空间，即ibdatafile中，当发生大型事务性操作会产生大量的undo信息，会把共享表空间撑大，共享表空间变大后不会自动收缩，所以mysql5.7之后需要配置独立undo表空间。

MySQL主从复制

为了减轻主库的压力，在系统应用层面做读写分离，写操作走主库，读操作走从库。

复制策略

MySQL默认复制策略是异步的，基于不同的配置，slave不一定要一直和master保持不断连接的复制或等待复制。

同步策略：Master要等待所有slave应答之后才会提交半同步策略：Master等待至少一个slave应答之后就可以提交异步策略：Master不需要等待slave应答就可以提交延迟策略：slave要至少落后master指定的时间。复制模式基于语句的复制 SBR：记录每条更改数据的sql语句

【

优：binlog文件较小，节省IO，性能较高，可用于实时还原。

缺：不是所有的数据更改都会写入binlog，特别是使用特殊函数和一些不确定的语句操作，从而导致主从数据无法复制。复制需要全表扫描的update时，需要比RBR请求更多行级锁，容易复制出错，消耗更多资源

】基于行的复制 RBR：记录每条数据的更改细节

【

优：详细记录每行数据的更改细节，不会由于特殊函数或其他情况不能复制。

缺：产生大量binlog日志内容，性能不佳，会增大主从同步延迟出现的几率，无法从binlog中看到操作了什么语句

】混合复制 MBR：MySQL根据执行的每条具体sql语句区分对待记录的日志。一般的语句修改使用statement格式保存binlog，对于一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog。 binlog二进制日志

用于主从复制，从库利用主库上的binlog进行重播。也可用于数据库基于时间点的还原。

内容：逻辑日志，可认为是执行过的sql语句的反向信息。

开始时间：事务提交时将事务中的sql语句一次性按照一定格式写入binlog文件中。先对二进制日志文件写入然后进行提交。

释放时间：默认按照参数expire_logs_days配置的天数后会被自动删除。

配置文件的路径：log_bin_basename。binlog日志按指定大小，到达最大到小后，进行滚动更新，生成新的binlog文件，对每个binlog文件，通过统一的index文件来组织。

relaylog中继日志

master将binlog写入slave中的中继日志。slave有两个线程，一个线程去读master的binlog日志写到自己的中继日志，一个线程解析日志，执行sql。

redo log和binlog的区别

1.redo log是保证事务持久性，是事务层面的。binlog是实现主从复制，是数据库层面的。redo log是InnoDB层产生的，binlog是存储引擎上层产生的，不管什么存储引擎，对数据库修改都会产生二进制日志。

2.redo log是物理日志，是数据页面修改后的物理记录。记录的是物理页的情况mysql持久化，具有幂等性，多次操作前后状态一样。binlog是逻辑日志，记录的是所有影响数据的操作，记录内容较多。

3.开始时间和释放时间不同。redo log是事务提交后开始将重做日志写入innodb_log_buffer，并在事务执行中不断写入磁盘，在对应事务脏页写入磁盘后，redolog释放。binlog在事务提交时一次性写入缓存，按照配置过期时间删除。

（编辑：阜阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!