insert成功返回时，数据已写入binlog（刷盘）、redo log（fsync）、buffer pool（脏页），但.ibd数据文件尚未落盘。

INSERT成功返回时，数据到底写到哪儿了？

“执行完INSERT就看到新数据”，不等于数据已落盘。MySQL返回成功，只代表binlog已刷盘、redo log已fsync、对应数据页已加载进buffer pool——但数据文件（.ibd）本身可能还在内存里没写出去。

这解释了为什么突然断电后查不到刚插入的记录：buffer pool里的脏页还没刷，而redo log虽在磁盘上，但恢复需依赖崩溃恢复流程，不是“立刻可见”。

• innodb_flush_log_at_trx_commit = 1：每次事务提交都fsync redo log，保证日志持久化
• sync_binlog = 1：每次事务提交都刷 binlog 到磁盘，主从复制安全的前提
• 数据页刷盘由后台线程（如page cleaner）异步控制，受innodb_max_dirty_pages_pct等参数影响

为什么Buffer Pool是INSERT路径的关键中转站？

INSERT不直接写磁盘，而是先改buffer pool里的数据页和索引页。这是性能核心：内存修改比随机磁盘写快两个数量级以上。

但这也带来几个现实约束：

• 如果buffer pool太小，频繁刷脏页会拖慢INSERT吞吐，甚至触发lru scan阻塞新页加载
• 全文索引（FULLTEXT）的倒排索引更新也走buffer pool，但其辅助表（如INNODB_FT_INDEX_TABLE）更新有延迟，innodb_ft_aux_table设置后需等几秒才可见
• 唯一键冲突检查发生在buffer pool内查找阶段，不是磁盘扫描；所以高并发下冲突检测快，但锁竞争（如插入意向锁）仍可能发生

redo log和binlog的写入顺序与作用差异

两者都写磁盘，但角色完全不同：redo log保障单机崩溃恢复，binlog支撑主从复制和逻辑恢复。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

它们的协作靠两阶段提交（2PC），顺序固定为：

• 先写redo log prepare 状态
• 再写binlog
• 最后写redo log commit 状态

这个顺序不能颠倒。否则会出现主从不一致或崩溃后无法判断事务是否该提交的问题。例如，若binlog先写完但redo log未commit就宕机，MySQL重启后会根据redo log状态回滚该事务，但从库已基于binlog重放——数据就丢了。

容易被忽略的隐式锁与加锁时机

很多人以为INSERT一定加行锁，其实InnoDB默认用的是隐式锁：插入时不显式上锁，直到另一个事务要读/改同一行，才由读方“帮它补锁”。

这意味着：

• 单纯执行INSERT INTO t VALUES (1, 'a')，不触发任何锁等待，也不占锁资源
• 但如果另一事务同时执行SELECT ... FOR UPDATE WHERE id = 1，它会检测到该记录存在隐式锁，并主动调用lock_rec_lock为其加上X锁，然后自己排队
• 幻读风险仍在RR隔离级别下存在，尤其涉及INSERT ... SELECT或无主键/唯一键的批量插入场景

真正影响并发表现的，往往不是“有没有锁”，而是“谁触发锁、何时触发、锁住什么范围”。比如插入间隙（gap）时的插入意向锁（INSERT intention），常被误认为是行锁，实则是为后续加间隙锁做协调的轻量信号。