本书汇集了关于MySQL数据库的各种常见面试题及其详细解答,旨在帮助读者深入理解MySQL技术并顺利通过相关职位的面试。
### MySQL 复制原理及流程
#### 基本原理流程
MySQL的复制机制基于主从架构,主要涉及到三个线程:Master上的`binlogdump`线程、Slave上的`IO`线程以及`SQL`线程。
1. **Master上的binlogdump线程**:当Master服务器上发生事务提交时,该线程负责将这些事务的二进制日志(binlog event)传输到Slave服务器。
2. **Slave上的IO线程**:接收并处理从Master传来的binlog,并将其写入本地的relay log文件中。
3. **Slave上的SQL线程**:读取relay log中的binlog事件并在Slave上执行相应的操作,确保数据的一致性。
在多线程复制场景下,除了上述三种线程外,还存在一个协调器线程。它将relay log中的binlog事件分配给多个worker线程进行并行处理,从而提高复制效率。
#### 一致性与延时性
- **一致性**:MySQL 5.6引入了多种机制来提升复制的一致性,包括使用`mysql.slave_relay_log_info`表存储SQL线程的位置信息、GTID(全局事务ID)复制和半同步复制等。
- 在MySQL 5.5及以前版本中,位置信息仅保存在文件中。如果Slave服务器异常重启,则可能导致数据不一致。从MySQL 5.6起通过引入`relay_log_info_repository=TABLE`参数解决了这一问题。
- GTID复制机制确保每个事务在所有实例上最多执行一次,从而增强了一致性。
- 半同步复制虽然提高了复制的一致性,但在超时时间内未能完成复制的情况下仍存在风险。MySQL 5.7引入了无损半同步复制机制,通过调整`rpl_semi_sync_master_wait_point`参数,在事务提交前等待slave的ACK确认,实现真正的无损复制。
- **延时性**:随着版本更新,MySQL不断优化其复制机制以减少延迟:
- MySQL 5.5采用单线程复制模式。
- MySQL 5.6引入了多库复制功能但尚未真正支持多线程。
- MySQL 5.7实现了真正的多线程复制,并通过group commit机制在slave端使用多个worker线程并行执行事务,显著减少延迟。
#### 数据恢复
- 当Master服务器意外宕机时,未成功传输至Slave的binlog数据需要特别处理。根据宕机时是否已切换到异步复制模式来决定相应的措施。
- 如果已经处于异步复制状态,则只需等待Master重启并继续执行复制即可。
- 若尚未进入异步复制阶段,则需检查Master的日志情况,评估丢失的数据,并采取必要步骤恢复一致性。
- MySQL 5.7的无损半同步机制能够更好地处理这种情况,即使在Master崩溃的情况下也能保证数据的一致性。
### MySQL 存储引擎区别:MyISAM与InnoDB
#### 至少五点不同
1. **事务支持**:InnoDB支持事务处理而MyISAM不提供这一特性。这使得InnoDB更适合需要高度一致性和可靠性的应用环境。
2. **锁机制**:InnoDB使用行级锁定,相比而言MyISAM采用表级锁定方式。行级锁定提高了并发性能,在大量并发请求情况下尤为明显。
3. **表结构差异**:InnoDB利用索引组织的存储方法(IOT),数据按索引顺序排列;而MyISAM则是堆表形式,即按照插入顺序存放数据。
4. **表文件拷贝**:InnoDB的数据和索引存于同一个文件内,不能通过简单复制来迁移表数据。相反地,MyISAM允许直接复制其表文件以实现快速传输。
5. **容错性**:与容易受到损坏的MyISAM相比,InnoDB具有更高的故障恢复能力,在服务器崩溃或硬件问题情况下更不易受损。
6. **行格式支持**:InnoDB提供多种行存储格式选项(如Compact、Redundant等),可根据具体需求优化空间利用率和查询性能;而MyISAM没有这种灵活性。