为什么SSMS在表格顶部而不是底部插入新行？

每当我在SQL Server Management Studio 2008（数据库是SQL Server 2005）中的表中手动插入一行时，新行就会出现在列表的顶部而不是底部。我正在使用标识列，这会导致类似

id  row
42 first row
1 second row
2 third row

当获取行且未明确对其进行排序时。当为Web应用程序获取行并更改TOP 1查询返回的内容时，这将导致外观不同。

我知道我可以order by，但是为什么会这样呢？我的大部分数据都是通过Web应用程序插入的，来自此应用程序的所有插入都将按照先进先出的顺序进行，例如最新插入在底部，因此id都排成一行。服务器或Management Studio中是否有某些设置会导致这种不正确的订购？

在SQL世界中，顺序不是一组数据的固有属性。因此，除非您使用ORDER BY子句查询数据，否则RDBMS不能保证您的数据将以特定顺序（甚至是一致的顺序）返回。

来自Craig Freedman：

将TOP与ORDER BY结合使用可将确定性添加到返回的行集中。如果没有ORDER BY，则返回的行集取决于查询计划，甚至可能因执行而异。

ORDER BY如果期望结果集中定义明确且一致的顺序，请始终使用。永远不要依赖数据库如何将行存储在磁盘上（例如，通过聚集索引）来保证查询中数据的特定顺序。

只是为了补充其他答案：根据定义，表是无序的行集。如果不指定ORDER BY子句，SQL Server可以自由选择以最有效的顺序返回行。由于大多数表在身份，日期时间或其他单调递增的列上都有聚集索引，所以这通常恰好与插入顺序一致，但是您应该将其视为完全相同：一个巧合。它可以随着新数据，统计信息更新，跟踪标志，对maxdop的更改，查询提示，对联接或查询中的where子句的更改，由于Service Pack /累积更新/修补程序/升级而对优化程序的更改，将数据库移动到其他服务器等。

换句话说，我知道您已经知道答案了，但是还不能完全说明：

如果要依赖查询的顺序，请始终添加 ORDER BY。

这是因为该表是堆表（最有可能）并且未建立索引。将ID列PRIMARY KEY设为和IDENTITY。SQL Server物理上根据索引存储数据-例如，如果id是聚簇索引（例如主键），则数据将按照id的顺序进行物理存储，并且即使没有一个ORDER BY条款。否则，行的排序对数据库根本不重要。因此，让应用程序依赖于数据库中行的顺序（以及依赖于以特定顺序排列的列）并不是一个好习惯。应用程序需要使用数据库中存在的任何键来识别行。