К примеру, запрос:

ВЫБРАТЬ
    БанковскиеСчетаКонтрагентов.Ссылка КАК Ссылка
ИЗ
    Справочник.БанковскиеСчетаКонтрагентов КАК БанковскиеСчетаКонтрагентов
ГДЕ
    БанковскиеСчетаКонтрагентов.Владелец = &Владелец

В каком порядке выходят ссылки в данном случае?

В любом. Согласно стандарту SQL нельзя ожидать какого-либо порядка выборке при отсутствии явного упорядочивания в запросе.

(0) в произвольном, пока не задашь порядок явно

В порядке индекса по Владельцу

В вашем случае - в произвольном. Либо будет читать кластерный индекс по ссылке, либо некластерный по владельцу.

(4) Сам то понял что написал?

(5) Вы отнесены в категорию "Егор", писать мне сообщения не имеет смысла.

(6) отбор во владельцу это классика для кластерного.

Не ссорьтесь. Если порядок выборки не определён в запросе, то порядок будет случайным, независимо ни от каких кластерных индексов. Может сработать кэш или фаза луны.

(8) Порядок не будет случайным.
Алгоритм кэша вполне определен.

(9) Алгоритм кэша зависит от фазы луны

(0) Зависит от многих факторов:
1. Какая СУБД
2. Какие типы данных в таблице
3. Размер таблицы и данных
4. Оптимизация (алгоритм вакуум)
5. Влияние кэша
и т.д.

(11) Вы не должны надеяться на чёткий алгоритм сортировки, если сортировки не было задано. Вроде всё чётко сказано.

(10) Фаза луны подчиняется алгоритму http://astrolab.ru/cgi-bin/moon.cgi.html

Вот только бывает даже разработчики типовых не в курсе, и берут в запросе "ПЕРВЫЕ 1" без указания "УПОРЯДОЧИТЬ ПО". Пару раз с таким в ЗУПе встречался.

(14) Это нормально. Значит их устраивает любой.

(15) Только при этом алгоритм допускает ошибку, вместо скажем последнего документа берется какой попало)

+(16) При этом на файловой версии, например, или на mssql ошибка может и не проявиться, а на каком-нибудь постгресе вылезет..

(13) Фазы Луны в целом да, но фаза Луны в момент запроса вообще-то случайна. Если Вы не делаете много запросов подряд, тогда фаза строго определена в момент первого запроса (кэш?) или строго через заданный промежуток времени (тогда кэш+дельта)

(16) Так и должно быть. Ровно такое поведение закладывается в запрос. Если программист надеялся на другое поведение, то он ошибался.

Например, нас интересует любой (какой попало) документ об увольнении сотрудника. Мы понимаем, что он первый или последний, но всегда один. Мы же не путаем Сотрудника и ФизическоеЛицо

(20) уволенное и вновь принятое физлицо = новый сотрудник?
по совместительству тоже?

(21) Разумеется, это разные сотрудники. В Вашей базе это единые сущности? Ну я Вас поздравляю. Ждите косяков

(20) Не, в моем случае была ошибка. Я отправлял на техподдержку сообщение, ошибку зарегистрировали и исправили в последующем.

(23) ну трям. А к сабжу это имеет отношение?

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

(14) "УПОРЯДОЧИТЬ ПО" - одна из самых ёмких операций поэтому всегда стараются её избегать.

(24) Так именно в этом и была ошибка, не использовалось явное упорядочение в запросе, в результате при некоторых исходных данных и на некоторых sql-серверах алгоритм работал неверно.

(25) ты про страницы и экстенты то в курсе?