没有指定order by 排序，同一条SQL（查询条件的值不同，也就是说不是同一天的数据），为什么查出来的数据顺序不同啊

问题，如题目所示

环境：winXP SP3，数据库服务器是MSDE，数据库客户端microsoft SQL Server Manegement Studio2005
      这些，都在我的机器上，只有我用我的机器，没有其他人连接我的数据库。
      （我的环境都是日文环境，下面的叙述可能多少和中文环境有些语言上的出入，不理解的请问我）

SQL文如下：
SELECT DISTINCT
    dbo.POSTotalSectionSales.ShopCode, dbo.POSTotalSectionSales.SalesDate, dbo.POSSectionMaster.SectionCode,
    dbo.POSSectionMaster.Name, SUBSTRING(dbo.POSSectionMaster.SectionCode, 1, 1) AS Type
FROM    dbo.POSSectionMaster CROSS JOIN
        dbo.POSTotalSectionSales
where dbo.POSTotalSectionSales.SalesDate = '2009/10/12'

dbo.POSSectionMaster表里只有SectionCode和Name，共21G条数据，就是各个部门的名称，主KEY是SectionCode。
dbo.POSTotalSectionSales表里，有ShopCode,SalesDate,SalesHour,SectionCode,Name,Type,Count,Amount,
主KEY是（ShopCode,SalesDate,SalesHour,SectionCode,），表中有很多天的数据，
但是POSTotalSectionSales.ShopCode字段可以无视，因为这个字段的内容都是同一个商店CODE。

现在分别执行两次这个SQL文，
第一次，设定查询条件SalesDate = '2009/10/12'
第二次，设定查询条件SalesDate = '2009/10/13'

现象：第一次的查询结果，是乱序的，第二次的查询结果，是按照SectionCode排好序的，
      看了看执行计划，这两次查询，不同的地方是，第一次有个Hash Match(aggregate)，第二次有个Sort(Distinct Sort)
      （其他的日期也反复的查询了几次，和第二次一个样，按照SectionCode排序的，执行计划里面也有个Sort或者Sort(Distinct Sort)）
问题：
     为什么同一条查询语句，只有查询的条件值不同，出的结果的排序会不同呢

50 个解决方案

#1

那天才讨论了这个问题

没有order by排序的时候是按照本身的物理逻辑来进行排序的

#2

引用 1 楼 fredrickhu 的回复:

那天才讨论了这个问题

没有order by排序的时候是按照本身的物理逻辑来进行排序的

......

#3

专业围观

#4

问题：
为什么同一条查询语句，只有查询的条件值不同，出的结果的排序会不同呢

可能因为前面其它字段的排序问题导致,数据都不一样的,好好检查下,

弄点数据来看看

#5

先去掉distinct看看结果怎样？
因为distinct会引起排序的。

#6

to fredrickhu
那就很奇怪了
为什么那么多天的数据，单单10/12那天的数据特殊呢？实在想不明白。
数据是客户那里拿过来的。

本身的物理逻辑------好象这么解释也不太让客户明白啊。

#7

http://topic.csdn.net/u/20091021/10/2171c105-e6aa-4fcf-aec7-b850d3de6539.html

你的这个帖子里面已经够明白了

#8

dbo.POSSectionMaster
SectionCode Name
00000 利用料金
10001 物品
10002 たばこ
10003 食品
10004 飲料
10005 シャワールーム
10006 女性販売
20001 DVD
20002 PS2
略

