Исходный заказ на размещение с кластеризованным индексом

(Ответы основаны на SQL Server - вопрос не указан на 100%)

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

Это не совсем правильно, данные могут храниться в любом порядке на листе, но массив слотов на странице фактически соответствует порядку, в котором данные считываются со страницы, а не физическому порядку данных.

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

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

Так как же можно извлечь из него данные в том порядке, в котором они были вставлены?

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

Представьте, что следующие данные вставляются в указанном порядке: 1,7,4,5,2, и для этого поля создается кластеризованный индекс. Таким образом, данные будут храниться внутри в порядке 1,2,4,5,7, верно?

Нет, на странице он будет храниться как 1,7,4,5,2, но массив слотов будет считывать адреса на странице как 7,5,4,2,1 (он построен с конца страницы в обратном направлении). , так что вы читаете в обратном порядке.)

Таким образом, это может ускорить поиск определенного значения, но что, если пользователю нужны первые 3 значения в том порядке, в котором он был вставлен?

В этом случае это не имеет значения - кроме отсутствия такой гарантии порядка, SQL будет считывать всю страницу в память. Если вы хотите узнать больше о SQL Internals на таком уровне, я бы по-прежнему рекомендовал книгу Kalen Delaneys SQL Internals как один из лучших источников.

Если вам нужна какая-либо информация о порядке вставки, я предлагаю какую-то вставленную_временную метку

Похоже, вам нужна временная метка для ваших строк. Обычно я помещаю следующие столбцы во все создаваемые мной таблицы (для аудита):

timecreated
timemodified
createdby
modifiedby
deleted

Эти столбцы позволяют узнать, кто и когда создал строку, когда она была изменена в последний раз и кем, а также, при необходимости, «обратимо удалить» строку, установив для удаления значение true. Конечно, все ваши другие запросы в системе должны будут проверять удаленное логическое значение для работы мягкого удаления.

Данные таблицы сортируются в соответствии с порядком кластеризованного индекса. У вас может быть только ОДИН кластеризованный индекс в каждой таблице, если вы хотите проверить первые 3 значения в том порядке, в котором он был вставлен,

ИСПОЛЬЗОВАТЬ AdventureWorks

go

CREATE TABLE myTable99(
Col1 int IDENTITY(1,1) PRIMARY KEY , Col2 Char(1) , Col3 datetime DEFAULT getdate()

) GO

INSERT INTO myTable99(Col2) SELECT 'A' UNION ALL SELECT 'B' UNION ALL SELECT 'C' GO

ВЫБЕРИТЕ * ИЗ myTable99 ЗАКАЗАТЬ ДО 3 GO

УДАЛИТЬ СТОЛ myTable99 GO

Другой метод может быть:

CREATE TABLE CounterData]( [CounterDataID] [bigint] IDENTITY(1,1) NOT NULL, [DateTimeID] [bigint] NOT NULL, [Value] [float] NULL ) ON [PRIMARY]

СОЗДАЙТЕ УНИКАЛЬНЫЙ КЛАСТЕРНЫЙ ИНДЕКС [IX_DateTime_CounterDataID] НА [PK].[CounterData]

(

[DateTimeID] ASC,
[CounterDataID] ASC

)

С

(PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] GO