MySQL INSERT语句的完整执行流程是什么

MySQL执行INSERT需经SQL解析与权限校验、InnoDB引擎写入Buffer Pool并记redo log、两阶段提交协调binlog与redo log三个核心步骤，缺一不可。

MySQL 执行 INSERT 不是“把值塞进表里”就完事——它是一条横跨 SQL 层、存储引擎层、日志系统和事务机制的完整链路。跳过任一环节去排查慢插入、主从延迟或崩溃后数据丢失，大概率会误判问题根源。

SQL 层解析与权限校验：第一步就可能失败

客户端发来的 INSERT 字符串，首先进入 MySQL Server 层：

1. sql_parse() 将语句转为语法树（AST），检查括号、逗号、字段名拼写；字段不存在直接报错 Unknown column 'xxx' in 'field list'
2. 校验当前用户对目标表是否有 INSERT 权限，无权限报 ERROR 1142 (42000): INSERT command denied to user
3. 若含子查询（如 INSERT INTO t SELECT * FROM s），还会额外检查对源表的 SELECT 权限
4. 优化器此时决定是否走索引、是否需要临时表，但不涉及实际写入

InnoDB 引擎层写入：Buffer Pool + redo log 是核心

Server 层把执行计划交给 InnoDB 后，真实写入才开始：

1. 先在内存 Buffer Pool 中修改对应的数据页和索引页（聚簇索引 + 二级索引）
2. 同时把物理变更写入 redo log buffer（非刷盘，仅内存缓存）
3. 若事务未提交，变更对其他事务不可见——靠 undo log 和 MVCC 实现隔离
4. 主键或唯一索引冲突（如重复 id）会在这一层立即报错 ERROR 1062 (23000): Duplicate entry 'x' for key 'PRIMARY'，根本不会走到刷盘阶段

两阶段提交（2PC）：binlog 和 redo log 的协同生死线

事务提交时，MySQL 用 2PC 协调 Server 层（binlog）和 InnoDB 层（redo log），防止崩溃丢失或主从不一致：

1. 第一阶段：InnoDB 将事务状态设为 PREPARE，并写入 redo log
2. 第二阶段：Server 层写入 binlog；成功后，InnoDB 才将 redo log 状态改为 COMMIT 并刷盘
3. 若 binlog 写失败（如磁盘满），InnoDB 回滚 PREPARE 状态，事务彻底失败
4. 若 redo log 提交后崩溃，MySQL 启动时会读 redo log 中的 PREPARE 记录，再查 binlog 是否完整：有则重做，无则回滚
5. sync_binlog=1 + innodb_flush_log_at_trx_commit=1 是强一致性组合，但每次 INSERT 都要刷盘，性能明显下降

容易被忽略的隐式开销：锁、自增、页分裂才是真瓶颈

真正拖慢 INSERT 或引发死锁的，往往不是语句本身，而是它触发的后台行为：

1. 唯一索引校验会加 gap lock 或 next-key lock，导致并发插入卡在锁等待上
2. 高并发下 auto_increment 锁（innodb_autoinc_lock_mode=0/1 差异极大）可能成为争用热点
3. 大字段（如 TEXT、BLOB）或频繁插入导致 B+ 树页分裂，引发大量物理写和锁升级
4. 长事务让 undo log 无法及时回收，间接拖慢新事务的可见性判断和 purge 线程

别只盯着 INSERT 语句耗时，得顺着 SHOW ENGINE INNODB STATUS 看锁等待、用 perf 或 pt-pmp 抓栈看 CPU 花在哪、查 information_schema.INNODB_METRICS 看 buffer pool 命中率和 log 写入量——流程清楚了，才好定位到底是哪一环在拖后腿。