ShopCode SalesDate SalesHour SectionCode Name Type Count Amount
026 2009/10/12 2009/10/12 11:00 00000 利用料金 1 50 12800.0000
026 2009/10/12 2009/10/12 11:00 10003 食品 1 1 50.0000
026 2009/10/12 2009/10/12 12:00 00000 利用料金 1 47 18300.0000
026 2009/10/12 2009/10/12 12:00 10003 食品 1 4 630.0000
026 2009/10/12 2009/10/12 12:00 30002 ポイントカード割引 1 3 -2100.0000
026 2009/10/12 2009/10/12 12:00 30009 ビッグバン割引 1 1 -1000.0000
026 2009/10/12 2009/10/12 13:00 00000 利用料金 1 13 9300.0000
026 2009/10/12 2009/10/12 13:00 10002 たばこ 1 1 300.0000
026 2009/10/12 2009/10/12 13:00 10003 食品 1 1 300.0000
026 2009/10/12 2009/10/12 13:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/12 2009/10/12 13:00 30003 ティッシュ割引 1 1 -100.0000
026 2009/10/12 2009/10/12 14:00 00000 利用料金 1 22 15100.0000
026 2009/10/12 2009/10/12 14:00 10002 たばこ 1 1 320.0000
026 2009/10/12 2009/10/12 14:00 10003 食品 1 3 400.0000
026 2009/10/12 2009/10/12 14:00 10005 シャワールーム 1 1 200.0000
026 2009/10/12 2009/10/12 14:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/12 2009/10/12 15:00 00000 利用料金 1 48 15400.0000
026 2009/10/12 2009/10/12 15:00 10002 たばこ 1 1 320.0000
026 2009/10/12 2009/10/12 15:00 10003 食品 1 5 830.0000
026 2009/10/12 2009/10/12 15:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/12 2009/10/12 16:00 00000 利用料金 1 41 12600.0000
026 2009/10/12 2009/10/12 16:00 10003 食品 1 2 240.0000
026 2009/10/12 2009/10/12 16:00 30002 ポイントカード割引 1 2 -400.0000
026 2009/10/12 2009/10/12 17:00 00000 利用料金 1 43 9800.0000
026 2009/10/12 2009/10/12 17:00 10003 食品 1 1 100.0000
026 2009/10/12 2009/10/12 17:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/12 2009/10/12 18:00 00000 利用料金 1 77 10100.0000
026 2009/10/12 2009/10/12 18:00 30002 ポイントカード割引 1 1 -200.0000
026 2009/10/12 2009/10/12 19:00 00000 利用料金 1 39 4300.0000
026 2009/10/12 2009/10/12 19:00 10003 食品 1 4 710.0000
026 2009/10/12 2009/10/12 19:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/12 2009/10/12 20:00 00000 利用料金 1 52 7300.0000
026 2009/10/12 2009/10/12 20:00 10003 食品 1 2 390.0000
026 2009/10/12 2009/10/12 21:00 00000 利用料金 1 36 8100.0000
026 2009/10/12 2009/10/12 21:00 10003 食品 1 1 180.0000
026 2009/10/12 2009/10/12 21:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/12 2009/10/12 22:00 00000 利用料金 1 35 6400.0000
026 2009/10/12 2009/10/12 22:00 10002 たばこ 1 3 960.0000
026 2009/10/12 2009/10/12 22:00 10003 食品 1 6 860.0000
026 2009/10/12 2009/10/12 23:00 00000 利用料金 1 42 4800.0000
026 2009/10/12 2009/10/12 23:00 10003 食品 1 1 180.0000
026 2009/10/12 2009/10/13 00:00 00000 利用料金 1 16 1900.0000
026 2009/10/12 2009/10/13 00:00 10003 食品 1 2 410.0000
026 2009/10/12 2009/10/13 01:00 00000 利用料金 1 40 4600.0000
026 2009/10/12 2009/10/13 01:00 10003 食品 1 1 150.0000
026 2009/10/12 2009/10/13 02:00 00000 利用料金 1 3 3600.0000
026 2009/10/12 2009/10/13 02:00 10001 物品 1 1 30.0000
026 2009/10/12 2009/10/13 02:00 10003 食品 1 1 200.0000
026 2009/10/12 2009/10/13 03:00 00000 利用料金 1 2 3200.0000
026 2009/10/12 2009/10/13 03:00 10003 食品 1 1 170.0000
026 2009/10/12 2009/10/13 04:00 00000 利用料金 1 14 2400.0000
026 2009/10/12 2009/10/13 04:00 10003 食品 1 1 100.0000
026 2009/10/12 2009/10/13 05:00 00000 利用料金 1 18 5700.0000
026 2009/10/12 2009/10/13 05:00 10002 たばこ 1 1 300.0000
026 2009/10/12 2009/10/13 05:00 10003 食品 1 1 120.0000
026 2009/10/12 2009/10/13 06:00 00000 利用料金 1 18 7500.0000
026 2009/10/12 2009/10/13 07:00 00000 利用料金 1 12 1500.0000
026 2009/10/12 2009/10/13 08:00 00000 利用料金 1 67 14500.0000
026 2009/10/12 2009/10/13 08:00 10005 シャワールーム 1 1 200.0000
026 2009/10/12 2009/10/13 09:00 00000 利用料金 1 48 12200.0000
026 2009/10/12 2009/10/13 09:00 10001 物品 1 5 525.0000
026 2009/10/12 2009/10/13 09:00 10002 たばこ 1 2 620.0000
026 2009/10/12 2009/10/13 09:00 10005 シャワールーム 1 1 200.0000
026 2009/10/12 2009/10/13 09:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/12 2009/10/13 10:00 00000 利用料金 1 59 9500.0000
026 2009/10/13 2009/10/13 11:00 00000 利用料金 1 35 7900.0000
026 2009/10/13 2009/10/13 11:00 10003 食品 1 2 330.0000
026 2009/10/13 2009/10/13 12:00 00000 利用料金 1 32 11900.0000
026 2009/10/13 2009/10/13 12:00 10003 食品 1 1 120.0000
026 2009/10/13 2009/10/13 12:00 30003 ティッシュ割引 1 2 -200.0000
026 2009/10/13 2009/10/13 13:00 00000 利用料金 1 51 11100.0000
026 2009/10/13 2009/10/13 13:00 10001 物品 1 1 100.0000
026 2009/10/13 2009/10/13 13:00 10003 食品 1 1 110.0000
026 2009/10/13 2009/10/13 13:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/13 2009/10/13 14:00 00000 利用料金 1 46 11500.0000
026 2009/10/13 2009/10/13 14:00 10002 たばこ 1 2 600.0000
026 2009/10/13 2009/10/13 14:00 10003 食品 1 4 860.0000
026 2009/10/13 2009/10/13 15:00 00000 利用料金 1 132 19200.0000
026 2009/10/13 2009/10/13 15:00 10001 物品 1 3 90.0000
026 2009/10/13 2009/10/13 15:00 10002 たばこ 1 1 300.0000
026 2009/10/13 2009/10/13 15:00 10003 食品 1 4 460.0000
026 2009/10/13 2009/10/13 15:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/13 2009/10/13 16:00 00000 利用料金 1 64 7500.0000
026 2009/10/13 2009/10/13 16:00 10002 たばこ 1 1 320.0000
026 2009/10/13 2009/10/13 17:00 00000 利用料金 1 80 11000.0000
026 2009/10/13 2009/10/13 17:00 10002 たばこ 1 1 320.0000
026 2009/10/13 2009/10/13 17:00 10003 食品 1 3 520.0000
026 2009/10/13 2009/10/13 18:00 00000 利用料金 1 67 11600.0000
026 2009/10/13 2009/10/13 18:00 10002 たばこ 1 2 620.0000
026 2009/10/13 2009/10/13 19:00 00000 利用料金 1 67 13600.0000
026 2009/10/13 2009/10/13 19:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/13 2009/10/13 20:00 00000 利用料金 1 39 6400.0000
026 2009/10/13 2009/10/13 20:00 10001 物品 1 10 300.0000
026 2009/10/13 2009/10/13 20:00 10002 たばこ 1 2 620.0000
026 2009/10/13 2009/10/13 20:00 10003 食品 1 3 440.0000
026 2009/10/13 2009/10/13 21:00 00000 利用料金 1 35 9600.0000
026 2009/10/13 2009/10/13 22:00 00000 利用料金 1 89 11100.0000
026 2009/10/13 2009/10/13 22:00 10003 食品 1 6 640.0000
026 2009/10/13 2009/10/13 22:00 30002 ポイントカード割引 1 2 -900.0000
026 2009/10/13 2009/10/13 22:00 30009 ビッグバン割引 1 1 -400.0000
026 2009/10/13 2009/10/13 23:00 00000 利用料金 1 44 5200.0000
026 2009/10/13 2009/10/13 23:00 10002 たばこ 1 1 320.0000
026 2009/10/13 2009/10/13 23:00 10003 食品 1 2 200.0000
026 2009/10/13 2009/10/14 00:00 00000 利用料金 1 63 7900.0000
026 2009/10/13 2009/10/14 00:00 10003 食品 1 2 370.0000
026 2009/10/13 2009/10/14 00:00 10004 飲料 1 1 100.0000
026 2009/10/13 2009/10/14 01:00 00000 利用料金 1 19 4100.0000
026 2009/10/13 2009/10/14 02:00 00000 利用料金 1 27 6900.0000
026 2009/10/13 2009/10/14 02:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/13 2009/10/14 03:00 00000 利用料金 1 4 5800.0000
026 2009/10/13 2009/10/14 03:00 10003 食品 1 4 620.0000
026 2009/10/13 2009/10/14 04:00 00000 利用料金 1 3 400.0000
026 2009/10/13 2009/10/14 04:00 10003 食品 1 2 270.0000
026 2009/10/13 2009/10/14 05:00 00000 利用料金 1 36 5200.0000
026 2009/10/13 2009/10/14 05:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/13 2009/10/14 06:00 00000 利用料金 1 18 7600.0000
026 2009/10/13 2009/10/14 06:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/13 2009/10/14 07:00 00000 利用料金 1 28 11800.0000
026 2009/10/13 2009/10/14 07:00 10005 シャワールーム 1 1 200.0000
026 2009/10/13 2009/10/14 08:00 00000 利用料金 1 63 16000.0000
026 2009/10/13 2009/10/14 08:00 10005 シャワールーム 1 1 200.0000
026 2009/10/13 2009/10/14 09:00 00000 利用料金 1 33 9500.0000
026 2009/10/13 2009/10/14 09:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/13 2009/10/14 10:00 00000 利用料金 1 44 10400.0000
026 2009/10/13 2009/10/14 10:00 10002 たばこ 1 1 300.0000
026 2009/10/13 2009/10/14 10:00 10003 食品 1 1 120.0000
026 2009/10/13 2009/10/14 10:00 30002 ポイントカード割引 1 1 -700.0000
026 2009/10/13 2009/10/14 11:00 00000 利用料金 1 2 2600.0000

