- MySQL执行过程
- 修正
- binlog开启状态
- 一句话总结SQL执行：
- 总结要点
- 数据恢复
- 崩溃恢复（自动）
- 手动恢复（人为）
- 一句话对比
MySQL执行过程
修正
MySQL - 一条 SQL 的执行过程详解 | Java 全栈知识体系
其中修正：数据库连接池有 Druid、C3P0、DBCP，对于MySQL方来说，它自己不是连接池，而是连接管理。应用通过本地的数据库连接池，复用多个到MySQL的持久连接。MySQL服务器则使用多线程模型，为每个连接分配一个线程来并发处理其上到来的SQL请求。
为什么说MySQL这边不叫“连接池”？
- 角色不同（主动 vs. 被动）：
- 应用连接池：是一个主动的管理者。它主动创建连接、主动分配连接、主动回收连接、主动检测连接健康度。它的行为是预设好的、主动发起的。
- MySQL的“连接管理”：是一个被动的接受者。它监听一个端口，等待客户端连接。当连接建立后，它就为这个连接分配一个线程来处理该连接上发来的请求。它不会主动去“分配”或“复用”连接给客户端。连接的生命周期主要由客户端驱动。
- 目的不同（性能优化 vs. 并发处理）：
- 应用连接池：主要目的是性能优化，解决创建/销毁连接的高昂开销。
- MySQL的“连接管理”：主要目的是实现并发处理。每个连接一个线程（或由线程池管理），是为了同时服务多个客户端，而不是为了“复用”连接以节省成本。
那么，MySQL这边更准确的叫法是什么？
MySQL这边更准确的术语是 “连接管理器” 或 “连接层”。它的核心组件是 “连接线程”。
- 在传统模型中，是 “每连接一线程”（Thread-Per-Connection）。MySQL会为每一个成功的网络连接创建一个对应的线程，专门服务这个连接。
- 在高性能版本（如Percona Server、MariaDB）或企业版MySQL中，提供了 “线程池”（Thread Pool）插件。注意，这仍然是线程池，不是连接池。它的目的是用少量工作线程来服务大量连接，避免在连接数极高时（成千上万）因线程上下文切换导致系统崩溃。但即便如此，它管理的仍然是处理请求的线程，而不是网络连接本身。连接依然是保持的。
MySQL服务器并没有一个与应用端对等的“连接池”。
- 应用连接池：管理的是物理TCP连接的复用，目的是节省建立连接的成本。
- MySQL连接管理器：管理的是为每个连接服务的线程，目的是实现请求的并发处理。
binlog开启状态
MySQL 5.7 及更早版本默认是：关闭的。
MySQL 8.0 版本默认是：开启的。
你可以通过以下 SQL 命令快速确认 Binlog 的状态：
-- 如果 `Value` 是 **`ON`**，则表示已开启。
-- 如果 `Value` 是 **`OFF`**，则表示未开启。
SHOW VARIABLES LIKE 'log_bin';
总结
| MySQL 版本 | Binlog 默认状态 | 原因 |
|---|---|---|
| 5.7 及以前 | OFF (关闭) | 认为复制是高级功能，非核心需求 |
| 8.0 及以后 | ON (开启) | 提升开箱即用性，为复制、备份、恢复提供更好基础支持 |
如果需要实现主从架构，必须开启binlog。
MySQL 5.6 开启 Binlog 步骤：
-
修改配置文件
找到my.cnf(Linux) 或my.ini(Windows)，在[mysqld]段落下添加：[mysqld] server-id = 1 log-bin = mysql-bin -
重启 MySQL 服务
# Linux service mysql restart # 或 systemctl restart mysql# Windows: 在服务管理器中重启 MySQL -
验证是否开启
SHOW VARIABLES LIKE 'log_bin'; -- 看到 ON 即为成功。
注意： server-id 是 MySQL 5.6 主从复制的必需参数，不然可能无法启动。
一句话总结SQL执行：
SQL执行 = 记录旧照（Undo Log）-> 改内存 -> 写流水账（Redo Log）-> 提交时归档（Binlog）-> 最终确认。
- Redo Log（重做日志）：保证持久性。事务提交后，即使宕机，数据也绝不丢失。
- Undo Log（回滚日志）：保证原子性。事务回滚或系统崩溃时，能撤销修改，回到过去。
- Binlog（归档日志）：用于数据复制和基于时间点的数据恢复。
总结要点
-
三大缓冲区：
- Buffer Pool：缓存数据和Undo Log。
- Log Buffer：缓存Redo Log。
- Binlog Cache：每个线程独占，缓存Binlog。
-
刷盘时机：
- Redo Log：事务提交时强制刷盘（取决于
innodb_flush_log_at_trx_commit）。 - Binlog：事务提交时强制刷盘（取决于
sync_binlog）。 - 数据和Undo Log：异步刷盘，靠后台线程完成。
- Redo Log：事务提交时强制刷盘（取决于
-
这个刷盘时机设计实现了：即使数据页本身没有刷盘，只要事务提交成功，修改就一定可以通过日志恢复，数据绝不会丢。
- 可靠性：通过Redo Log和Binlog的同步刷盘，确保了即使崩溃，已提交的事务也绝不丢失。
- 高性能：通过数据和Undo Log的异步刷盘，避免了缓慢的随机IO对事务提交速度的影响。
undo log、redo log 、bin log 都是要先写进缓存再持久化的？
MySQL 这三种核心日志都采用 “先写缓存，后持久化” 的策略，这是为了在保证数据安全的同时，极大地提升性能。
以下是它们的缓存和刷盘机制对比：
日志类型 缓存区域 刷盘时机与控制 核心目的 Undo Log Buffer Pool 异步刷盘。随数据脏页由后台线程一起刷入表空间（ ibdata1）。保证事务原子性 Redo Log Log Buffer 可配策略。由 innodb_flush_log_at_trx_commit控制，可设置为提交时强制刷盘。保证事务持久性 Binlog Binlog Cache 可配策略。由 sync_binlog控制，可设置为提交时强制刷盘。用于复制与恢复 一句话总结：
- Undo Log 被视为数据，所以和数据页共用 Buffer Pool，异步刷盘。
- Redo Log 和 Binlog 是真正的日志，有自己独立的缓存，并且可以通过参数在事务提交时进行同步强制刷盘，以确保数据不丢失。
数据恢复
崩溃恢复（自动）
- 什么时候用：MySQL自己挂了或服务器宕机后重启。
- 怎么做的：
- 前滚：用
Redo Log把磁盘上没来得及存的已提交数据，在内存里重做一遍。 - 回滚：用
Undo Log把那些没提交成功的事务修改，全部撤销掉。
- 前滚：用
- 目标：保证数据回到崩溃前最后一刻的一致性状态。整个过程MySQL自动完成。
崩溃恢复（自动）
应对mysql服务突然停止的情况：先使用Redo Log前滚，再使用Undo Log 回滚。
- 第一阶段：前滚
- 动作：无条件地、顺序地重放 Redo Log 中从最近检查点之后的所有修改。
- 目的：将数据库在内存中的状态重建到崩溃发生前的那一刻。这个状态是一个“混杂状态”，包含了已提交和未提交的事务。
- 第二阶段：回滚
- 动作：在前滚建立起的“混杂状态”基础上，扫描所有事务，利用 Undo Log 回滚那些没有 commit 标记的事务。
- 目的：清理现场，撤销所有未完成的工作，最终得到一个纯净的、只包含已提交事务的一致性状态。
最终效果： 数据库中只留下 所有已提交事务的结果，完美恢复到崩溃前的一个一致性状态。
手动恢复（人为）
- 什么时候用：人闯祸了，比如误删了表或数据。
- 怎么做的：
- 用最近的全量备份，恢复一个数据库底子。
- 用
Binlog作为“操作记录”，把从备份之后到误操作之前的所有增删改命令，重新执行一遍。
- 目标：把数据恢复到某个误操作发生之前的某个时间点。需要DBA手动操作。
一句话对比
- 崩溃恢复：救系统，靠
Redo/Undo Log，自动的。 - 手动恢复：救人，靠
备份 + Binlog，手动的。
)
