MySQL 面试题

Binlog

是什么？

binlog用于记录数据库执行的写入性的DDL和DML（不包括查询）信息，以二进制的形式保存在磁盘中。

DDL：用于定义和管理数据库中的对象，例如表、视图、索引等。常见的DDL语句包括CREATE、ALTER和DROP语句。CREATE用于创建新对象，ALTER用于修改现有对象的结构，而DROP用于删除对象。

DML：用于对数据库中的数据进行操作，例如插入、查询、更新和删除数据。常见的DML语句包括SELECT、INSERT、UPDATE和DELETE语句。

有什么用？

可以用来做主从复制和数据恢复。

数据恢复：

1.mysqlbinlog binlog.000001 > recovery.sql #将binlog转化为sql文件
2.剔除某时间点的drop命令
3.mysql -u username -p < recovery.sql #执行历史SQL

也可指定具体数据库数据表
mysqlbinlog --database=mydatabase binlog.000001 > recovery.sql
mysqlbinlog --tables=mydatabase.mytable binlog.000001 > recovery.sql
mysqlbinlog --database=mydatabase --tables=mytable binlog.000001 > recovery.sql
mysql -u username -p database_name < recovery.sql

假如数据库是在9点坏掉的，10点发现的，先把备份的数据恢复一下，然后执行binlog到9点，至于9点到10的数据大概率需要重新做一遍。

主从复制

默认情况下，二进制日志在每次写入 ( sync_binlog=1) 时都会同步到磁盘。如果 sync_binlog未启用，并且操作系统或机器（不仅是 MySQL 服务器）崩溃，则二进制日志的最后语句可能会丢失。为了防止这种情况，请启用 sync_binlog系统变量以在每个提交组之后将二进制日志同步到磁盘 N。请参见 第 5.1.7 节“服务器系统变量”。最安全的值为 sync_binlog1（默认值），但这也是最慢的。

sync_binlog=0：禁用 MySQL 服务器将二进制日志同步到磁盘。相反，MySQL 服务器依赖操作系统将二进制日志不时刷新到磁盘，就像处理任何其他文件一样。此设置提供最佳性能，但在发生电源故障或操作系统崩溃时，服务器可能已提交尚未同步到二进制日志的事务。

sync_binlog=1：在提交事务之前启用二进制日志到磁盘的同步。这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响。如果发生电源故障或操作系统崩溃，二进制日志中丢失的事务仅处于准备状态。这允许自动恢复例程回滚事务，从而保证二进制日志中不会丢失任何事务。

例如，如果您正在使用InnoDB表，MySQL服务器处理一条COMMIT 语句时，它会按顺序将许多准备好的事务写入二进制日志，同步二进制日志，然后将该事务提交到InnoDB. 如果服务器在这两个操作之间意外退出，事务将在重新启动时回滚InnoDB，但仍存在于二进制日志中。–innodb_support_xa假设设置为默认值 1，此类问题即可解决 。虽然这个选项与XA事务的支持有关InnoDB，但它也保证了二进制日志和InnoDB数据文件的同步。为了使此选项提供更高程度的安全性，MySQL 服务器还应该配置为 InnoDB在提交事务之前将二进制日志和日志同步到磁盘。InnoDB默认同步日志，可sync_binlog=1用于同步二进制日志。该选项的作用是，在崩溃后重新启动时，在执行事务回滚后，MySQL 服务器会扫描最新的二进制日志文件以收集事务xid值并计算二进制日志文件中的最后一个有效位置。然后，MySQL 服务器指示InnoDB完成已成功写入二进制日志的任何准备好的事务，并将二进制日志截断到最后一个有效位置。这可以确保二进制日志反映 InnoDB表的准确数据，因此副本与源保持同步，因为它不会收到已回滚的语句。

innodb_flush_log_at_trx_commit
控制提交操作的严格ACID合规性 与重新安排并批量完成提交相关 I/O 操作时可能获得的更高性能 之间的平衡 。您可以通过更改默认值来获得更好的性能，但随后可能会在崩溃时丢失事务。

完全符合 ACID 需要默认设置 1。每次事务提交时都会将日志写入并刷新到磁盘。

设置为 0 时，每秒将日志写入并刷新到磁盘一次。未刷新日志的事务可能会在崩溃中丢失。

设置为 2 时，日志会在每次事务提交后写入，并每秒刷新到磁盘一次。未刷新日志的事务可能会在崩溃中丢失。

在XA事务中 启用InnoDB对两阶段提交的支持，从而导致事务准备时需要额外的磁盘刷新。XA 机制在内部使用，对于任何打开二进制日志并从多个线程接受数据更改的服务器来说都是必不可少的。如果禁用 ，则事务可以按照与实时数据库提交事务的顺序不同的顺序写入二进制日志，这在灾难恢复中或在副本上重播二进制日志时可能会生成不同的数据。不要 在复制源服务器上禁用，除非您有一种不寻常的设置，其中只有一个线程能够更改数据。 innodb_support_xainnodb_support_xa

innodb_support_xa已弃用；预计它会在未来的 MySQL 版本中被删除。 InnoDB从 MySQL 5.7.10 开始，始终启用 XA 事务中两阶段提交的支持。innodb_support_xa不再允许禁用，因为它会使复制不安全并阻止与二进制日志组提交相关的性能提升 。

MySQL存储结构

为什么要采用B+树作为指引

1. B+树多路分叉，能显著减少IO次数
2. B+树的查询效率更加稳定，数据都放在叶子结点
3. B+树能提高分为查询的效率，因为叶子结点指向想哟个叶子结点
4. B+树采用顺序读

顺序读：