#9

你是哪儿的呀怎么叫sql文呢

#10

难道是排序规则的问题？？都有日文

#11

to fredrickhu

> 你的这个帖子里面已经够明白了
  不过还是无法解释，为什么这么多天的数据没事儿，只有那一天的数据特殊呢
  麻烦你你给我解释一下吧，我自己都说服不了自己。
  那个帖子，让我懂得，没有order by的情况下，SQLServer会按照
  其他方式（索引，主键，数据库排序规则）排序。

  但是，在同一个数据据，同一个条件下，为什么出现了不同的结果呢

#12

to bancxc
> 你是哪儿的呀怎么叫sql文呢
呵呵，你叫什么。我一直叫个东西，我是做对日开发的。汉语叫SQL语句对吗

#13

to fredrickhu

>难道是排序规则的问题？？都有日文
  排序规则，我觉得不应该从这里考虑阿，为什么同一个规则，出不同顺序的数据阿
  我把数据贴出来的，你帮忙分析一下。

to 大家
  如果我把dbo.POSTotalSectionSales表的数据export出来，再把这表清空，再把刚才导出的数据
  导入，就没有这个问题了

#14

引用 12 楼 creatbird 的回复:

to bancxc
> 你是哪儿的呀怎么叫sql文呢
呵呵，你叫什么。我一直叫个东西，我是做对日开发的。汉语叫SQL语句对吗

