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已持久化，但数据页本身可能仍在内存中——这是性能与可靠性的关键权衡。
