SandalTree1. Не всегда. RID создаётся только на неуникальном кластерном индексе и только в случае повторяющихся значений.

2. У меня вопрос непро уникальный кластерный индекс, а про Primary Key, который с ним различается.

Всегда.
Storage Engine (SE) всегда может однозначно идентифицировать запись.


А вопрос, имхо, сильно зависит... от спрашивающего.

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

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

Как понять, кто перед тобой, если ты заранее не знаешь? Это можно сделать по реакции на свой ответ.
Если видно:
- высокомерие граничащее с тыканьем в грязь (обусловленное только тем, что собеседующий 10 минут назад прочитал раздел справки по которому тебя спрашивает, а-ля "в какой последовательности передаются параметры в функцию datediff")
- отсутствие наводящих и уточняющих вопросов с целью понять какой ты специалист
- ощущение что больше не тебя хотят спросить, а показать свою крутость
и прочие схожие мысли.

В целом, имхо, вопрос сродни "чем отличается болт от шурупа" - вроде примерно похожи, но есть разница.
Ответ может лежать как в семантической (смысловой) области, так и в физической. Если это вопрос не для того чтобы завязать диалог, а "анкетный" вопрос - то он откровенно глупый, по крайней мере в такой формулировке. Т.к. "анкетный" вопрос все-таки, должен понимать "анкетный" ответ в той же плоскости. Например, можно было бы спросить "Для чего используется PK, а для чего UQ" - смысловой. Или "Как сервер реализует PK и как UQ" - физика.

Это вам задали на собеседовании или вы сами такие вопросы спрашиваете?

Storage Engine всегда может однозначно идентифицировать запись, даже если таблица куча и все значения в ней одинаковые или неуникальный кластерный индекс и все ключи одинаковые. "Только люди видят дубликаты" (c) Paul Randal выше на скриншоте. Я думаю достаточно авторитетный источник =)

Что касается механизма поддержки уникальности. Есть понятие - закладка. Закладка - это логический указатель на строку. Физически закладка может реализовываться по-разному.

Например:
Таблица-куча - FileID:PageID:SlotID (то, что общепринято называть RID)

Таблица-кластеризованная RowStore - Clustered Index Key : [Uniqueifier] (унификатор, добавляется если кластерный индекс не уникален)

Таблица-кластеризованная ColumnStore - RowgroupID:TypleID (для кластерных колоночных индексов в 2014, идентификатор группы строк + порядковый номер строки, нигде не хранится - вычисляется)

Таблица-кластеризованная ColumnStore часть Delta Store - CSILOCATOR (для кластерных колоночных индексов в 2014, для внутренней структуры Delta Store , которая поддерживает изменения добавляется псевдо колонка CSILOCATOR суррогатный ключ, по сути просто порядковый номер)

Закладки нужны серверу для того, чтобы поддерживать изменения. Даже если никаких других индексов нет, простое написание запроса delete from t, происходит следующим образом.



Куча


Любой запрос на изменение имеет две части, так называемые read cursor и write cursor. В части read cursor сервер определяет, какие строки нужно изменить, для этих строк он собирает закладки, эти закладки после передаются в часть write cursor. Которая выполняет изменения на основных данных и дополнительных (если есть другие индексы которые затрагивает модификация).



Обратите внимание в плане на вывод псевдо колонки Bmk1000. Это как раз и есть закладка.
В данном случае, таблица куча, а потому закладка это просто физическое расположение строки.



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



Видно, что используется HEAP RID key, который совпадает с физическим положением строки в кластерном индексе (предыдущий рисунок).

Неуникальный кластерный индекс
Тот же набор экспериментов для неуникального кластерного индекса.




Обратите внимание, теперь, в качестве закладки в write cursor передается ключ кластерного индекса + унификатор (т.к. мы сделали неуникальный кластреный индекс). Второй интересный момент, поскольку на предыдущем шаге мы создали некластреный индекс, то для поиска строк оптимизатор решил использовать его, и значение закладки взял именно из некластерного индекса.

Можно посмотреть, что хранится на листовом уровне некластерного индекса теперь:



Видно, что теперь нет RID-а, но добавился унификатор, причем, что интересно, поскольку значения A,B у нас фактически разные, унификатор один и тот же.

Уникальный кластерный индекс


Теперь, поскольку индекс уникальный, в качестве закладки, используется просто ключ кластерного индекса:





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

SandalTreeHEAP RID key используется индексом, но в реальности-то он не хранится.
Нету его на странице данных.
Вывод DBCC Page вас не убеждает? Вы полагаете DBCC Page что-то придумывает, а не использует данные страницы?

SandalTreeHEAP RID key используется индексом, но в реальности-то он не хранится.
Нету его на странице данных.

SandalTreeНе понял вопроса.

Хотел лишь сказать что в хипе индекс ссылается на записи по RID, но RID в самих данных не хранится.

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