这样子啊

#15

引用楼主 creatbird 的回复:

问题，如题目所示

环境：winXP SP3，数据库服务器是MSDE，数据库客户端microsoft SQL Server Manegement Studio2005
      这些，都在我的机器上，只有我用我的机器，没有其他人连接我的数据库。
      （我的环境都是日文环境，下面的叙述可能多少和中文环境有些语言上的出入，不理解的请问我）

SQL文如下：
SELECT DISTINCT
    dbo.POSTotalSectionSales.ShopCode, dbo.POSTotalSectionSales.SalesDate, dbo.POSSectionMaster.SectionCode,
    dbo.POSSectionMaster.Name, SUBSTRING(dbo.POSSectionMaster.SectionCode, 1, 1) AS Type
FROM    dbo.POSSectionMaster CROSS JOIN
        dbo.POSTotalSectionSales
where dbo.POSTotalSectionSales.SalesDate = '2009/10/12'

dbo.POSSectionMaster表里只有SectionCode和Name，共21G条数据，就是各个部门的名称，主KEY是SectionCode。
dbo.POSTotalSectionSales表里，有ShopCode,SalesDate,SalesHour,SectionCode,Name,Type,Count,Amount,
主KEY是（ShopCode,SalesDate,SalesHour,SectionCode,），表中有很多天的数据，
但是POSTotalSectionSales.ShopCode字段可以无视，因为这个字段的内容都是同一个商店CODE。

现在分别执行两次这个SQL文，
第一次，设定查询条件SalesDate = '2009/10/12'
第二次，设定查询条件SalesDate = '2009/10/13'

现象：第一次的查询结果，是乱序的，第二次的查询结果，是按照SectionCode排好序的，
      看了看执行计划，这两次查询，不同的地方是，第一次有个Hash Match(aggregate)，第二次有个Sort(Distinct Sort)
      （其他的日期也反复的查询了几次，和第二次一个样，按照SectionCode排序的，执行计划里面也有个Sort或者Sort(Distinct Sort)）
问题：
    为什么同一条查询语句，只有查询的条件值不同，出的结果的排序会不同呢

我的解释为：你第一次查询后这个表的记录就按照顺序存在内存里面了
不相信你把数据库重新启动一下试试

#16

to HEROWANG
> 先去掉distinct看看结果怎样？
> 因为distinct会引起排序的。
  谢谢你回答我的问题。
  我试了试，去掉了后

  12号那天的数据是
SELECT
    dbo.POSTotalSectionSales.ShopCode, dbo.POSTotalSectionSales.SalesDate, dbo.POSSectionMaster.SectionCode,
    dbo.POSSectionMaster.Name, SUBSTRING(dbo.POSSectionMaster.SectionCode, 1, 1) AS Type
