SQL 写入从发出到落盘需经历连接建立、解析优化、引擎写入（Redo/Undo/Binlog 协同）、两阶段提交及异步刷盘等完整流程。
一条 SQL 写入语句从发出到最终落盘，不是简单地“执行就完事”，而是一系列协同工作的内部流程。理解这个生命周期，有助于排查慢写入、数据不一致、主从延迟等问题。
客户端发起与连接建立
应用通过数据库驱动（如 JDBC、PyMySQL）向数据库服务器发起 TCP 连接请求。连接建立后，会进行身份认证和权限校验。若使用连接池，这一步可能被复用，跳过重复握手。连接成功后，客户端将 SQL 文本（如INSERT INTO users(name, age) VALUES(‘Alice’, 28)）以协议包形式发送给服务端。
服务端解析与优化
收到 SQL 后，MySQL 服务端依次完成以下工作：
- 词法与语法分析：将 SQL 字符串拆解为 token，验证是否符合语法规则，生成解析树；
- 语义检查：确认表是否存在、字段是否合法、用户是否有 INSERT 权限等；
- 查询重写：如展开视图、常量折叠、去除无用条件；
- 执行计划生成：对 INSERT 而言虽无复杂 JOIN，但仍需确定存储引擎、检查约束（主键 / 唯一索引冲突）、预估是否需要临时表或排序等。
引擎层写入与日志协同
优化器将执行指令交由存储引擎（如 InnoDB）处理。此时关键动作同步发生：
- 写 Redo Log（物理日志）：先在内存中的 redo log buffer 中记录页修改的物理变更（如“第 X 页第 Y 偏移处改为值 Z”），事务提交前必须刷盘（受innodb_flush_log_at_trx_commit 控制）；
- 写 Undo Log（逻辑日志）：记录反向操作（如“插入前该行不存在”），用于回滚和 MVCC 快照读；
- 修改 Buffer Pool：更新内存中的数据页，标记为 dirty page；
- 写 Binlog（逻辑日志）：Server 层记录逻辑 SQL 或行变更事件，用于主从复制和恢复，刷盘策略由 sync_binlog 决定。
注意：Redo Log 和 Binlog 需通过两阶段提交（2PC）保证一致性——先写 Redo（prepare 状态），再写 Binlog，最后写 Redo（commit 状态）。
落盘与清理收尾
写入并未随 SQL 返回而结束：
- Dirty Page 刷盘：后台线程（如 InnoDB 的 page cleaner）异步将 Buffer Pool 中脏页刷新到磁盘数据文件（.ibd）；
- Log 文件轮转与清理：Redo Log 循环复用，Binlog 按大小或时间滚动，过期日志由 purge 线程或 DBA 手动清理；
- Undo Log 回收：当所有活跃事务都不再需要某版本快照时，对应 undo log 才被标记可覆盖。
客户端收到“Query OK”响应，仅代表事务已提交、Redo 和 Binlog 已持久化，但数据页本身可能仍在内存中——这是性能与可靠性的关键权衡。
