SQL Server 2000和2012之间的数据sorting更改

SQL Server 2012不保证在SQL 2012中返回的行的顺序。对于这一点，2000也没有。 （我发现的引用实际上是2005年 ，但足够接近。）

本质上，SQL Server查询优化器确保查询树中的内部操作符将按特定顺序处理其input。 没有相应的保证，该运算符的输出将暗示查询树中的下一个运算符按该顺序执行。 重新sorting规则可以并且将违反这个假设（并且在对你不方便的时候这样做，开发者;）。 请理解，当我们重新sorting操作以find更有效的计划时，可以使树中的中间节点的sorting行为发生改变。 如果你已经把一个操作放在假定特定中间顺序的树中，它可能会中断。

基本上：你到现在为止幸运，它终于咬你。

Itzik Ben-Gan的这篇文章可以帮助你。 一个样品：

Cantor的定义暗示了其中一个最重要的方面。 他没有提到集合中元素的顺序，因为顺序并不重要。 这是人们在查询表格时最难理解的概念之一，也就是说，不能保证被查询的数据将以特定的顺序被消费。 例如，有些人认为当他们查询一个具有聚集索引的表时，他们会以聚集索引顺序返回数据。 从语言的angular度来看，这并不能保证，因为你所查询的是一个集合，而你所得到的是一个集合。 SQL Server知道该语言没有提供任何顺序保证，因此它以任何喜欢的顺序扫描数据，包括不以聚簇索引顺序。 人们经常使用违反基于集合和关系概念的技术，因为结果的正确性依赖于以索引顺序使用的数据，这是SQL Server从未保证的。 我在我的networking独家文章“ 多行variables赋值和ORDER BY ”和“ 有序运行聚合的更新和基于集合的解决scheme ”中介绍了几个经典示例。

本甘撰写了SQL Server 70-461培训手册，并强调了这一点。

我希望我有更好的东西来告诉你，但是…不，没有“默认顺序”，因此你不应该依赖它，它没有logging。

订单的集合是未定义的和无证的 。 在这种情况下，“无证”意味着两件事情：

1. 我们将无法为您提供具体的链接或引用详细的更改或新的行为将是什么，因为它是明确的没有声明。 这是通过devise ，并根据关系“集”的概念。
2. 由于没有logging，Microsoft随时可以随时更改其行为。 通过Windows更新提供的其他不起眼的修补程序可以改变这一点（不是它有，但它可以不违反任何政策）。 即使你今天剔除了一个特定的行为，你也不应该依赖它，因为它可能在没有任何警告的情况下改变。

这种自由对于微软这样的数据库厂商来说非常重要 这使他们有能力在其产品中进行创新并使性能发生积极变化。

这使我想到了下一点。 很长一段时间，有一种想法是，没有ORDER BY子句的查询将返回与查询中主表的主键（聚簇索引）一致的结果。 这是错误的 ，一直是错误的。 结果通常以这种方式返回，但仅仅是因为这通常是最快的方式来服务查询。 但是总是有这样的例外：包括索引，循环表扫描，复杂的联接和子查询，根据这个月编译的统计信息，查询的“主”表可能会改变。

近年来，像recursionCTE，窗口函数和APPLY操作这样的新概念创造了许多新的情况，其中聚集索引顺序不再是查询服务的最快方式。 这种影响不仅限于使用这些新function的查询。 由于查询引擎增加了复杂性以适应新的function，因此它获得了新的工具来支持这些function，这些function在为旧查询准备计划时也很有用。

只是添加更多在SQL 2K8企业有一个新的function称为梅里四处转转。
这个function在本质上重用了来自其他线程的表扫描查询。
http://www.sanssql.com/2013/07/merry-go-round-scans-in-sql-server.html