1. MySQL 逻辑架构概述
MySQL 的架构大致可以分为两部分：Server层 和 存储引擎层。
- Server层 负责大部分核心服务功能，包括连接器、查询缓存、分析器、优化器、执行器等。
- 存储引擎层 则负责数据的实际存储和读取，不同的存储引擎（比如 InnoDB 和 MyISAM）有不同的特性和实现。
2. SQL 语句执行流程
SQL 语句的执行流程我总结了几个关键步骤：
image.png
- 连接器：首先管理客户端连接，负责身份验证和权限控制。
- 查询缓存：如果查询结果之前已经被缓存了，直接从缓存返回结果，避免重复计算。
- 分析器：对 SQL 语句进行语法分析和语义检查，确认 SQL 是否正确。
- 优化器：最重要的部分，它生成执行计划，选择最合适的执行策略，优化 SQL 查询的效率。包括索引选择、连接顺序等。
- 执行器：按照优化器生成的执行计划，实际执行 SQL 操作，获取数据并返回给客户端。
3. 优化器细节
优化器在 MySQL 查询执行中的角色非常重要。它不仅决定了如何选择索引，还决定了如何进行多表连接、扫描方式等。优化器的工作原理：
- 索引选择：在有多个索引的情况下，优化器会选择最合适的索引来加速查询。
- 连接顺序：对于多表关联查询，优化器会决定表的连接顺序，以最小化扫描的数据量。
- 扫描方式：根据数据表的大小、索引的可用性等，选择合适的扫描方式（如全表扫描、索引扫描等）。
优化器的执行过程我简单概括为：
- 解析 SQL：首先将 SQL 语句解析成语法树。
- 生成候选执行计划：根据查询条件生成多个执行计划。
- 评估成本：优化器根据各执行计划的执行成本（如 I/O、CPU、内存消耗等）进行比较。
- 选择最优计划：最终选出成本最低的执行计划。
查看执行计划：通过 EXPLAIN 语句来查看 MySQL 执行 SQL 时的计划。举个例子：
EXPLAIN SELECT * FROM users WHERE id = 10;
通过这个语句，我可以看到表的扫描方式、使用的索引和连接顺序等。
4. Redo Log 的作用与工作原理
Redo Log 是 MySQL 中一个重要的物理日志，尤其是在 InnoDB 存储引擎中。它的作用是确保即使数据库发生异常重启，已经提交的事务不会丢失，这种机制叫做 crash-safe。
Redo Log 的工作原理其实可以想象成一个“循环写板”：
-
循环写入：每次记录数据变更时，都会写入 Redo Log。当写入位置
write pos超过checkpoint时，系统会暂停新的更新操作，先擦除旧记录，推进checkpoint。 - 作用：通过这种方式，即便数据库崩溃，Redo Log 中的已提交事务也可以在恢复时重新应用。
Redo Log 参数：
-
innodb_flush_log_at_trx_commit：建议设置为 1，确保每次事务提交时，Redo Log 都会立即写入磁盘，保证数据不会丢失。 -
sync_binlog：建议设置为 1，确保每次事务的 binlog 都能被持久化到磁盘，防止 binlog 丢失。
5. 两阶段提交
Redo Log 和 binlog 一起参与了 MySQL 的 两阶段提交（2PC）过程。这个过程确保了分布式系统中不同节点的数据一致性和事务的原子性。在 MySQL 的事务处理中，Redo Log 负责确保事务的持久性，而 binlog 则记录了更详细的事件信息，主要用于复制和恢复。
6. 备份策略
备份策略是数据库管理中的一项重要工作。在 MySQL 中，常见的备份策略包括定期进行全量备份和增量备份。备份的频率要根据系统的业务需求来决定：
- 一天一备：适合数据更新频繁的系统，能够保证较小的恢复点目标（RPO）。
- 一周一备：适合数据变化较少的系统，减少存储和备份操作的负担。
全量备份的频率会影响数据库的 恢复时间目标（RTO） 和 恢复点目标（RPO），需要根据实际需求平衡备份与恢复的效率。
