10

我在一个项目的查询缓存方面遇到了很多麻烦：我正在运行 MySQL 的 Percona 风格，在我的本地开发机器上和生产服务器上的版本相同。现在，启用查询缓存在我的本地机器上给了我很好的结果：几乎所有应该缓存的查询，实际上都是。

现在，生产服务器上没有缓存完全相同的查询。一切都一模一样；mysql 变量、数据库内容、代码库、登录用户……但在生产环境中，只有少数查询被缓存，最重要的查询都被跳过了。而且我不知道为什么:-)

因此，在寻找解决方案时，我正在使用以下查询，用于从主题表中选择最新的 3 个主题：（这是最“重”的查询，也是我绝对想要缓存的查询！）

SELECT `topic`.* FROM `topics` AS `topic` 
LEFT OUTER  JOIN `topics` AS `topic_helper` 
 ON (`topic`.`id` = `topic_helper`.`id` 
      AND `topic_helper`.`created_on` < `topic`.`created_on`) 
GROUP BY `topic`.`id` HAVING COUNT(*) < 3 
ORDER BY `topic`.`created_on` DESC;

因此，首先，SHOW VARIABLES LIKE '%query_cache%给我相同的结果，无论是在本地还是在生产中：

+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| have_query_cache             | YES      |
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 10485760 |
| query_cache_strip_comments   | OFF      |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

运行上面的查询在第一次运行后被缓存在本地，这SHOW PROFILE清楚地告诉我它的跟踪接近尾声：

| Waiting for query cache lock   | 0.000001 |
| Waiting on query cache mutex   | 0.000001 |
| freeing items                  | 0.000000 |
| storing result in query cache  | 0.000002 |
| logging slow query             | 0.000001 |
| cleaning up                    | 0.000006 |
+--------------------------------+----------+

第二次调用按预期从缓存中返回查询。

在生产服务器上，运行此查询永远不会将其存储在缓存中。结果集完全相同，并且显然没有使用会使查询缓存无效的语句（根据http://dev.mysql.com/doc/refman/5.1/en/query-cache-operation上的手册.html - 我确定上述查询确实符合缓存要求。）

为了完整起见，SHOW PROFILE生产服务器上相同查询的完整输出粘贴在这里： http: //pastebin.com/7Jm5rmVd

此外，值得注意的是，虽然两台服务器上的配置完全相同，但我的本地版本是 5.5.27，比生产版本 5.5.17-55 上的版本稍新。难道这就是问题..？

我将本地服务器的完整SHOW VARIABLES;输出与生产服务器进行了比较，以查看是否缺少任何内容，但除了系统时区和日志文件的路径等之外，没有什么不同。

那么，你们中的任何人都知道下一步该去哪里寻找吗？或者有任何线索可能导致这种情况？

4

1 回答 1

1

我们在这里经常使用 Percona 服务器，也使用社区 MySQL。

查询缓存功能强大 - 并且非常复杂。MySQL 可能做的最糟糕的事情是返回一些陈旧的缓存数据。

MySQL 不仅缓存查询，还缓存数据库数据——并使用索引来提高性能。

任何可能使查询缓存无效的东西都会使其无效。

作为一个经验法则——我们不会过于关注它是否被缓存……我们相信 MySQL 的行为是智能的——如果出于任何原因它认为某些东西不应该被缓存，它就不会缓存它。我们所做的是确保我们的查询尽可能高效和简单。

如果我可以这样说 - 如果您的示例查询是“您最常用的查询之一”，我认为无论查询缓存如何，您都会遇到严重的可伸缩性问题。一旦服务器忙起来，它就会像没有腿的狗一样跑！

根据您的 pastebin 条目 - 您至少创建了一个临时表，可能是由于外部连接（或 GROUP BY）。

我完全赞成规范化 - 但有时性能需要替代路线。

您不能自己在某种查找/汇总表中缓存其中的一些数据吗？触发器可以在这里成为你的朋友:)

于 2013-03-15T11:05:20.920 回答