MySQL首次查询慢、后续变快的底层主因是InnoDB缓冲池（buffer pool）和OS页缓存：首次需磁盘随机I/O，后续直接内存访问，耗时从秒级降至毫秒级；buffer_pool_size设置不合理或数据被淘汰会导致提速不可靠。
MySQL查询首次执行慢、后续变快的底层原因
这不是错觉，而是InnoDB缓冲池（innodb_buffer_pool）和操作系统页缓存共同起效的结果。首次执行时，数据页基本不在内存中，需从磁盘读取（随机I/O），后续执行若数据仍在缓冲池或OS缓存里，就直接走内存访问，耗时可从秒级降到毫秒级。
innodb_buffer_pool 是性能变化的关键开关
这个参数决定了MySQL能为数据和索引缓存多少内存。如果它太小（比如默认128MB），而你的表有2GB，那每次查询都只能缓存一小部分，反复换入换出，导致“看似变快了几次，又突然变慢”。
- 查当前值：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; - 生产环境建议设为物理内存的50%–75%，但别超过可用内存，否则触发系统swap反而更慢
- 修改后需重启MySQL才生效（在线调整仅限MySQL 5.7+且需满足特定条件）
哪些情况会让“变快”失效或不可靠
即使开了buffer pool，以下操作会清空或绕过缓存，让下一次执行重新变慢：
- 执行
FLUSH TABLES或FLUSH TABLES WITH READ LOCK - 表被
ALTER TABLE ... ENGINE=InnoDB重建（会丢弃原buffer pool中的页） - 大量写入导致buffer pool频繁淘汰旧页，把刚缓存的热点数据挤出去
- 查询用了
SQL_NO_CACHE（MySQL 5.7已移除，但8.0前某些客户端驱动仍可能加） - 跨连接执行，且
innodb_buffer_pool_instances设置过高 + 数据分布不均，造成局部热点无法复用
如何判断是不是缓存带来的提速
不要只看执行时间，要验证数据是否真进了buffer pool：
- 执行查询前后，运行：
SELECT POOL_ID, BLOCKS_USED, DATA_SIZE FROM information_schema.INNODB_BUFFER_POOL_STATS;观察DATA_SIZE是否明显增长 - 用
SELECT * FROM information_schema.INNODB_BUFFER_PAGE WHERE TABLE_NAME = 'your_db/your_table' LIMIT 5;看对应表的数据页是否在pool中 - 关掉查询缓存（
query_cache_type=0）并确认没用SQL_CACHE，排除旧式查询缓存干扰
真正影响线上稳定性的，往往不是“第二次比第一次快”，而是“为什么第三次又慢了”——这通常指向buffer pool大小不合理、热点数据无法驻留，或者查询本身未命中索引导致反复刷脏页。
