MySQL 查询缓存 (2)答案

【问题标题】：MySQL Query Caching (2)MySQL 查询缓存 (2)
【发布时间】：2012-06-19 11:40:42
【问题描述】：

这不是问题，但它属于网站优化。我有 110K 的酒店记录。当我使用 SELECT something 查询时，它会从 110k 记录中提取数据。

如果我搜索超过 3 星评级的酒店列表，价格在 100 - 300 美元之间，并且在墨西哥城内。假设我得到了 45 个匹配结果。

当我添加更多细化时，是否有其他方法，它会从仅 45 个匹配中提取数据而不与 110K 数据一起使用？

【问题讨论】：

您使用什么查询？给我们看一些代码
也许有不同的方法而不是使用SELECT ... FROM ... WHERE ... ORDER BY ...？但为什么？哪个是问题？如果您的数据库设计良好，您的查询应该很快......
使用正确的索引，发送 sql 代码只会返回正确的结果，因此您可以有 110,000k 条记录，然后说 5 条返回......而且速度很快......它会出现错误的索引返回缓慢，没有 where 子句，它们都回来了，你的本地代码必须完成所有工作
您应该使用WHERE 和索引。向我们展示您的架构和查询，我们可以提供更多帮助。

【解决方案1】：

关键是我的朋友的索引...确保您拥有 WHERE 中使用的所有项目的索引，这将减少选择时的基数...

另一方面... 110k 行对于 MySQL 来说仍然是一个非常小的数据集，因此如果您没有在表上获得正确的索引，则不会造成太大的性能问题。

【讨论】：

【解决方案2】：

这更多取决于您的数据更新频率。

看。

我是说当我添加更多细化时还有其他方法吗？将仅从 45 个匹配项中提取数据，而不是与 110K 数据。

然后查看这 45 行并对其应用查询。

【讨论】：

【解决方案3】：

使用查询创建视图

Create view refined as select * from ....

然后向该视图添加更多选择查询喜欢

 Select * from refined where ...

【讨论】：

【解决方案4】：

首先，我倾向于同意Brian，索引很重要。

检查最频繁的查询类型，并相应地在表上构建多列索引。请注意，索引中列的顺序确实很重要（因为索引是一棵树，第一列出现在树根中，所以如果您的查询不使用该列 - 整个树都是无用的）。
启用慢查询日志以查看哪些查询实际上需要很长时间（如果有），或者不使用索引，这样您就可以随着时间的推移改进索引。

话虽如此，查询缓存确实可以提升性能，如果您的表数据主要被读取。这是mysql查询缓存上的useful article。

【讨论】：