повышение производительности таблицы базы данных

Question

У меня есть следующая таблица базы данных sql server 2008:

CREATE TABLE [dbo].[cache](
[cache_key] [nvarchar](50) NOT NULL,
[cache_data] [nvarchar](max) NOT NULL,
[expiry_date] [datetime] NOT NULL) ON [PRIMARY]

Я хочу добавить к нему первичный ключ, т.е. сделать столбец cache_key первичным ключом. Этот столбец содержит уникальные строки. Мой вопрос: есть ли какие-либо последствия для того, чтобы сделать столбец nvarchar 50 первичным ключом? Можно ли добавить первичный ключ в этот столбец, содержащий данные, даже если данные cache_key уникальны?

У меня также есть другой скрипт, который запускается каждый день и удаляет данные из таблицы на основе столбца expiry_date. Это может означать удаление до 5000 записей на основе сравнения с этим полем. Повысит ли это производительность, если я создам индекс для этого поля?

Answer 1

Вы можете сделать первичный ключ из всего, что индексируется и уникально. Varchar (50) не проблема. Вы можете добавить определение первичного ключа после факта, если каждая запись имеет уникальное значение в этом столбце. ВАМ не разрешат "первично-ize" столбцы, которые не являются уникальными.

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

Answer 2

В принципе, технически вы можете сделать любой столбец, максимальный размер которого меньше 900 байт, вашим первичным ключом, например, вы не можете сделать NVARCHAR(2000) вашим первичным ключом, но nvarchar(50) работает.

Требования к первичному ключу:

• должно быть уникальным
• не должно быть NULL

Если эти требования выполнены - вы хорошоgo.

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

Если у вас есть таблица, в которой нет ни одного, или только одного некластеризованного индекса - не беспокойтесь.Но если в вашей таблице довольно много некластеризованных индексов (например, таблица Customer, которая может иметь четыре, пять индексов или даже больше), то такой широкий ключ кластеризации (100 байт) переменной ширины не идеален.В этом случае лучше использовать что-то вроде INT IDENTITY в качестве суррогатного ключа и поместить в этот столбец первичный ключ / кластерный индекс.Это сэкономит вам много дискового пространства и сделает вашу таблицу намного лучше.

Узнайте больше о том, что делает хороший ключ кластеризации (на занятой, большой таблице) в блоге Кимберли Триппаpost Постоянно увеличивающийся ключ кластеризации - дебаты по кластерному индексу .......... снова! - высокообразовательный!