2

事情就是这样。我有 3 个表，我正在做这个查询：

select t.nomefile, t.tipo_nome, t.ordine
from
(select nomefile, tipo_nome, categorie.ordine
from t_gallerie_immagini_new as immagini
join t_gallerie_new as collezioni on collezioni.id=immagini.id_ref
join t_gallerie_tipi as categorie on collezioni.type=categorie.id
order by RAND()
) as t
group by t.tipo_nome
order by t.ordine

它应用于 3 个表，都在关系 1-N 中，需要将它们连接起来，然后从更高级别表中的每个不同结果中获取 1 个随机结果。这个查询工作得很好，问题是我被要求重写这个查询USING ONLY ONE SELECT。我已经有了另一种方法，只有一个选择，问题是根据 SQL 语法，GROUP BY 必须在 ORDER BY 之前，所以当你已经只有第一条记录时，随机排序是没有意义的更高级别表中的值。

有人知道如何仅使用一个选择来编写此查询吗？

4

2 回答 2

2

一般来说，如果我没记错的话，ORDER BY像这样的查询的子查询中的子句与允许您根据指定的顺序提取非 GROUP BY 列（在外部查询中）的技术有关。所以你在这里可能不走运，因为这意味着子查询对于这个查询很重要。

好吧，因为在这种特定情况下，选择的顺序是BY RAND()而不是特定列/列集，所以通过在同一级别上进行连接和分组，您可能会得到一个非常粗略的等价物，如下所示：

select nomefile, tipo_nome, categorie.ordine
from t_gallerie_immagini_new as immagini
join t_gallerie_new as collezioni on collezioni.id=immagini.id_ref
join t_gallerie_tipi as categorie on collezioni.type=categorie.id
group by tipo_nome
order by categorie.ordine

但是，您必须了解为什么这不是完全等价的。问题是，MySQL 确实允许您在 GROUP BY 查询中提取非 GROUP BY 列，但如果它们与 GROUP BY 列不相关，则返回的值将是......不，不是随机的，使用的术语按手册是不确定的。另一方面，第一段中提到的技术利用了这样一个事实，即如果行集在 grouping 之前明确且明确地排序，则非 GROUP BY 列值将始终相同*。因此，不确定性与“通常”行在分组之前没有明确排序的事实有关。

现在您可能会看到不同之处。原始版本明确地对行进行排序。即使它是BY RAND()，它也是故意的，以确保（尽可能）在大多数情况下输出不同的结果。但是修改后的版本被“剥夺”了显式排序，因此您可能会连续多次执行相同的结果，即使它们是“随机的”。

因此，总的来说，由于上述原因，我认为您的问题无法解决，如果您选择使用建议的修改版本之类的东西，那么请注意它的行为可能与原始版本略有不同。

*顺便说一句，该技术可能没有得到很好的记录，并且可能是通过经验而不是通过遵循手册找到的。

于 2012-05-22T10:20:05.730 回答
1

我无法理解重写此查询的请求背后的原因，但是，我发现有一个解决方案只使用一次“选择”字。这是查询：

SELECT g.type, SUBSTRING_INDEX(GROUP_CONCAT(
i.nomefile ORDER BY
RAND()),',',1) nomefile
FROM t_gallerie_new g JOIN t_gallerie_immagini_new i ON g.id=i.id_ref
GROUP BY g.type;

对于任何对此问题感兴趣的人。

注意：使用 GROUP_CONCAT 有几个缺点：不建议在使用中型/大型表时使用此关键字，因为它可能会增加服务器端的负载。另外，GROUP_CONTACT 返回的字符串的大小有一个限制，默认为 1024，因此，需要在 mySql 服务器中修改一个参数，以便能够从该指令接收更大的字符串。

于 2012-05-25T12:06:52.973 回答