1. MySQL复制原理及流程
(1)、复制基本原理流程
1、Main：线程——记录所有改变数据库数据的语句，放到上面；
2、From：io线程——使用start Slave后，负责从上面拉取内容，放入自己的relay log中；
3. Slave：sql执行线程——执行中继日志中的语句；
(2) MySQL复制有几个线程以及它们之间的关系
MySQL复制是基于以下三种线程的交互（多线程复制中应该有四种线程）：
1.上面的dump线程，负责将事件传递给slave；
2、Slave上的IO线程负责接收进来的消息并写入relay log；
3、Slave上的SQL线程负责读取并执行中继日志；
4、如果是多线程复制，无论是5.6库级别的假多线程，还是5.7的真多线程复制，SQL线程都只做这件事，只负责读出中继日志并处理它转移到线程上。 woker线程负责具体的事件执行；
（3）MySQL如何保证复制时数据的一致性，减少数据同步延迟
一致性主要有以下几个方面：
复制代码
1. .5之前，slave的SQL线程执行的中继日志的位置只能保存在文件（ ）中，并且默认每10000个事务同步到磁盘，这意味着当slave不小心崩溃重启，SQL线程执行的位置与数据库中的数据不一致，会导致复制错误。 如果不重复复制，可能会出现
导致数据不一致。 MySQL 5.6引入了参数itory。 当该参数设置为TABLE时，MySQL会将SQL线程执行的位置保存到mysql.sql文件中。 宕机后，从机通过崩溃
恢复可以将SQL线程执行的位置和用户事务恢复到一致的状态。
2、MySQL 5.6引入了GTID复制，每个GTID对应的事务在每个实例上最多执行一次，大大提高了复制的数据一致性；
3、MySQL 5.5引入了半同步复制。 用户安装半同步复制插件并开启参数后，设置超时时间，保证超时时间内如果事务没有传输到从机，则用户提交事务时不会返回，直到超时暂停。 异步复制，但是如果在异步之前用户线程正在等待事务时事务已经提交，那么该事务将会被提交
上面其他的都是可见的。 如果此时崩溃，那么该事务将不再在slave上可见。 这个问题直到5.7才得到解决；
4、MySQL 5.7引入无损半同步复制，默认引入参数。 意思是事务在切入半同步之前不提交，而是在收到slave的ACK确认后提交。 从此，复制才真正可以无损地完成。
5、5.7中无损复制的情况下，如果出现意外宕机，重启后发现没有传输到slave怎么办？ ？ ？ 分两种情况讨论，1.宕机时已经切入异步，2.宕机时还没有切入异步？ ？ ？ 宕机时如何判断是否切入异步？ ？ ？ 分别该如何处理呢？ ？ ？
复制代码
潜伏：
5.5是单线程复制，5.6是多库复制（对单库单表并发操作没用），5.7是真正的多线程复制，其原理是基于组的，只要
上面的事务是分组的，所以slave也可以通过多线程并发执行。 .0.0.5中引入的多线程复制原理基本相同。
(4)、工作中遇到的 bug的解决
5.6 多存储库复制有时会自行停止，我们编写了一个脚本来重新启动从站； 待补充...
2、MySQL和MySQL的区别，至少5点
(1)问5个不同点
复制代码
1.支持事物，而不是事物
2.支持行级锁，但支持表级锁
3.支持MVCC，不支持
4.支持外键，但不支持
5.不支持全文索引，但支持。
6.不能通过直接复制表文件的方式将表复制到另一台机器上，支持
7.表格支持多种行格式，但不支持
8.它是一个索引组织表和一个堆表
复制代码
(二)、发动机的4大特点
1. 插入缓冲区 ( )
2.第二次写入（write）
3. 自适应哈希索引（ahi）
4. 继续阅读
(3)、各个mysql版本的改进
复制代码
.6发动机的主要改进：
(1)数据定义语言
(2)NoSQL接口
(3) ( 更改表 / )
(4) MySQL正常关闭时，可以dump出pool(space,)，重启时，可以加快预热速度
(5)索引和表的统计数据持久化到mysql。 和mysql.，可以提供稳定的执行计划
(6)行支持压缩表
MySQL 5.7 引擎的主要改进
(1)修改字段长度有时可以使用DDL
(2)池支持在线调整大小
(3)矿池支持导出部分比率
(4)支持新建，里面可以创建多个表
(5)磁盘临时表存放在temp中，以前存放的是
(6)透明表空间压缩功能
复制代码
(4)、2个count(*)哪个更快，为什么
更快，因为内部维护了一个计数器，可以直接调用。
(5)、执行索引2
两者都是B+树索引，分别是索引组织表和堆表。 您应该熟悉索引组织表和堆表之间的区别
3、MySQL与char的区别以及(50)中50的含义
(1)、与char的区别
单字节字符集下，char(N)内部存储时始终是定长的，不存在变长字段长度列表。 多字节字符集下，如果char(N)存储的字节数超过N个字节，那么char(N)就和(N)没有什么区别。多字节字符集下，如果存储
如果存储的字节数小于N，则存储N个字节，并在后面补空格，达到N个字节的长度。 两者都存储可变长度数据和可变长度字段长度列表。 (N) 不管字节字符集如何，它都是变长的，即存储变长数据和变长字段长度的列表。
(2)、(50)中50的含义
最多存储50个字符，(50)和(200)为hello存储相同的空间，但后者在排序时会消耗更多的内存，因为order by col使用了col长度的计算（引擎是相同的）。 在早期的MySQL版本中，50代表字节数，现在它代表字符数。
(3)、int(20)中20的含义
指显示字符的长度
不影响内部存储，只影响定义的int前面加了多少个0，方便在报表中显示
(4)、mysql为什么要这样设计
对大多数应用程序来说没有意义，只是指定一些工具使用的字符数； int(1)和int(20)的存储和计算相同；
4. 事务和日志的实现
(1)日志有多少种？
重做和撤消
(2)、日志的存储形式
redo：当一个页面被修改时，首先写入redo log，然后写入redo log的文件系统缓存()，最后同步到磁盘文件(fsync)。
Undo：在.5之前，undo只能存储在*文件中。 5.6之后，可以通过设置ces参数将undo log存储在*之外。
(3) 事务是如何通过日志实现的，越深入越好
基本流程如下：
因为当事务修改一个页时，必须先记录undo，并且在记录undo之前必须记录undo的重做，然后修改数据页，然后记录数据页修改的重做。 Redo（包括undo修改）必须在数据页之前持久化到磁盘。当事务需要回滚时，因为undo，数据页可以回滚到之前的镜像
状态，当从崩溃中恢复时，如果重做日志中没有该事务对应的记录，则需要使用undo将事务的修改回滚到事务开始之前。 如果有记录，则使用redo前滚至事务完成后提交。
5、MySQL的几种日志条目格式及区别
(1)、各种日志格式的含义
复制代码
1.：每一条会修改数据的sql都会被记录在.
优点：不需要记录每一行的变化，减少了日志量，节省了IO，提高了性能。 （与Row相比，能节省多少性能和日志量取决于应用程序的SQL情况。通常情况下，Row格式修改或插入相同记录生成的日志量小于生成的日志量。
但考虑到带条件的操作，以及删除全表、修改表等操作，ROW格式会产生大量日志，所以在考虑是否使用ROW格式日志时，应根据申请的实际情况。 生成的日志量会有所不同。 增加多少，以及带来的IO性能问题。 ）
缺点：由于只记录执行语句，为了让这些语句在slave上正确运行，还需要在每条语句执行时记录一些相关信息，以保证所有语句在slave上都能得到相同的结果奴隶，因为他们最后被处决。 结果。 另外，mysql的复制，
像一些具体的函数，slave可以和上面一致就会有很多相关的问题（比如sleep()函数，(),user-(udf)都会有问题）。
使用以下函数的语句也无法复制：
* ()
* UUID()
* 用户()
* ()
* ()（除非启动时启用了 --is-now 选项）
同时会产生比RBR更多的行级锁
2、Row：不记录sql语句上下文的相关信息，只保存哪条记录被修改过。
优点：不需要记录执行的SQL语句的上下文相关信息，只需要记录记录被修改了什么。 所以日志内容会清晰地记录每一行数据修改的细节。并且不会出现存储过程在某些特定情况下，或者，以及调用和触发器无法正确复制的问题
缺点：当所有执行的语句都记录到日志中时，会被记录为每行记录的修改，可能会产生大量的日志内容。 比如一条语句修改了多条记录，那么里面的每一条修改都会有记录，这会造成大量的日志，尤其是执行alter table等语句时，
由于表结构的修改，每条记录都会改变，表的每条记录都会记录在日志中。
3.：是以上两个级别的混合使用。 一般语句修改都以格式保存。 比如有些函数无法完成主从复制的操作，以行格式保存。 MySQL会按照区分日志的形式来执行每条具体的SQL语句进行记录，
也就是Row和Row之间选其一。 新版本MySQL中队的行级模式也进行了优化。 并非所有修改都会记录在行级别。 例如，当表结构发生变化时，就会记录在mode中。 记录。 至于修改数据或等待的语句，仍然会记录所有行的更改。
复制代码
（二）适用场景
当一条SQL操作多行数据时，节省的空间越多，行占用的空间也越大。 但行模式更可靠。
(3)、结合第一个问题，每种日志格式在复制中的优缺点
它可能占用相对较少的空间，并且传输到从机的时间可能更短，但它不如行模式可靠。 Row模式在操作多行数据时比较消耗空间，但可靠。
6、如果MySQL数据库的CPU飙升到500%，他该怎么办？
当cpu飙升到500%时，首先使用操作系统的top命令检查是否是占用造成的。 如果不是，找出占用率高的进程并处理。 如果是造成的，show一下是否有消耗资源的sql在运行。 找到消耗高的sql，
检查执行计划是否准确，索引是否缺失，或者是数据过多导致的。 一般来说，必须杀死这些线程（同时观察cpu使用率是否下降），并进行相应的调整（例如添加索引、更改sql、更改内存参数）后，然后重新运行这些SQL。 也有可能每条sql消耗的资源并不多，但是突然间，
有大量的连接导致CPU飙升。 这种情况下，就需要分析为什么连接数会随着应用的增加而激增，然后做出相应的调整，比如限制连接数等。
7.SQL优化
(1)、出来的各项的含义
复制代码
id：每个独立执行的操作的标志，表示操作对象的顺序。 一般来说，如果id值较大，则先执行； 如果id值相同，则按照从上到下的顺序。
：查询中每个子句的类型。
table: name，被操作的对象的名称，通常是表名（或别名），但也可以是其他格式。
：匹配的分区信息。
类型：连接类型。
：列出可能用到的索引。
key：实际使用的索引。
：使用的索引键的平均长度，以字节为单位。
ref：表示本行正在操作的对象的引用对象，可能是const表示的常量，也可能是另一个表
key指向的对象，例如驱动表的join列。
rows：估计每次需要扫描的行数。
:rows*/100 表示本步骤结束时获得的行数（估计值）。
extra：重要的附加信息。
复制代码
(二)、含义及使用场景
用于分析sql性能的消耗分布。 当慢SQL无法通过使用它来解决时，需要使用它对SQL进行更详细的分析，找出该SQL消耗的时间最多的是哪一部分，并确认该SQL的性能瓶颈。
(3)、索引问题
结果中，一般来说，尽量使用索引（类型为const、ref等，且键列有值），避免使用全表扫描（类型显式为ALL）。 例如，具有where条件和良好选择性的列需要建立索引。
驱动表的连接列也需要建立索引。 驱动表的连接列还可以与where条件列创建联合索引。 当需要排序或者group by时，还可以考虑建立索引来满足直接排序和汇总的需求。
八、备份计划及其实施原理
(一)、备份计划
这取决于图书馆的规模。 一般来说，100G以内的库可以考虑使用，因为它更加轻量和灵活。 备份时间选择在业务非高峰期，每天可以进行全量备份（备份
输出文件相对较小，压缩后更小）。 100G以上的库可以考虑使用，备份速度明显比这快。 一般选择一周进行一次全量备份，其余时间每天进行增量备份，备份时间在业务非高峰期。
(2)、备份恢复时间
复制代码
物理备份恢复快，逻辑备份恢复慢
这与机器的速度，尤其是硬盘的速度有关系。 以下是一些仅供参考。
2分钟20G()
80G 30 分钟()
30分钟111G()
3小时288G（额外）
4小时3T（额外）
逻辑导入时间一般是备份时间的5倍以上
复制代码
(3) 备份恢复失败如何处理
首先，恢复前要做好充足的准备，避免恢复过程中出现失误。 例如备份后的有效性检查、权限检查、空间检查等。 如果报错，根据错误提示进行相应调整。
(四)、及实现原理
属于逻辑备份。 添加 -- 选项以进行一致的备份。 后台进程首先会设置事务隔离级别为RR（SET READ），
然后显式启动一个事务（START/!/），这样可以保证事务中读取的数据是该事务的快照。 然后从表中读取数据。如果加上--data=1，则会在开头加上数据库读锁
（），启动事务后，记录数据库当前位置（），立即解锁，然后读取表中的数据。所有数据导入完毕后，即可结束事务
:
是物理备份，直接复制表空间文件，同时不断扫描生成的重做日志并保存。最后一次备份完成后，会进行flush log操作（旧版本有bug，如果有的话会丢失数据） 5.6上不执行此操作），确保所有重做日志已经放到磁盘上（涉及事务的两阶段提交
概念，因为不复制，所以必须保证所有重做日志都放在磁盘上，否则可能会丢失最后一组已提交事务的数据）。这个时间点就是备份的时间点完全的。 虽然数据文件不一致，但是这期间的redo可以使数据文件达到一致性（恢复时所做的事情）
感情）。 然后需要用读锁flush，备份其他引擎的表，备份后解锁。 这样就实现了完美的热备份。
9、sql文件中备份的sql，如果sql文件中一行只有一个....value()怎么办？ 如果备份需要带复制点信息怎么办？
复制代码
- 跳过 -
[root@helei- ~]# -uroot -p helei –skip--
进入 ：
关键（c1），
钥匙 (c2)
) = =51 =;
/!40101设置=@/;
–
– 表 helei 的数据
锁定合雷写；
/!40000 更改表 helei KEYS /;