FROM    dbo.POSSectionMaster CROSS JOIN
        dbo.POSTotalSectionSales
where dbo.POSTotalSectionSales.SalesDate = '2009/10/12'

026 2009/10/13 00000 利用料金 0
026 2009/10/13 00000 利用料金 0
026 2009/10/13 00000 利用料金 0
   .
   .
   .
026 2009/10/13 10001 物品 1
026 2009/10/13 10001 物品 1
   .
   .
   .
026 2009/10/13 10002 たばこ 1
026 2009/10/13 10002 たばこ 1

  13号那天的数据是
SELECT
    dbo.POSTotalSectionSales.ShopCode, dbo.POSTotalSectionSales.SalesDate, dbo.POSSectionMaster.SectionCode,
    dbo.POSSectionMaster.Name, SUBSTRING(dbo.POSSectionMaster.SectionCode, 1, 1) AS Type
FROM    dbo.POSSectionMaster CROSS JOIN
        dbo.POSTotalSectionSales
where dbo.POSTotalSectionSales.SalesDate = '2009/10/13'

026 2009/10/18 00000 利用料金
026 2009/10/18 10001 物品
026 2009/10/18 10002 たばこ
   .
   .
   .
026 2009/10/18 00000 利用料金
026 2009/10/18 10001 物品
026 2009/10/18 10002 たばこ
   .
   .
   .

#17

在没有指定order by 时，sqlserver不会主动加一层sort操作。
在多表连接时，结果集顺序并不确定，sqlserver依具具体的情况来确定采用的连接方式（算法),不同的连接算法，导至结果集顺序会有差异。

#18

如果相同了,那才是见鬼了.

#19

to taoistong
> 我的解释为：你第一次查询后这个表的记录就按照顺序存在内存里面了
> 不相信你把数据库重新启动一下试试
  你好，按照你的意思，我第一次查询后（10/12），这个表的记录就按照顺序存在
  内存里了，那么第二次查询（10/13 ），就应该按照刚才存在内存的顺序查询了。
  可是，第二次查询，是不同的顺序啊。
  可能是不是我理解错你的意思了？！
  我重新启动了数据库好几次，分不同的顺序测试了这2个SQL，和先执行后执行没有关系
  乱序的还是乱序，有序的还是有序。

#20

to 大家
  我发现，DB里，
  2009/10/13以后的数据可以有序的表示出来
  2009/10/12以前的数据，按照相同的顺序，也就是说，10/12和10/11，10/10等等，
  这几天的表示顺序相同，乱序的表示出来

  难道我看到的乱序，也是一种顺序？只不过我看不出是按照什么顺序排序的。

#21

继续等待。
那个朋友帮忙顶一下帖子啊

#22

引用 21 楼 creatbird 的回复:

继续等待。
那个朋友帮忙顶一下帖子啊

没有order by 的查询，结果从理论上讲顺序是不一定的，他会按物理上最先访问的到的顺序排,你看的乱序也是正常的

#23

to xiequan2
> 没有order by 的查询，结果从理论上讲顺序是不一定的，
> 他会按物理上最先访问的到的顺序排,你看的乱序也是正常的
有没有办法看一下某一条数据的物理位置。
oracle里面不是有个rowID吗？SQLServer里面有没有类似的属性之类的啊

#24

引用 23 楼 creatbird 的回复:

to xiequan2
> 没有order by 的查询，结果从理论上讲顺序是不一定的，
> 他会按物理上最先访问的到的顺序排,你看的乱序也是正常的
有没有办法看一下某一条数据的物理位置。
oracle里面不是有个rowID吗？SQLServer里面有没有类似的属性之类的啊

不知道是不是IDENTITY

#25

引用 23 楼 creatbird 的回复:

to xiequan2
> 没有order by 的查询，结果从理论上讲顺序是不一定的，
> 他会按物理上最先访问的到的顺序排,你看的乱序也是正常的
有没有办法看一下某一条数据的物理位置。
oracle里面不是有个rowID吗？SQLServer里面有没有类似的属性之类的啊

，有个类似的row_number，但它的值也是要依靠排序的

#26

应该和数据页有关

#27

数据的基本存储单位是页，当没有order by 排序的时候，是按照物理页的顺序来读取的。

#28

to yesyesyes,navy887
如何才能看到，某一条数据所在的页数。
比如，写一个SQL，可以看到每一条数据所在的页数。我要确认一下。

#29

to ALL
  好像有个RID，可以表示哪一行。不过还不会使用呢

  是不是按照 Page:RID这样的形式表示每一条的数据物理位置的啊

  继续调查中，请大家帮忙。

