insert语句通过innodb事务机制间接触发buffer pool写入：先查找或加载数据页，修改后标记为dirty并加入flush_list；若页不在buffer pool中则从磁盘读入，否则直接内存修改。
INSERT语句如何触发Buffer Pool写入
MySQL的INSERT语句本身不直接写Buffer Pool，而是通过InnoDB存储引擎的事务和页管理机制间接完成。真正触发页加载、修改、刷脏的是后续的「行插入→页查找→页分裂→日志记录→脏页标记」这一连串动作。关键前提是：目标页不在Buffer Pool中时，会先从磁盘读入；若已存在，则直接在内存中修改——但无论哪种情况，只要页被修改，就会被标记为dirty并加入flush_list。
- 必须启用
innodb_buffer_pool_load_at_startup=ON（仅影响启动加载，不影响运行时行为） - 确保
innodb_buffer_pool_size足够大，否则频繁的LRU淘汰会让观察变得不可靠 -
INSERT执行后立刻查INFORMATION_SCHEMA.INNODB_BUFFER_PAGE可能查不到对应页——因为页可能还在LRU_list冷端未被访问，或刚写入尚未被page cleaner线程归入flush_list
用performance_schema定位INSERT涉及的具体页
想确认某条INSERT是否真的修改了某个索引页或数据页，最直接的方式是开启performance_schema中的页级监控表。需提前启用相关消费者与仪器：
UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME IN ('events_statements_history_long', 'events_stages_history_long');
<p>UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE 'stage/innodb/%';</p>
然后执行带明确主键/唯一键的INSERT，再查：
SELECT * FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%INSERT%' ORDER BY TIMER_START DESC LIMIT 1\G
拿到EVENT_ID后，关联events_stages_history_long可看到类似stage/innodb/insert buffer insert或stage/innodb/buffer pool resize等阶段——注意：如果走自增主键且页未满，通常不会触发insert buffer，而是直写聚集索引页。
为什么INFORMATION_SCHEMA.INNODB_BUFFER_PAGE查不到刚INSERT的页
这是最常踩的坑：INFORMATION_SCHEMA.INNODB_BUFFER_PAGE只显示当前Buffer Pool中**已加载且未被驱逐**的页，但它有严重限制：
- 该表默认每10秒才刷新一次缓存，不是实时视图
- 它不包含
UNDO_LOG页、SYSTEM页、以及正在被page cleaner处理但尚未提交刷盘的dirty页 - 如果INSERT导致页分裂，新分配的页可能还没来得及被
buf_page_get_gen()加载进LRU链表，就已被标记为dirty并挂到flush_list上——此时它在INNODB_BUFFER_PAGE里“消失”了 - 查询该表需要
PROCESS权限，且在高并发下性能开销大，不建议在线上频繁使用
用innodb_metrics和SHOW ENGINE INNODB STATUS交叉验证
更稳定的做法是结合指标计数器和状态快照。先启用关键指标：
SET GLOBAL innodb_monitor_enable = 'buffer_page_gets,buffer_pages_created,buffer_pages_written,buffer_pool_reads';
执行INSERT前后分别运行：
SELECT NAME, COUNT FROM information_schema.innodb_metrics
WHERE NAME IN ('buffer_page_gets', 'buffer_pages_created', 'buffer_pages_written');
再执行SHOW ENGINE INNODB STATUS\G，重点关注BUFFER POOL AND MEMORY段中的Pages read、Pages created、Pages written，以及ROW OPERATIONS段中是否有inserts计数变化。若Pages created增加而Pages read未变，说明是纯内存分配（如新页分配）；若Pages read上升，则说明发生了磁盘页加载。
真正难观察的是页内偏移更新和mini-transaction边界——这些只能靠gdb attach mysqld进程+断点buf_page_get_gen或分析ib_logfile0内容，日常运维几乎不用碰。别在没开innodb_status_output_locks时硬看TRANSACTIONS段，那里面没有页级信息。
