MySQL SQL_NO_CACHE不能正常工作

我有一个表（InnoDB）插入，更新和频繁阅读（通常在几毫秒的爆发）。 我注意到，有时INSERT / UPDATE之后的SELECT语句会得到陈旧的数据。 我认为这是由于caching，但在把SQL_NO_CACHE放在它之前并没有真正做任何事情。

你如何确保SELECT始终等到先前的INSERT / UPDATE结束而不从caching中获取数据？ 请注意，这些语句是从单独的请求中执行的（不在相同的代码执行中）。

也许我误解了什么SQL_NO_CACHE实际上…

更新 ：

@Uday，INSERT，SELECT和UPDATE语句如下所示：

INSERT myTable (id, startTime) VALUES(1234, 123456)

UPDATE myTable SET startTime = 123456 WHERE id = 1234

SELECT SQL_NO_CACHE * FROM myTable ORDER BY startTime

我尝试使用交易没有运气。

更新 ：

我认为这实际上是INSERT的问题，而不是更新。 SELECT语句总是试图获取按时间sorting的最新行。 但是由于INSERT不执行任何表级locking，所以SELECT可能会得到旧数据。 有没有办法强制执行表级locking时执行插入？

Answer 1

查询caching不是问题。 写入使caching无效。

MySQL优先写入，并且使用默认的隔离级别（REPEATABLE READ），您的SELECT将不得不等待UPDATE完成。

如果你为MyISAM启用了CONCURRENT INSERTS， INSERT可以被区别对待，InnoDB也使用logginglocking，所以它不需要等待表的插入。

难道这是一个竞争条件呢？ 你确定你的SELECT发生在UPDATE之后吗？ 你是否从一个复制服务器读取更新尚未传播？

如果问题是使用并发INSERT，则需要在MyISAM上禁用CONCURRENT INSERT，或者在INSERT期间使用LOCK TABLES显式locking表。 InnoDB的解决scheme是相同的，用LOCK TABLES显式地lockingINSERT上的表。

Answer 2

一个）
如果您根本不需要caching（对于任何SELECT），请完全禁用查询caching。

B）
如果你只想要一个会话，你可以像“set session query_cache_type = 0;” 这将为此次会议设定。

另外在任何情况下都使用SQL_NO_CAHCE。