#30

你给的命令是 "消除重复"

SQL Server即可以使用Aggregate的方法消除重复，也可以使用Sort後再消除重复.

请问这个有什么不妥的?

#31

看表的物理结构

dbcc page ('taoisTong', 1, 115, 3) WITH TABLERESULTS

http://blog.csdn.net/taoistong/archive/2009/04/17/4088418.aspx

#32

to Garnett_KG
> SQL Server即可以使用Aggregate的方法消除重复，也可以使用Sort後再消除重复.
  你好，那个东西我都不懂，查了查，好像是做成集合的方式。

  你说的很有道理，就是消除重复的方式。
  我以为，Sort(Distinct Sort) ，就是进行了排序，Aggregate，没有进行排序。
  但是，同一个数据库，同一个表，同一条SQL，为什么会有着两种排序的方式呢。

#33

引用 32 楼 creatbird 的回复:

to Garnett_KG
> SQL Server即可以使用Aggregate的方法消除重复，也可以使用Sort後再消除重复.
  你好，那个东西我都不懂，查了查，好像是做成集合的方式。

  你说的很有道理，就是消除重复的方式。
  我以为，Sort(Distinct Sort) ，就是进行了排序，Aggregate，没有进行排序。
  但是，同一个数据库，同一个表，同一条SQL，为什么会有着两种排序的方式呢。

毫不夸张的说，同一条sql语句会有成千上万个不同的执行计划可供选择。sql server基於成本去选择执行计划, 而不同的条件就会导至成本上的差异。

你要想都要排序就加上order by
你要想都不排序就加上option(hash group), 总之要给1个确切的指令给sqlserver。

#34

to taoistong

> dbcc page ('taoisTong', 1, 115, 3) WITH TABLERESULTS
  谢谢啊！！！
  如果我要察看数据库A，表B的物理结构的话，怎么写SQL啊？

  dbcc page ('A', 1, 115, 3) WITH TABLERESULTS

#35

居然用日语。。。

专业笔试·！

#36

引用 35 楼 lang071234 的回复:

居然用日语。。。

专业笔试·！

我是做对日开发的
5年了,中文都快说的不利落了
大家常说的SQL语句，我们都说SQL文，呵呵

#37

现在，怀疑，是不是数据库中表的索引，长期没有整理，导致产生了很多碎片，引起了目前的现象啊

为什么会出现同一SQL，不同日期，检索出的数据顺序不同啊

#38

等待那哥们儿帮忙解释一下，或者告诉我原因，即以后怎么才能避免产生这样的问题。
当然，除了添加 order by语句这个办法。

#39

不做db好多年。纯粹友情顶下

#40

不太清楚，期待高手来解答，我理解的是，存贮过程也不是物理空间连续的，所以不加order by 肯定是乱的。

#41

引用 1 楼 fredrickhu 的回复:

那天才讨论了这个问题

没有order by排序的时候是按照本身的物理逻辑来进行排序的

赞成小F的

#42

引用 41 楼 zywcy100 的回复:

引用 1 楼 fredrickhu 的回复:
那天才讨论了这个问题

没有order by排序的时候是按照本身的物理逻辑来进行排序的

赞成小F的

那你告诉我，怎么才能看到每一条数据的物理位置吧

#43

等待大家帮忙给我解释一下，我都睡不着觉了阿

怎么才能看到每一条数据的物理位置啊
有没有这样的SQL啊

#44

数据是集合，没有顺序，要排序指定order by

#45

该回复于2009-10-30 14:35:08被版主删除

#46

引用 44 楼 colacat911 的回复:

数据是集合，没有顺序，要排序指定order by

这个道理我也明白。
但是，目前的情况是，这个系统运行了3年多了，在没写order by 的前提下
还没有听说出现乱序的问题。现在就是要弄清楚，为什么！！！

#47

引用 45 楼 cpzyy828 的回复:

春哥纯爷们，铁血真汉子

谢谢哥们帮我顶帖子。你是我朋友吗?

#48

这个系统运行了3年多了，在没写order by 的前提下
还没有听说出现乱序的问题。每天都要打印一次帐票，一般是正常排序，怎么突然有一天打印的时候，成了乱序了？天长日久，以前的数据就不是正常排序了，现在就是要弄清楚是什么改变了以前数据的存储顺序

#49

引用 48 楼 creatbird 的回复:

这个系统运行了3年多了，在没写order by 的前提下
还没有听说出现乱序的问题。每天都要打印一次帐票，一般是正常排序，怎么突然有一天打印的时候，成了乱序了？天长日久，以前的数据就不是正常排序了，现在就是要弄清楚是什么改变了以前数据的存储顺序

