sql'select top 1' without 'order by' from view with 'top 100 percent ... order by ...'声明给出了意想不到的结果[重

Posted 2023-02-15

【中文标题】sql\'select top 1\' without \'order by\' from view with \'top 100 percent ... order by ...\'声明给出了意想不到的结果[重复]

【英文标题】：sql 'select top 1' without 'order by' from view with 'top 100 percent ... order by ...' declaration gives unexpected results [duplicate]sql'select top 1' without 'order by' from view with 'top 100 percent ... order by ...'声明给出了意想不到的结果[重复]

【发布时间】：2022-01-07 00:37:28

【问题描述】：

我有以下看法

CREATE VIEW ...
    AS SELECT        TOP (100) PERCENT ...
FROM            ...
INNER JOIN ...
ON ...
WHERE    ...
ORDER BY datetime2 DESC

我还有一个存储过程 SELECT TOP(1) ... FROM ... WHERE ... 没有“ORDER BY”声明。 （我也在修复它）。执行这个usp的程序也在依赖表中写入了很多信息。所以请求可以被执行，而视图得到了新的信息。

首先，我们在视图上执行了一些“SELECT ... WHERE ...”语句，这些语句未排序。为什么不排序，视图应该按datetime2-Column排序。

我期待不带“ORDER BY”附加的“SELECT TOP(1)”语句的混合结果。但实际上，错误的结果比预期的要少，而且是在特定的时期。 4 月 2 天，11 月 2 天。 视图中的数据也是混杂的，应该不是统计原因，为什么结果给我的一些数据比其他的更频繁。

我找不到数据之间的任何联系，在环境中也找不到。 这只是一个不幸的情况吗？一个让我思考的“陷阱”，有联系吗？

有没有办法重现“失败”。 （实际上这是系统的正确行为）？

我希望你有足够的信息来帮助我！如果有问题，我当然会回答。

编辑同一天 - 09:32 UTC： usp 的重要部分是，它将“SELECT TOP(1) ... FROM ... WHERE ...”的结果插入到表中。周围没有条件。

【问题讨论】：

为什么你有一个VIEW 和一个ORDER BY？排序应该在VIEW 的外部完成，而不是在它里面。

至于你的问题，我不确定是什么？你似乎知道你的程序（我们没有定义）写得不好，所以为什么不直接修复它呢？

@Larnu 我没有写视图，我只是想了解这个声明背后的问题。并且必须修复它：P 编辑：是的，如果我们只是修复它，就不应该再有异常了，但是如果有可能理解和重现问题，那就太好了。

重现什么问题？您是在谈论您的陈述“为什么它未排序，视图应该按 datetime2-Column 对其进行排序。”？错误，VIEW 未排序；带有ORDER BY 的TOP (100) 是一个无证的杂物，不能保证工作。在VIEW之外订购您的数据。

优化器现在已经足够聪明了，它知道TOP 100 PERCENT 可以在不执行任何排序的情况下计算出来。视图固有地是未排序的（就像表格一样）。

【参考方案1】：

ORDER BY 是一个“美观”的 SQL 子句，它只在查询的完整 SQL 处理之后显示行之间的顺序。因为引擎没有“顺序”来操作查询计划中使用的不同算法，所以行被随机放置在结果集中。

View 不排除这条规则，因为在任何时候，您都可以在 SELECT from view(s) 上添加 ORDER BY 子句。

所以 ORDER BY，在查询中设置的任何技巧都不会影响最终的 SQL 命令：SELECT、INSERT、MERGE、UPDATE 或 DELETE。

在使用视图或表的 UDF 时，查询中绝对没有默认顺序...