как мне убедиться, что mytable эффективен

Question

Я создаю новую таблицу, в которой потенциально может быть 200К строк.Я хотел бы убедиться, что запросы к этой таблице эффективны.

В прошлом я всегда давал строке уникальный идентификатор в предположении, что это приведет к индексу:

CREATE TABLE [dbo].[Equipment](
    [EquipID] [nchar](20) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
    [EquipDescription] [nchar](100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
    [Category] [nchar](100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
    [id] [int] IDENTITY(1,1) NOT NULL
) ON [PRIMARY]

этого достаточно?, если я устанавливаю первичный ключ.

Если у кого-то есть предложения, пожалуйста, дайте им летать.

T-SQL, SQL2000,

Answer 1

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

Индексы также не без затрат, они делают вашибазы данных больше, и они увеличивают стоимость модификации таблицы.

Эта статья , хотя старые, кажется, дают хороший обзор индексов.

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

Answer 2

Оптимизация базы данных - это целое искусство / наука, но и моделирование данных.Сначала убедитесь, что ваша схема надежна и поддерживает ваше приложение.Затем вы можете добавить индексы для повышения производительности запросов.Но не делайте выбор моделирования данных, основываясь на некотором представлении о том, что выбор каким-то образом ускорит запрос к таблице.

1) Все таблицы должны иметь первичный ключ по причинам, отличным от производительности.Вы должны иметь возможность однозначно идентифицировать запись.

2) Производительность запросов и то, какие индексы повысят их эффективность, зависят от запроса.Если вы используете столбец в предложении JOIN, WHERE или ORDER BY, то у него должен быть индекс.Ваш первичный ключ автоматически получит индекс, поэтому подумайте, какие другие столбцы могут быть использованы таким образом.В некоторых случаях многостолбцовые индексы являются лучшим выбором.

Answer 3

Лучше всего создать первичный ключ на столе.Как указано @deinst, вы не получите индексы, если не создадите их явно.Создание первичного ключа - один из способов создания индекса.

Столбец [id], вероятно, является хорошим кандидатом на первичный ключ.И, вероятно, это нормально, если это будет ваш кластеризованный индекс (вы получаете один кластеризованный индекс на таблицу), который используется по умолчанию при создании первичного ключа.

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

Является ли [EquipID] естественным ключом для таблицы.Естественный ключ является уникальным атрибутом в бизнес-сфере.Как люди в бизнесе ссылаются на каждый элемент.Если [EquipID] является естественным ключом, вы можете добавить уникальное ограничение или уникальный индекс для этого столбца, и вы можете изменить его обнуляемость на NOT NULL.

Answer 4

На этот вопрос невозможно ответить, не опубликовав также Запросы и Отношения , которые у вас будут.

• Собираетесь ли вы всегда ссылаться на оборудование по id?Или EquipID?
• Сохраняют ли другие таблицы ссылки (внешние ключи) на оборудование, сохраняя значение id или EquipID?
• Собираетесь ли вы агрегировать по Category?
• Есть ли иерархия, подразумеваемая Category?
• Меняется ли когда-либо EquipID для оборудования?

Answer 5

Первое, что вы должны спросить себя: «Каковы свойства« оборудования »?»Может ли часть оборудования существовать без EquipID, Описание или Категории?Если нет, то эти столбцы не должны иметь нулевое значение.

Второй - «что однозначно определяет часть« Оборудования »?»Это EquipID?Тогда это должен быть ваш первичный ключ.Это сочетание EquipID и Категория?Затем у вас есть составной первичный ключ, состоящий из обоих столбцов.Иногда, однако, данные не поддаются первичному ключу, к которому легко можно присоединиться в полностью реляционной модели.Таким образом, вы могли бы рассмотреть столбец Identity ID, как вы показываете - это известно как суррогатный ключ.Знайте, что создание первичного ключа по умолчанию создает кластерный индекс для этих ключевых столбцов.Если вы используете подход с суррогатным ключом, IMHO, это хорошая идея, чтобы создать еще один уникальный индекс уникальности вашего объекта (т. Е. EquipID).

Что касается других индексов, вам следует задать себе вопрос"Какие столбцы я буду опрашивать чаще всего?"Возможно, у вас будет много вопросов, таких как «ВЫБЕРИТЕ ИСПОЛЬЗОВАТЬ ОТ ОБОРУДОВАНИЯ, ГДЕ Категория = 3».Это может означать, что Category является хорошим кандидатом в столбец для индекса.

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

Хороший подход к этому может быть примерно таким, как показано ниже (быстро объединено, не проверено):

CREATE TABLE [dbo].[Equipment]( 
  [EquipID] [nchar](20) NOT NULL
  ,[EquipDescription] [nchar](100) NOT NULL
  ,[CategoryID] [bigint] NOT NULL
  ,CONSTRAINT [PK_Equipment] PRIMARY KEY CLUSTERED (
    [EquipID] ASC
  )
) ON [PRIMARY] 
GO

CREATE TABLE [dbo].[Categories]( 
  [CategoryID] [bigint] IDENTITY(1,1) NOT NULL 
  ,[CategoryName] [nchar](100) NOT NULL
  ,CONSTRAINT [PK_Categories] PRIMARY KEY CLUSTERED (
    [CategoryID] ASC
  )
) ON [PRIMARY] 
GO

CREATE NONCLUSTERED INDEX [IDX_Equipment_Category] ON [dbo].[Equipment] (
  [CategoryID] ASC
) ON [PRIMARY]

CREATE UNIQUE NONCLUSTERED INDEX [IDX_Categories_CategoryName] ON [dbo].[Categories] (
  [CategoryName] ASC
) ON [PRIMARY]

ALTER TABLE [dbo].[Equipment]  WITH CHECK ADD  CONSTRAINT [FK_Equipment_Categories] 
FOREIGN KEY([CategoryID]) REFERENCES [dbo].[Categories] ([CategoryID])
GO