Sql 既然rid查找更快，为什么要使用键查找而不是rid查找？

有人知道为什么使用键查找而不是RID查找来搜索数据，因为当聚集索引上有非聚集索引时，RID查找肯定比键查找快？就像您已经可以获得RID/地址一样，为什么还要费心从根节点中读取跨多个级别的内容以获得所需的内容？

数据存储在扩展数据块内的8K页中。如果表没有聚集索引，则称为堆，最后的字节是2字节地址的向量，指向该页上的数据行地址。这些被称为RID或行ID

当堆获得聚集索引（只能有一个）时，RID地址向量将转换为键地址向量。这允许SQLServer对堆和集群（索引）表使用相同的页面结构

---

因此，您的问题的答案是，集群表已丢失其RID，唯一的策略是使用键查找。请注意，即使堆上有RID，也需要扫描IAM页以查找数据页地址，因此任何“节省”都是值得怀疑的。

RID是包含三个组成部分的逻辑地址

• 文件
• 页面
• 槽

对于堆和聚集索引，确实存在此概念。你可以用眼睛看

SELECT sys.fn_physlocformatter(%%physloc%%), *
FROM your_table

我认为物理RID不用于聚集索引的原因是维护成本太高。处于键顺序，因此在所有现有行具有更高键顺序的页面上插入新行将意味着可能有数百行的插槽号增加，并且需要在所有非聚集索引中更新

对于堆，无需在插入时重新排列插槽阵列，因为它不必维护任何特定顺序。对于更新时的堆，如果一行扩展并且不再适合其原始位置，则会留下一个转发指针，这样就不需要在非聚集索引中更新RID，即使是该单行

通过只使用

File:Page

组件的物理地址，并在页面本身上查找键值，可以避免一些开销（与通过常规索引查找找到叶页面时的情况相同）但仍然可能存在许多行的PID无效的操作，并且需要将此效果传播到非聚集索引（例如页拆分或索引重建）

---

将逻辑指针与行的物理位置分离也允许以较少的开销将索引迁移到不同的文件组。

您需要提供有关场景、表定义、索引、查询和执行计划的一些详细信息。您指的是什么？为此，数据库的二级索引中通常有行ID。@DaleK-似乎是关于SQL Server的设计决策的一般问题，即当表有CI时，将（逻辑）聚集索引键作为行定位器包含在非聚集索引中，而不是像堆那样仅使用物理RID。“扩展数据块是八个物理连续页面的集合，用于有效管理页面。所有页面都被组织成区段。-rid是文件、页面、插槽。聚集索引行存在于文件的页面上，并且在页面上有一个插槽，因此没有理由不能将物理RID用于这些行。这可能不是一个好主意，因为插槽数组是按键顺序排列的，所以在页面中插入一行可能会导致数十个或数百个插槽索引发生更改，并且需要在非聚集索引中更新。这是一个非常有用的答案，非常感谢！