ORDER BY [PRIMARY_KEY]必须在应该只使用索引时应用排序顺序吗？

Question

根据我的研究，按主键（或带有索引的任何其他列）进行排序 - 查询应该在没有显式排序的情况下运行。

我还发现了一个博客，其中这种行为显示在不同的数据库上，其中一个是Oracle。

然而 - 在我的测试中，这不是真的 - 可能是什么原因？安装选项不好？破碎的指数？ （虽然我通过创建一个全新的表来排除这一点）

查询：

select * from auftrag_test order by auftragkey

执行计划：

 Plan Hash Value  : 505195503 

-----------------------------------------------------------------------------------
| Id | Operation            | Name         | Rows   | Bytes    | Cost  | Time     |
-----------------------------------------------------------------------------------
|  0 | SELECT STATEMENT     |              | 167910 | 44496150 | 11494 | 00:00:01 |
|  1 |   SORT ORDER BY      |              | 167910 | 44496150 | 11494 | 00:00:01 |
|  2 |    TABLE ACCESS FULL | AUFTRAG_TEST | 167910 | 44496150 |  1908 | 00:00:01 |
-----------------------------------------------------------------------------------

create table AUFTRAG_TEST
(
   auftragkey           VARCHAR2(40) not null,
  ...
);
alter table AUFTRAG_TEST
  add constraint PK_AUFTRAG_TEST primary key (AUFTRAGKEY);

你可能会问自己为什么主键是一个varchar字段。嗯，这是我们老板决定的事情。 （实际上我们放入了字符串化的guid）

我发现的博客：

http://use-the-index-luke.com/sql/sorting-grouping/indexed-order-by

P.S。：我认为我发现了问题。此选择不“按顺序”：

select * 
from auftrag_test 
where auftragkey = 'aabbccddeeffaabbccddeeffaabbccdd' 
order by auftragkey

所以 - 显然 - 如果你过滤了一个索引，它只会起作用，“平等”根本不会有用。

P.P.S：MS-SQL似乎正如我所料。如果我按主键（使用非群集唯一索引）进行排序 - 排序是“免费”。在执行计划中，也可以在时间上查询。

Answer 1

你应该知道通过索引扫描一个大表可能需要几个小时。在同一张桌子上进行全表扫描，只需几分钟 在这种情况下，遍历索引是为了保存O（n * log（n））排序操作，听起来不是一个好主意。

堆表将产生排序操作 IOT（索引orginized表，也称为＆＃34;聚集索引＆＃34;）已经排序。

create table t_heap (i int primary key,j int);
create table t_iot  (i int primary key,j int) organization index;

select * from t_heap order by i;

select * from t_iot order by i;