MySQL执行INSERT时数据先经SQL解析与权限校验，再由存储引擎写入Buffer Pool并记redo log，最后通过两阶段提交协调binlog与redo log保证一致性。
MySQL 执行 INSERT 语句时，数据到底去了哪？
INSERT 不是“写完就完”，它会经过解析、优化、引擎层写入、日志落盘等完整链路。跳过这些环节直接调优或排查问题（比如主从延迟、事务卡住、磁盘写满），容易误判根源。
SQL 解析与权限校验阶段发生了什么？
客户端发来的 INSERT 字符串，先被 MySQL Server 层接收，然后走标准 SQL 生命周期：
-
sql_parse()将文本解析成语法树（AST），检查括号、逗号、字段名是否合法；字段名不存在会报错Unknown column 'xxx' in 'field list' - 校验用户对目标表的
INSERT权限，权限不足报错ERROR 1142 (42000): INSERT command denied to user - 若含子查询（如
INSERT INTO t SELECT * FROM s），此时还会触发对源表的SELECT权限检查
存储引擎层如何真正写入数据？
Server 层把执行计划交给引擎（如 InnoDB）后，写入逻辑取决于引擎实现和事务状态：
- 非事务表（如 MyISAM）：直接写入
.MYD文件，加表级锁，不写 redo log - InnoDB 表（默认）：
- 先在内存中修改
Buffer Pool中的数据页和索引页 - 同时写入
redo log buffer（物理日志，保证 crash-safe） - 若事务未提交，变更对其他事务不可见（靠
undo log和 MVCC 实现） - 主键冲突会立即报错
ERROR 1062 (23000): Duplicate entry 'x' for key 'PRIMARY'，不等刷盘
- 先在内存中修改
redo log 和 binlog 怎么协同保证一致性？
MySQL 用两阶段提交（2PC）协调 InnoDB 和 Server 层日志，避免主从不一致或崩溃丢失：
1. InnoDB prepare → 写入 redo log（状态为 PREPARE） 2. Server 层写入 binlog 3. InnoDB commit → 修改 redo log 状态为 COMMIT，并刷盘（受 innodb_flush_log_at_trx_commit 控制）
关键点：
- 若步骤 2 失败（如磁盘满），InnoDB 回滚 prepare 状态，事务彻底失败
- 若步骤 3 崩溃，MySQL 启动时会读取 redo log 中 PREPARE 记录，查 binlog 是否完整：有则重做，无则回滚
-
sync_binlog=1+innodb_flush_log_at_trx_commit=1是强一致性组合，但写性能下降明显
真正难调试的往往不是 INSERT 本身，而是它触发的隐式行为：唯一索引校验锁等待、自增锁争用、大字段导致的页分裂、或者长事务让 undo log 无法回收。别只盯着 INSERT 语句，得顺着日志、锁、buffer pool 看下去。
