SQL Server - Разделенные таблицы или кластерный индекс?

Ответ 1

Эта таблица очень узкая. Если реальная таблица будет такой узкой, вы должны быть счастливы иметь сканирование таблицы вместо index- > ​​lookups.

Я бы сделал это:

CREATE TABLE Narrow
(
  [id] INT NOT NULL,
  [date] SMALLDATETIME NOT NULL,
  [sales] FLOAT NULL,
  PRIMARY KEY(id, date)  --EDIT, just noticed your id is not unique.
)

CREATE INDEX CoveringNarrow ON Narrow(date, id, sales)

Это обрабатывает точечные запросы с помощью запросов и широкодиапазонных запросов с ограниченным просмотром по критериям даты и критериям идентификатора. Нет никакого поиска записей из индекса. Да, я удвоил время записи (и используемое пространство), но это прекрасно, imo.

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

CREATE VIEW Narrow200801
AS
SELECT * FROM Narrow WHERE '2008-01-01' <= [date] AND [date] < '2008-02-01'
--There is some command that I don't have at my finger tips to make this a clustered view.

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

SELECT SUM(sales) FROM Narrow WHERE '2008-01-01' <= [date] AND [date] < '2008-02-01'

В качестве индекса вы можете удобно использовать определенные столбцы... Кластеризованное представление позволяет вам удобно использовать определенные строки.

Ответ 2

Кластеризованный индекс даст вам преимущества в производительности для запросов при локализации ввода-вывода. Дата является традиционной стратегией разделения, так как многие запросы D/W просматривают движения по дате.

Практическое правило для многораздельной таблицы предполагает, что размер разделов должен составлять около 10 м строк.

Было бы необычно видеть много прироста производительности от кластерного индекса при разнообразной аналитической нагрузке. Оптимизатор запросов будет использовать метод 'Index Intersection', чтобы выбирать строки, даже не попав в таблицу фактов. См. здесь для сообщения, которое я сделал по другому вопросу, который объясняет это более подробно с некоторыми ссылками. Кластеризованный индекс может участвовать или не участвовать в пересечении индексов, поэтому вы можете обнаружить, что он довольно мало влияет на общую рабочую нагрузку на запрос.

Вы можете найти обстоятельства при загрузке, когда кластеризованные индексы дают вам некоторую выгоду, особенно если вы получили вычисления (например, Earned Premium), которые вычисляются в процессе ETL. В этом случае вы можете получить некоторые преимущества. Если у вас есть определенный запрос, который, как вы знаете, будет выполняться все время, это может иметь смысл использовать кластерные индексы для этого. Варианты № 2 и № 3 будут только значительно приносить вам пользу, если вы ожидаете, что этот тип запросов будет подавляющим большинством работы, выполняемой приложением.

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

Ответ 3

Если вы используете разделы в операторах выбора, вы cn получаете некоторую скорость.

Если вы не используете его, используйте только "стандартные", тогда у вас нет пользы.

По вашей первоначальной проблеме: я бы порекомендовал вам вариант №1 с некластеризованным индексом по включенному идентификатору.

Ответ 4

Я бы сделал следующее:

• Некластерный индекс на [Id]
• Кластеризованный индекс в [Дата]
• Преобразуйте тип данных [sales] в числовой, а не в float

Ответ 5

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

Ответ 6

Кластеризованный индекс в столбце даты не подходит, если у вас будут вставленные вставки, которые будут вставлены быстрее, чем разрешение datetime 3,33 мс. если вы это сделаете, вы получите 2 ключа с одинаковым значением, и ваш индекс должен будет получить еще один внутренний уникальный идентификатор, который увеличит его размер.

я бы пошел С# 2 ваших вариантов.