MySQL INSERT 从客户端到磁盘需经连接层、解析器、优化器、存储引擎、日志系统和磁盘六层，成功返回意味着binlog已刷盘、redo log已fsync、数据页已入buffer pool。
MySQL INSERT 语句从客户端到磁盘的完整路径
一条 INSERT 不是“发出去就完事”，它会依次经过连接层、解析器、优化器、存储引擎、日志系统和磁盘，中间任何一环失败都会回滚。你看到的“成功返回”，意味着 binlog 已刷盘、redo log 已 fsync、数据页至少已写入 buffer pool（InnoDB 默认不立即刷盘）。
InnoDB 中 INSERT 的关键五步与对应日志行为
以 INSERT INTO t(a,b) VALUES(1,'x') 为例，在 InnoDB 引擎下实际发生：
-
INSERT解析后生成执行计划，定位目标 page（若不在 buffer pool，则触发预读或单页加载） - 在 buffer pool 中修改对应 leaf page：插入记录、更新 page header 中的
heap_top和page_dir槽位 - 生成一条
INSERT类型的 redo log record，写入log_buffer；事务提交时该 record 必须持久化到 ib_logfile* - 若开启 binlog（
binlog_format=ROW），同时生成一条Write_rows_log_event写入 binlog cache；commit 时刷盘（受sync_binlog控制） - 该 page 标记为
dirty，后续由page_cleaner线程异步刷入磁盘（受innodb_max_dirty_pages_pct和innodb_io_capacity影响）
为什么有时 INSERT 很快，有时卡住？关键阻塞点
INSERT 延迟通常不来自 SQL 解析，而来自以下三类同步等待：
- 等待
log_flush_order_mutex：多个事务竞争将 redo log 刷盘，尤其在innodb_flush_log_at_trx_commit=1且高并发时明显 - 等待
dict_operation_lock：表结构变更（如ALTER TABLE）未完成，新 INSERT 会被挂起（错误信息含Waiting for table metadata lock） - 等待唯一索引检查：插入值违反
UNIQUE KEY或PRIMARY KEY时，需加next-key lock扫描，可能被其他事务锁阻塞 - 等待 buffer pool latch：极端高并发下，大量线程争抢同一 page 的
btr_search_latch或buf_pool->mutex
INSERT 性能调优中容易忽略的配置项
很多调优只盯 innodb_buffer_pool_size，但这些参数对写入吞吐影响更直接：
-
innodb_log_file_size：过小会导致频繁 checkpoint，拖慢大事务；建议总大小 ≥ 2GB（innodb_log_files_in_group × innodb_log_file_size） -
innodb_flush_log_at_trx_commit：设为2可大幅提升吞吐（redo log 仅 write 到 OS cache），但崩溃可能丢 1s 数据 -
innodb_doublewrite：关闭可提升写性能，但遇到部分页写失败（partial write）时无法恢复，SSD + 文件系统支持 atomic write 时才建议关 -
bulk_insert_buffer_size：仅对LOAD DATA INFILE和多值INSERT ... VALUES(),(),()批量插入生效，单条 INSERT 无效
真正决定单条 INSERT 延迟的，往往是磁盘 fsync 耗时和锁竞争，而不是 SQL 解析或网络传输——这点在排查慢 INSERT 时最容易误判。
