В ASE это зависит от типа таблицы (как она блокируется), если она allpageslock - то все записи должны быть отсортированы по первичному ключу
ДокументацияВ кластерных индексах по таблицам с блокировкой всех страниц страни-
цы листового уровня также являются страницами данных, и все строки
хранятся в физическом порядке согласно значениям ключей.

в случае datapageslock или rowlock - таблица не будет обязательно автоматически упорядочиваться по ключу, сервер только попытается это сделать если на страницах будет свободное место
ДокументацияВ отличие от кластерных индексов по таблицам с блокировкой всех
страниц, строки данных в таблицах с блокировкой только данных не
обязательно хранятся строго в порядке значений ключа. В этом случае
индекс направляет строки на страницы, содержащие смежные или близ-
кие ключи.

Добиваться упорядочивания по кластерному ключу для таблиц с типом блокирования отличныи от allpageslock можно с помощью параметров управления пространством (например fillfactor) и выполнением команды reorg rebuild.

ДокументацияФизическое упорядочение означает следующее:
• Все элементы на странице данных расположены в порядке
индексного ключа.
• Вся таблица может быть прочитана в порядке индексного ключа
благодаря тому, что на каждой странице данных есть указатели
на следующую страницу.

При простом select * from таблица выполняется table scan, при этом данные читаются по страницам, котрые (у таблиц с кластерным ключом и типом блокирования allpages) расположены в порядке кластерного ключа.

Описание работы кластерного индекса довольно объемное, полностью приводить его нет смысла

>Александр Гoлдун
>Даже если в текущей версии это так, то я сомневаюсь, что это а) гарантированно,
Гарантированно.

>б) останется в дальнейшем так.
Это из области домыслов, пока не менялось.

to MasterZiv

Понятно, про парралелизм то я и забыл, однако он используется редко, и помнится вы же и рекомендовали использовать его крайне осторожно.
Насколько показывает опыт, в обычном режиме происходит выдача данных именно по кластерному ключу и некоторые разработчики под ASE это используют (не я и не в нашей конторе), сомневаюсь, что у "Трава у дома" включен параллелизм, скорее всего, изменили тип блокирования.

ДокументацияЕсли это таблица с блокировкой всех страниц, то при сканировании
таблицы или сканировании, использующем кластерный индекс для
просмотра большого количества страниц, страницы данных просмат-
риваются по указателям на следующую страницу, которые есть на
каждой странице.

Честно говоря я всегда думал, что это и гарантирует упорядоченность вывода, теперь уже сам засомневался. С параллельным сканированием, особенно если таблица секционирована, все ясно - порядок не гарантирован, но без него вроде должно быть по порядку.

to MasterZiv
>При простом select * from таблица выполняется table scan,
>Далеко не факт. И в документации нигде такого не сказано.

А в каком случае сервер применит стратегию отличную от table scan?
Может когда есть индекс покрывающий все поля таблицы?

to MasterZiv

Так и не понял к чему это, обсуждался запрос вида:
ни хинтов, ни group by, ни distinct, ни объединения таблиц, про абстрактные планы тоже упоминания не было. Конечно пинком можно заставить сервер поменять план, но вы сказали, что он сам может выбрать стратегию отличную от table scan - в каком случае?

Еще раз:

Документация• Вся таблица может быть прочитана в порядке индексного ключа
благодаря тому, что на каждой странице данных есть указатели
на следующую страницу.

В оригинале:
ДокументацияBy following the “next page” pointers on the data pages, Adaptive
Server reads the entire table in index key order.

Похоже просто случай из раздела lost translation (перевод официальный), а в оригинале вроде все вполне определенно.

to "Трава у дома"

Не могли бы вы привести вывод sp_help по таблице - там должны быть строки, например:
Object is not partitioned.
Lock scheme Allpages

или соответственно что-то другое.

У вас используется параллельное исполнение?