【问题标题】:correct results but in different order in sql正确的结果,但在 sql 中的顺序不同
【发布时间】:2014-07-28 13:52:33
【问题描述】:

我有这个问题

 select s.emp_no, min(s.from_date)
 from
 **start** (select s.emp_no
 from salaries s, employees e
 where s.to_date=(select max(to_date) from salaries) and s.emp_no=e.emp_no
 group by s.salary DESC
 LIMIt 10) **end** as emps, salaries s
 where emps.emp_no=s.emp_no
 group by s.emp_no;

start - end 部分是正确的。如您所见,它只有一个包含员工编号的字段。 emp_no 是表薪水的外键。表薪水有 2 个字段。 emp_no 和 from_date。每个 emp_no 可能有多个 from_date 值。我想将每个 emp_no 的所有行从工资中分组,并保留 date_value 中的最小值。这显示了更正的结果(我想),但改变了在 start - end 部分创建的行的顺序。关于保持订单的任何想法?

【问题讨论】:

  • 您可能需要添加样本和所需的结果,但如果您需要特定的订单,您也需要在外部查询中订购。对有序子查询的结果执行的任何无序外部查询都可能将结果重新排列为伪随机顺序。
  • 那么,如何保持外部的顺序与内部的顺序一致?
  • 要回答这个问题,您需要添加一些示例数据和所需的结果,目前还不清楚您希望如何按照原始结果进行分组。

标签: mysql sql mysql-workbench


【解决方案1】:

您没有ORDER BY 子句。如果没有ORDER BY 子句,您就不能期望您的结果集具有特定的顺序。如果您希望您的数据以特定顺序出现,那么您需要以这种方式排序。这可能意味着计算内部表表达式中的列,以允许您正确排序外部结果集。您实际实现排序的方式取决于您的数据以及您需要它的顺序。

更多信息见:

困难的概念是这个。 SQL 规范说结果集行的顺序是不可预测的,除非完全由ORDER BY 子句确定。这个不可预测性是一个很难处理的概念。如果您在查询中遗漏了正确的 ORDER BY 规范,您的行将有时,但并不总是按您期望的顺序出现。通常,当您将应用程序从开发服务器移至生产服务器时,顺序会发生变化。更糟糕的是,当生产服务器中的某些表超过大小阈值时,它可能会在生产数月后发生变化。请小心。

【讨论】:

  • 确实如此。有时,但并非总是GROUP BY 的意外副作用是将结果集按特定顺序排列。
  • 这可能是真的,但是当您可以明确声明您需要以特定方式排序的结果时,为什么还要依赖未记录的、意想不到的后果呢?有很多方法可能会崩溃,我不建议任何人实际使用这些技术。
  • 没错。我的观点是:来自开发服务器的“事情正常”的证据比无用更糟糕。带有错误或缺少ORDER BY 代码的应用程序可能在小型开发服务器上运行良好,并在移动到生产环境时崩溃。更糟糕的是,当某些表超过大小阈值时,它可能会在生产一年后崩溃。两个我都见过。 “有时,但并非总是”,也称为“不可预测”,在实践中是一个很难掌握的概念。
猜你喜欢
  • 2021-11-19
  • 2013-08-09
  • 2020-01-05
  • 2012-08-11
  • 2021-04-03
  • 2011-03-22
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多