为什么同一个SQL在MySQL多次执行后耗时会大幅下降-mysql教程-PHP中文网

MySQL首次查询慢、后续变快的底层主因是InnoDB缓冲池（buffer pool）和OS页缓存：首次需磁盘随机I/O，后续直接内存访问，耗时从秒级降至毫秒级；buffer_pool_size设置不合理或数据被淘汰会导致提速不可靠。

为什么同一个sql在mysql多次执行后耗时会大幅下降

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，以下操作会清空或绕过缓存，让下一次执行重新变慢：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

执行 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大小不合理、热点数据无法驻留，或者查询本身未命中索引导致反复刷脏页。