mysql查询和性能答案

【问题标题】：mysql query and performancemysql查询和性能
【发布时间】：2011-05-22 20:07:23
【问题描述】：

我想知道如果我在以下条件下运行此查询对性能的影响。

查询：

select   `players`.*, count(`clicks`.`id`) as `clicks_count` 
from     `players` left join `clicks` on `clicks`.`player_id` = `players`.`id`
group by `players`.`id`
order by `clicks_count` desc 
limit    1

条件：

在我希望得到的 clicks 表中 1分钟插入1000次
clicks 表将包含更多然后是 1,000,000 行
玩家表将包含 10,000 行
玩家表每 5 次插入一次分钟

如果我在 1 分钟内运行查询 1000 次，我想知道性能方面的预期。

谢谢

【问题讨论】：

如果不知道很多关于您的服务器和设置的事情，就不可能说出来。为什么不简单地尝试一下？
@Yonathan，这样的查询看起来不错，在您真正遇到慢速之前不要担心性能，而不是回来询问有关它的一些细节问题。 “过早的优化是万恶之源” -- Donald Knuth.
好的，谢谢。一如既往的Trial and error!
如果事情变得缓慢，EXPLAIN 有时可以为您提供有关查询是如何完成的线索。这是一个友好的基于树的版本：xaprb.com/blog/2007/07/29/introducing-mysql-visual-explain
确保使用事务。每秒 1000 个 INSERTS 和每秒 1000 个 COMMITS 之间存在很大差异（祝你好运！）。还要决定哪个更重要——插入或查询。索引将加速查询（如果覆盖正确），但需要更多的工作来维护。额外的索引可能实际上会损害查询（如果它们破坏了计划）和插入性能。

标签： mysql sql sql-server performance

【解决方案1】：

该查询将永远在您的表中包含任何有意义的数据量时在几毫秒内运行。它将运行两次全表扫描，将两者连接在一起，聚合混乱，并从中获取第一行。

使用触发器将总数存储在播放器中，并索引该字段。然后您就可以完全避免加入：

select p.* from players p order by clicks_count desc limit 1

【讨论】：

我喜欢带触发器的想法，你能告诉我如何根据我的情况声明一个吗？我不熟悉触发器
如果只用 clicks_count 添加到 player 表列，每次点击只加 1 会比触发器更好吗？
是的，这正是 Denis 所写的，添加该列并通过触发器或单独的更新查询为每次点击添加 1 来更新它。如果您不需要存储有关点击的额外信息，例如日期、点击者等，您甚至可以删除 clicks 表并在播放器中更新 clicks_counter。
@Denis when you write 那个查询永远不会在毫秒内运行那么它会变得更糟吗？
@yonathan：有数百万和数十亿行，它将运行到几分钟、几小时和几天。

【解决方案2】：

首先，如果您想要在如此多的记录和频繁写入的情况下获得良好的性能，您应该担心您的架构；即，如果还没有适当的索引和约束，则必须创建。

接下来，查询本身，选择所需的最少字段数（因此，如果您不需要 ALL player 字段，请避免使用“players.*”）。

个人偏好，我会重组表格（例如用 playerID 代替 id）并像这样查询：

SELECT p.*, COUNT(c.id) as clicks_count
FROM players p
JOIN clicks c USING(playerID)
GROUP BY p.playerID
ORDER BY clicks_count desc 
LIMIT 1

再次，看看您是否真的需要所有玩家表字段；如果不是，则省略“p.*”并替换为 p.foo、p.bar 等。

【讨论】：

感谢您的提示。但我想知道这种情况是否正常，应该如何处理以及我该如何处理
好吧，你正在处理一个大的记录集和频繁的写入 - 看看它是如何进行的（在生产中），大声笑，很好的建议 ;--) 我说提前计划（所以创建 PK玩家表中的 playerID 并在 clicks 表中的 playerID 上添加 FK；然后选择必要的最少字段；将读取查询设置为只读；分配足够的 cpu 周期和内存来处理负载，在将任何东西投入生产之前由负载测试确定）
很公平，当然，我们都对他的情况一无所知。 @denis 已经针对单个表进行了性能方面的查询