怎么在查询时绕过缓存直接读取磁盘 SQL_NO

不能，mysql 8.0 已移除查询缓存，5.7 默认禁用，sql_no_cache 被静默忽略；它仅对已废弃的查询缓存有效，不影响 innodb 缓冲池、os 缓存等真正决定是否读磁盘的层级。

不能，而且很可能完全没效果——因为 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 'have_query_cache'; —— 若返回 NO，说明编译时就没带
即使返回 YES，也要看 query_cache_type 是否为 ON（值为 1），且 query_cache_size > 0
SQL_NO_CACHE 只对「查询缓存」起作用，对 InnoDB 缓冲池（innodb_buffer_pool）、操作系统页缓存、客户端连接层缓存全无效

真正影响“是否从磁盘读”的是 InnoDB 的缓冲池和 OS 文件系统缓存，不是那个早已废弃的查询缓存。绕过它们没有标准 SQL 语法，得靠组合操作。

清空 InnoDB 缓冲池：执行 SET GLOBAL innodb_buffer_pool_dump_now = ON;（可选）+ SET GLOBAL innodb_buffer_pool_load_now = OFF;，再用 SET GLOBAL innodb_buffer_pool_size = 1024*1024;（临时调小再调回）触发重载——但需 SUPER 权限，且影响全局性能
绕过 OS 缓存：Linux 下可用 sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"，但这是危险操作，会清空所有文件缓存，仅限测试环境
更稳妥的做法：在查询前先让目标页“失效”，比如用 SELECT COUNT(*) FROM t FORCE INDEX (PRIMARY) WHERE id BETWEEN ? AND ?; 配合大范围扫描，把热点页挤出缓冲池（不精确但可控）

仅限 MySQL 5.6 或更早、且明确开启查询缓存的实例——现在几乎只存在于老旧政企系统或遗留 Docker 镜像里。即便如此，也受限极多。

必须同时满足：query_cache_type = 1、query_cache_size > 0、SQL 是确定性 SELECT（不能含 NOW()、USER()、子查询含非确定函数等）
如果表发生任何写操作（哪怕只是 INSERT INTO t VALUES ()），对应表的所有缓存条目都会被立即清除，SQL_NO_CACHE 就失去存在意义
使用 SQL_NO_CACHE 后，该语句不会被缓存，但也不会“强制走磁盘”——InnoDB 仍优先查缓冲池，查不到才读磁盘

别依赖 SQL 提示，要控制环境状态。最轻量且可复现的方式是重启 MySQL 实例后立刻执行目标查询——此时缓冲池和 OS 缓存都是空的。但生产环境显然不能这么干。

开发/测试机上：用 mysqladmin shutdown + 重启 mysqld，再连上去跑 SELECT ...，配合 SHOW ENGINE INNODB STATUS\G 查 Buffer pool hit rate 确认是否真缺页
不想重启？用低权限方案：建一张新表 t_test，导入数据后立刻执行一次全表扫描 SELECT COUNT(*) FROM t_test;，再删表——这样能确保缓冲池里没它的页，后续查就是真实磁盘 I/O
注意：SSD 和 HDD 对“首次读盘”的延迟差异极大，同一语句在不同硬件上观察到的耗时不能直接对比

真正难的不是加个关键字，而是厘清每一层缓存的生命周期和控制边界。很多人卡在“为什么加了没用”，其实是根本没弄清自己面对的是哪一层缓存。