17370845950

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 看下去。