Jus*_*ier 91
这是不必要的.您可以使用a ORDER BY并只更改排序DESC以获得相同的效果.
Tom*_*m H 82
SELECT
columns
FROM
(
SELECT TOP 200
columns
FROM
My_Table
ORDER BY
a_column DESC
) SQ
ORDER BY
a_column ASC
Mar*_*ger 36
对不起,但我认为我认为没有看到任何正确的答案.
该TOPX功能显示在未确定的订单记录.从该定义可以看出,BOTTOM无法定义函数.
独立于任何索引或排序顺序.当你这样做时,ORDER BY y DESC首先得到y值最高的行.如果这是一个自动生成的ID,它应该显示最后添加到表中的记录,如其他答案中所建议的那样.然而:
TOP功能进行比较,则会对性能产生重大影响正确的答案应该是没有,也不可能等同TOP于获得底行.
Sha*_*uti 16
从员工中选择Bottom 1000
DECLARE
@bottom int,
@count int
SET @bottom = 1000
SET @count = (select COUNT(*) from Employee)
select * from Employee emp where emp.EmployeeID not in
(
SELECT TOP (@count-@bottom) Employee.EmployeeID FROM Employee
)
小智 10
似乎在解决方案中实现 ORDER BY 子句的任何答案都没有抓住重点，或者实际上并不了解 TOP 返回给您的内容。
TOP 返回一个无序查询结果集，该结果集将记录集限制为返回的前 N 条记录。（从 Oracle 的角度来看，它类似于添加一个 where ROWNUM < (N+1)。
任何使用顺序的解决方案都可能返回也由 TOP 子句返回的行（因为该数据集首先是无序的），具体取决于顺序中使用的条件
TOP 的用处在于，一旦数据集达到特定大小 N，它就会停止获取行。您无需获取所有数据即可了解数据的外观。
为了准确地实现 BOTTOM，它需要无序地获取整个数据集，然后将数据集限制为最后的 N 条记录。如果您正在处理大表，这将不会特别有效。它也不一定会给你你认为你要求的东西。数据集的结尾可能不一定是“最后插入的行”（对于大多数 DML 密集型应用程序可能不会）。
同样，不幸的是，实现 ORDER BY 的解决方案在处理大型数据集时可能是灾难性的。如果我有 100 亿条记录并且想要最后 10 条记录，那么订购 100 亿条记录并选择最后 10 条记录是非常愚蠢的。
这里的问题是，当与 TOP 比较时，BOTTOM 没有我们想到的含义。
当记录被一遍遍地插入、删除、插入、删除时，存储中会出现一些间隙，然后，如果可能的话，将插入行。但是我们经常看到，当我们选择 TOP 时，似乎是排序的数据，因为它可能在表存在的早期就已经插入了。如果表没有经历很多删除，它可能看起来是有序的。（例如，创建日期可能与表创建本身的时间一样早）。但实际情况是，如果这是一个需要大量删除的表，则 TOP N 行可能根本不是这样。
所以 - 这里的底线（双关语）是要求 BOTTOM N 记录的人实际上并不知道他们在要求什么。或者，至少，他们的要求和 BOTTOM 的实际含义不是一回事。
所以——该解决方案可能满足请求者的实际业务需求……但不符合作为底层的标准。