MySQL 查询时加 SQL_NO_CACHE 真的能绕过查询缓存吗？
答案是：不能，而且很可能完全没效果。原因很简单，那个古老的查询缓存（Query Cache）在主流版本里要么已经消失，要么默认就处于“休眠”状态。
具体来说，MySQL 8.0 已经彻底移除了查询缓存（query_cache_type 参数默认关闭且不可启用）。而 5.7 版本虽然保留了相关代码，但默认也是禁用的，甚至在编译时常常就被直接去掉了。所以，当你满怀期待地在查询前加上 SQL_NO_CACHE 时，MySQL 通常会选择安静地忽略它——不报错、不生效，也不会给你任何提醒。
一个常见的迷惑现象是：执行 SELECT SQL_NO_CACHE * FROM t WHERE id = 1; 多次后，去查看 SHOW STATUS LIKE 'Qcache_hits';，结果命中次数始终为 0，或者干脆收到一个 Unknown system variable 'query_cache_type' 的提示。
- 检查缓存是否存在：运行
SHOW VARIABLES LIKE 'ha ve_query_cache';。如果返回NO，那说明这个 MySQL 实例在编译时就没带上查询缓存功能。 - 检查缓存是否启用：即使上一步返回
YES，也要确认query_cache_type是否为ON（即值为1），并且query_cache_size > 0。 - 关键认知：
SQL_NO_CACHE这个提示词，只对「查询缓存」这一层起作用。对于真正影响性能的 InnoDB 缓冲池（innodb_buffer_pool）、操作系统页缓存、客户端连接层缓存，它完全无效。
不能，MySQL 8.0 已移除查询缓存，5.7 默认禁用，SQL_NO_CACHE 被静默忽略；它仅对已废弃的查询缓存有效，不影响 InnoDB 缓冲池、OS 缓存等真正决定是否读磁盘的层级。
想强制读磁盘，该动哪几层缓存？
真正决定“数据是否从磁盘读取”的，是 InnoDB 的缓冲池和操作系统的文件系统缓存，而不是那个早已被废弃的查询缓存。遗憾的是，绕过这两层缓存并没有标准的 SQL 语法，需要一些组合操作。
- 清空 InnoDB 缓冲池：可以尝试执行
SET GLOBAL innodb_buffer_pool_dump_now = ON;（可选，用于保存当前状态）加上SET GLOBAL innodb_buffer_pool_load_now = OFF;，然后通过临时调整innodb_buffer_pool_size的大小（比如先调小再调回）来触发缓冲池的重载。但这需要 SUPER 权限，并且会严重影响全局性能，生产环境慎用。 - 绕过 OS 缓存：在 Linux 系统下，可以使用
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"来清空页缓存、目录项和 inode。这是一个危险操作，会清空所有进程的文件缓存，仅限于测试环境。 - 更稳妥的做法：在目标查询执行前，先设法让相关的数据页从缓冲池中“失效”。例如，可以用
SELECT COUNT(*) FROM t FORCE INDEX (PRIMARY) WHERE id BETWEEN ? AND ?;配合一个足够大的范围进行全表扫描，将原有的热点页挤出缓冲池。这种方法虽然不精确，但相对可控。
SQL_NO_CACHE 在哪些版本/配置下还可能起作用？
它的生效范围非常狭窄：仅限于 MySQL 5.6 或更早的版本，并且必须明确开启了查询缓存。如今，这种配置几乎只存在于一些老旧的企业内部系统或遗留的 Docker 镜像中。即便如此，限制也极多。
- 必须同时满足：
query_cache_type = 1、query_cache_size > 0，并且 SQL 必须是确定性的 SELECT 语句（不能包含NOW()、USER()等非确定性函数，或包含这类函数的子查询）。 - 缓存极易失效：只要对表执行了任何写操作（哪怕只是一条简单的
INSERT），该表的所有查询缓存条目都会被立即清除。在这种情况下，SQL_NO_CACHE的存在意义就大打折扣了。 - 作用范围有限：即使
SQL_NO_CACHE生效，也仅仅是阻止该语句的结果被存入查询缓存，而不会“强制走磁盘”。数据读取依然会优先经过 InnoDB 缓冲池，只有缓冲池未命中时，才会真正从磁盘读取。
实际压测或调试时，怎么可靠地模拟“首次读盘”？
别再把希望寄托在 SQL 提示词上了，可靠的方法是直接控制环境状态。最干净、最可复现的方式，就是在重启 MySQL 实例后立刻执行目标查询——此时缓冲池和操作系统缓存都是空的。当然，这显然不适用于生产环境。
- 在开发/测试机上：使用
mysqladmin shutdown关闭服务，然后重启 mysqld，连接后立即运行你的SELECT ...语句。同时，可以通过SHOW ENGINE INNODB STATUS\G查看Buffer pool hit rate来确认是否真的发生了缺页（page fault）。 - 不想重启服务？ 可以尝试一个低权限方案：创建一张新表
t_test，导入数据后立刻执行一次全表扫描（如SELECT COUNT(*) FROM t_test;），然后删除该表。这样可以确保缓冲池里没有该表的任何数据页，后续的查询就能触发真实的磁盘 I/O。 - 注意硬件差异：SSD 和 HDD 对“首次读盘”的延迟影响天差地别。同一句 SQL 在不同硬件上观察到的耗时，不能直接拿来对比。
说到底，真正的难点不在于记住某个关键字，而在于厘清每一层缓存的生命周期和控制边界。很多人困惑于“为什么加了没用”，根源往往是没搞清楚自己面对的究竟是哪一层缓存机制。
