问题标签 [query-optimization]

好的，所以我有一个非常可怕的 MySQL 表（900k 记录，总共 180 MB），我想从子组中提取更高的记录date_updated并计算每个组的加权平均值。计算运行约 15 个小时，我有一种强烈的感觉，我做错了。

首先，巨大的桌子布局：

• category
• element_id
• date_updated
• value
• weight
• source_prefix
• source_name

这里唯一的关键是element_id（BTREE，~8k 独特元素）。

及计算过程：

为每个组和子组进行哈希。

我真的不明白这种对哈希的大惊小怪，但这种方式工作得更快。暗魔法，我猜。

查找每个子组的最大日期

将 temp1 与 temp2 连接以查找类别的加权平均值

（现在我浏览了它并将其全部写下来，在我看来，我应该在最后一个查询中使用 INNER JOIN（以避免 900k*900k 临时表））。

不过，有没有正常的方法可以做到这一点？

UPD：一些图片供参考：

删除了无效的 ImageShack 链接

UPD：解释建议的解决方案：

我想以最有效的方式从一个表中选择与另一个表中的“一个或多个”行匹配的所有行。

目前，如果有多个匹配任务，这会多次返回相同的身份（但稍后消除这些的性能损失并不算太糟糕）。我希望它只为每个身份返回一行，它与这些任务组中的一个或多个匹配，我想知道是否有比 DISTINCT 或 GROUP BY 更有效的方法。

使用 DISTINCT 或 GROUP BY 的问题在于，仍然会扫描任务表以查找所有 groupid 匹配项，然后通过临时表（有时使用文件排序）将它们减少为一个。我宁愿它进行某种短路评估-在找到相同身份后，不要进一步追求任何后续任务匹配。

我正在考虑做一个 EXISTS 子查询，但我不知道这些是如何优化的。我需要它在身份表之前先加入任务表，所以我没有对身份表进行全面扫描，该表非常大并且会有很多不匹配。

我有一个有两个索引的表，其中一个是某个查询的更快覆盖索引。但是，mySQL (5.1) 没有选择正确的索引。我已经查看了这个查询的解释并做了一些速度测试，如果你强制使用它会产生很大的不同。

有什么方法可以检查它如何选择索引以及它基于什么标准？

数据库

询问

此查询当前需要大约 2 秒才能运行，这太长了。在 id 列上有一个索引，在 Start_time+duration/24 上有一个函数索引。在 Sql Developer 中，查询计划显示没有使用任何索引。该查询为我的测试开始和结束时间返回 475 行。Table2 有 ~800k 行 Table1 有 ~200k 行

如果从查询中删除持续时间/24 计算，将其替换为静态值，则查询时间将减少一半。这不会检索完全相同的数据，但让我相信除法成本很高。

我还测试了向 Table2 添加一个 endtime 列，该列填充有 (starttime + duration/24) 该列是通过单个更新预填充的，如果它将在生产中使用，我将通过更新触发器填充它。

此查询将在大约 600 毫秒内运行，并且它使用索引进行连接。由于具有冗余数据的附加列，它不太理想。

有什么方法可以让这个查询更快吗？

我有一个将用户排名作为中心部分的网站，但用户数量已增长到超过 50,000 人，这给服务器带来了压力，以每 5 分钟循环一次更新排名。有没有更好的方法可以用来轻松地至少每 5 分钟更新一次排名？它不必与 php 一起使用，它可能是像 perl 脚本一样运行的东西，或者如果类似的东西能够更好地完成工作（虽然我不确定为什么会这样，只是离开我的选项在这里打开）。

这是我目前更新排名的方法：

更新（解决方案）：

这是解决方案代码，执行和更新所有 50,000 行所需的时间不到 1/2 秒（按照 Tom Haigh 的建议对主键进行排名）。

我发生了一件奇怪的事情。我在 C# ADO.NET 应用程序上运行探查器时得到的第一个查询。它所做的并不像传递参数的方式那么有趣 - 此查询需要 250 多秒才能完成，但是当我通过更改参数传递方式来修改它（查询 1）时（请参阅查询 2），然后它需要 <0.001 秒才能完成。

这里有什么玩意？我们可以做些什么来强制 ADO.NET 生成更优化的查询？

我有一个查询：

SELECT a.nick,grp,count(*) FROM help_mails h JOIN accounts a ON h.helper=a.id WHERE closed=1 GROUP BY helper, grp, a.nick

这个加入有什么问题？当我提出 2 个查询时：

SELECT helper,grp,count(*) FROM help_mails h WHERE closed=1 GROUP BY helper, grp; SELECT nick FROM accounts WHERE id IN (...) 它快 100 倍。

解释返回这个：

accounts.id、help_mails.grp 和 help_mails.closed 获得了索引。

我有一个 mysql (5.0.22) myisam 表，其中大约有 300k 条记录，我想在 5 英里半径范围内进行纬度/经度距离搜索。

我有一个涵盖纬度/经度字段的索引，当我只选择纬度/经度时，它的速度很快（毫秒响应）。但是当我选择表格中的其他字段时，速度会慢到 5-8 秒。

我正在使用 myisam 来利用全文搜索。其他索引表现良好（例如 select * from Listing where slug = 'xxxxx'）。

如何优化查询、表或索引以加快速度？

我的架构是：

我的查询是：

解释没有地理搜索的计划：

用地理搜索解释计划：

这是带有覆盖索引的解释计划。以正确的顺序排列列会产生很大的不同：

谢谢！

我面临一个问题，即运行存储过程占用过多资源，这有时会导致服务器超时（尤其是当 CPU 使用率超过 90% 时）。

谁能建议最好和最快的方法是发现占用大量资源的块，并提出解决它的好方法，好吗？

• 我正在使用 SQL Server 2005

我知道 SQLite 本身并不强制执行外键，但这不是我最关心的问题。问题是：如果我声明

sqlite至少会使用clientID是外键的信息来优化查询并自动索引invoice.clientID，还是这个约束是真正的无操作？