В 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

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

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

Уже что-то, конечно правильнее и спокойней добавить order by во все запросы, но можно попробовать:


Проблемы:

1. Таблица монопольно блокируется на время операции
2. Потребуется много свободного места, зависит от размера таблицы
ДокументацияПри использовании команды alter table...lock для изменения схемы
блокировки таблицы с блокировки всех страниц на блокировку толь-
ко данных и наоборот СУБД Adaptive Server делает копию страниц
данных этой таблицы. В сегменте, где размещается таблица, должно
быть достаточно пространства для полной копии страниц данных.
В сегменте, где размещаются индексы, должно быть место для пере-
строения индексов.
3. Ну и различные мелочи
Документация
• планы запросов в процедурном кэше, которые обращаются к
этой таблице, будут перекомпилированы при их следующем
запуске;
• активные многооператорные процедуры, которые исполь-
зуют эту таблицу, перекомпилируются перед выполнением
следующего шага;
• специальные пакетные транзакции, использующие эту таблицу,
завершаются.
Предупреждение. Изменение схемы блокировки таблицы в ходе
операции массового копирования может привести к поврежде-
нию таблицы. Операция массового копирования сначала полу-
чает сведения о таблице и не удерживает блокировку между мо-
ментом считывания информации о таблице и началом пересылки
строк, оставляя небольшой промежуток времени, когда может
быть запущена команда alter table...lock

to Александр Гoлдун

В чем я-то виноват?

Везде пишу, что нужен order by - это лучшее решение, но если нужно как-то выкрутиться лучше уж alter table чем слезы, дескать разработчики бяки.

Конечно они сделали криво - никто и не спорил.