RID是一个包含三个组成部分的逻辑地址。
有人知道为什么使用密钥查找而不是RID查找来搜索数据吗？因为当聚集索引上有非聚集索引时，RID查找肯定比密钥查找快？就像你已经可以获得RID/地址一样，为什么还要从根节点遍历几个级别来读取你想要的？
- 文件
- 页码
- 插槽
这个概念确实存在于堆和聚集索引中。你可以用看到
SELECT sys.fn_physlocformatter(%%physloc%%), *
FROM your_table
我想物理RID不用于集群索引的原因是维护成本太高。插槽阵列是按键顺序排列的，因此在所有现有行都有稍后键顺序的页面上插入新行意味着可能会有数百行的插槽编号增加，并且需要在所有非聚集索引中更新。
对于堆，不需要在插入时重新排列插槽阵列，因为它不必维护任何特定的顺序。对于更新时的堆，如果一行扩展且无法再容纳在其原始位置，则会留下一个转发指针，从而省去了在非聚集索引中更新RID的需要，即使是该单行。
通过使用仅包含File:Page组件的物理地址并查找页面本身的键值(与通过常规索引查找定位叶页面时的方法相同(，可以避免部分开销，但仍可能存在许多行的PID无效的操作，并且需要将这种效果传播到非聚集索引(例如页面拆分或索引重建(。
将逻辑指针与行的物理位置解耦也允许以较少的开销将索引迁移到不同的文件组。
数据存储在扩展区内的8K页面中。如果表没有聚集索引，则称为堆，最后的字节是指向该页上数据行地址的2字节地址的矢量。这些被称为RID或行ID。
当堆获得聚集索引(只能有一个(时，RID地址的向量将转换为键地址的向量。这允许SQL Server对堆和集群(索引(表使用相同的页面结构。
因此，您的问题的答案是集群表已经丢失了RID，唯一的策略是使用密钥查找。请注意，即使堆上有RID，也需要扫描IAM页面以查找数据页面地址，因此任何"节省"都是值得怀疑的。