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：每次事务提交都fsyncredo 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支撑主从复制和逻辑恢复。
它们的协作靠两阶段提交（2PC），顺序固定为：
- 先写
redo logprepare 状态 - 再写
binlog - 最后写
redo logcommit 状态
这个顺序不能颠倒。否则会出现主从不一致或崩溃后无法判断事务是否该提交的问题。例如，若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），常被误认为是行锁，实则是为后续加间隙锁做协调的轻量信号。