可能是磁盘空间问题和聚集索引导致部分历史数据在某些时候发生物理转移了吧？

#50

引用 49 楼 pbsh 的回复:

引用 48 楼 creatbird 的回复:
这个系统运行了3年多了，在没写order by 的前提下
还没有听说出现乱序的问题。每天都要打印一次帐票，一般是正常排序，怎么突然有一天打印的时候，成了乱序了？天长日久，以前的数据就不是正常排序了，现在就是要弄清楚是什么改变了以前数据的存储顺序

可能是磁盘空间问题和聚集索引导致部分历史数据在某些时候发生物理转移了吧？

我也怀疑，能不能给点链接什么的

#1

那天才讨论了这个问题

没有order by排序的时候是按照本身的物理逻辑来进行排序的

#2

引用 1 楼 fredrickhu 的回复:

那天才讨论了这个问题

没有order by排序的时候是按照本身的物理逻辑来进行排序的

......

#3

专业围观

#4

#5

先去掉distinct看看结果怎样？
因为distinct会引起排序的。

#6

#7

http://topic.csdn.net/u/20091021/10/2171c105-e6aa-4fcf-aec7-b850d3de6539.html

你的这个帖子里面已经够明白了

#8

#9

你是哪儿的呀怎么叫sql文呢

#10

难道是排序规则的问题？？都有日文

#11

#12

to bancxc
> 你是哪儿的呀怎么叫sql文呢
呵呵，你叫什么。我一直叫个东西，我是做对日开发的。汉语叫SQL语句对吗

#13

#14

引用 12 楼 creatbird 的回复:

to bancxc
> 你是哪儿的呀怎么叫sql文呢
呵呵，你叫什么。我一直叫个东西，我是做对日开发的。汉语叫SQL语句对吗

这样子啊

#15

引用楼主 creatbird 的回复:

问题，如题目所示

环境：winXP SP3，数据库服务器是MSDE，数据库客户端microsoft SQL Server Manegement Studio2005
      这些，都在我的机器上，只有我用我的机器，没有其他人连接我的数据库。
      （我的环境都是日文环境，下面的叙述可能多少和中文环境有些语言上的出入，不理解的请问我）

SQL文如下：
SELECT DISTINCT
    dbo.POSTotalSectionSales.ShopCode, dbo.POSTotalSectionSales.SalesDate, dbo.POSSectionMaster.SectionCode,
    dbo.POSSectionMaster.Name, SUBSTRING(dbo.POSSectionMaster.SectionCode, 1, 1) AS Type
FROM    dbo.POSSectionMaster CROSS JOIN
        dbo.POSTotalSectionSales
where dbo.POSTotalSectionSales.SalesDate = '2009/10/12'

dbo.POSSectionMaster表里只有SectionCode和Name，共21G条数据，就是各个部门的名称，主KEY是SectionCode。
dbo.POSTotalSectionSales表里，有ShopCode,SalesDate,SalesHour,SectionCode,Name,Type,Count,Amount,
主KEY是（ShopCode,SalesDate,SalesHour,SectionCode,），表中有很多天的数据，
但是POSTotalSectionSales.ShopCode字段可以无视，因为这个字段的内容都是同一个商店CODE。

现在分别执行两次这个SQL文，
第一次，设定查询条件SalesDate = '2009/10/12'
第二次，设定查询条件SalesDate = '2009/10/13'

现象：第一次的查询结果，是乱序的，第二次的查询结果，是按照SectionCode排好序的，
      看了看执行计划，这两次查询，不同的地方是，第一次有个Hash Match(aggregate)，第二次有个Sort(Distinct Sort)
      （其他的日期也反复的查询了几次，和第二次一个样，按照SectionCode排序的，执行计划里面也有个Sort或者Sort(Distinct Sort)）
问题：
    为什么同一条查询语句，只有查询的条件值不同，出的结果的排序会不同呢

我的解释为：你第一次查询后这个表的记录就按照顺序存在内存里面了
不相信你把数据库重新启动一下试试

#16

#17

#18

如果相同了,那才是见鬼了.

#19

#20

#21

继续等待。
那个朋友帮忙顶一下帖子啊

#22

引用 21 楼 creatbird 的回复:

继续等待。
那个朋友帮忙顶一下帖子啊

没有order by 的查询，结果从理论上讲顺序是不一定的，他会按物理上最先访问的到的顺序排,你看的乱序也是正常的

#23

#24

引用 23 楼 creatbird 的回复:

to xiequan2
> 没有order by 的查询，结果从理论上讲顺序是不一定的，
> 他会按物理上最先访问的到的顺序排,你看的乱序也是正常的
有没有办法看一下某一条数据的物理位置。
oracle里面不是有个rowID吗？SQLServer里面有没有类似的属性之类的啊

不知道是不是IDENTITY

#25

引用 23 楼 creatbird 的回复:

to xiequan2
> 没有order by 的查询，结果从理论上讲顺序是不一定的，
> 他会按物理上最先访问的到的顺序排,你看的乱序也是正常的
有没有办法看一下某一条数据的物理位置。
oracle里面不是有个rowID吗？SQLServer里面有没有类似的属性之类的啊

，有个类似的row_number，但它的值也是要依靠排序的

#26

应该和数据页有关

#27

数据的基本存储单位是页，当没有order by 排序的时候，是按照物理页的顺序来读取的。

#28

to yesyesyes,navy887
如何才能看到，某一条数据所在的页数。
比如，写一个SQL，可以看到每一条数据所在的页数。我要确认一下。

#29

to ALL
  好像有个RID，可以表示哪一行。不过还不会使用呢

  是不是按照 Page:RID这样的形式表示每一条的数据物理位置的啊

  继续调查中，请大家帮忙。

#30

你给的命令是 "消除重复"

SQL Server即可以使用Aggregate的方法消除重复，也可以使用Sort後再消除重复.

请问这个有什么不妥的?

#31

看表的物理结构

dbcc page ('taoisTong', 1, 115, 3) WITH TABLERESULTS

http://blog.csdn.net/taoistong/archive/2009/04/17/4088418.aspx

#32

#33

引用 32 楼 creatbird 的回复:

to Garnett_KG
> SQL Server即可以使用Aggregate的方法消除重复，也可以使用Sort後再消除重复.
  你好，那个东西我都不懂，查了查，好像是做成集合的方式。

  你说的很有道理，就是消除重复的方式。
  我以为，Sort(Distinct Sort) ，就是进行了排序，Aggregate，没有进行排序。
  但是，同一个数据库，同一个表，同一条SQL，为什么会有着两种排序的方式呢。

#34

#35

居然用日语。。。

专业笔试·！

#36

引用 35 楼 lang071234 的回复:

居然用日语。。。

专业笔试·！

我是做对日开发的
5年了,中文都快说的不利落了
大家常说的SQL语句，我们都说SQL文，呵呵

#37

#38

等待那哥们儿帮忙解释一下，或者告诉我原因，即以后怎么才能避免产生这样的问题。
当然，除了添加 order by语句这个办法。

#39

不做db好多年。纯粹友情顶下

#40

不太清楚，期待高手来解答，我理解的是，存贮过程也不是物理空间连续的，所以不加order by 肯定是乱的。

#41

引用 1 楼 fredrickhu 的回复:

那天才讨论了这个问题

没有order by排序的时候是按照本身的物理逻辑来进行排序的

赞成小F的

#42

引用 41 楼 zywcy100 的回复:

引用 1 楼 fredrickhu 的回复:
那天才讨论了这个问题

没有order by排序的时候是按照本身的物理逻辑来进行排序的

赞成小F的

那你告诉我，怎么才能看到每一条数据的物理位置吧

#43

等待大家帮忙给我解释一下，我都睡不着觉了阿

怎么才能看到每一条数据的物理位置啊
有没有这样的SQL啊

#44

数据是集合，没有顺序，要排序指定order by

#45

该回复于2009-10-30 14:35:08被版主删除

#46

引用 44 楼 colacat911 的回复:

数据是集合，没有顺序，要排序指定order by

#47

引用 45 楼 cpzyy828 的回复:

春哥纯爷们，铁血真汉子

谢谢哥们帮我顶帖子。你是我朋友吗?

#48

#49

引用 48 楼 creatbird 的回复:

这个系统运行了3年多了，在没写order by 的前提下
还没有听说出现乱序的问题。每天都要打印一次帐票，一般是正常排序，怎么突然有一天打印的时候，成了乱序了？天长日久，以前的数据就不是正常排序了，现在就是要弄清楚是什么改变了以前数据的存储顺序

可能是磁盘空间问题和聚集索引导致部分历史数据在某些时候发生物理转移了吧？

#50

引用 49 楼 pbsh 的回复:

引用 48 楼 creatbird 的回复:
这个系统运行了3年多了，在没写order by 的前提下
还没有听说出现乱序的问题。每天都要打印一次帐票，一般是正常排序，怎么突然有一天打印的时候，成了乱序了？天长日久，以前的数据就不是正常排序了，现在就是要弄清楚是什么改变了以前数据的存储顺序

可能是磁盘空间问题和聚集索引导致部分历史数据在某些时候发生物理转移了吧？

我也怀疑，能不能给点链接什么的