Нужно ли удалять уникальный индекс при изменении размера столбца nvarchar? И будет ли таблица заблокирована при воссоздании индекса?

14

В нашей базе данных существует большая таблица, которая более или менее выглядит так:

CREATE TABLE dbo.production_data
(
    pd_id BIGINT PRIMARY KEY,
    serial NVARCHAR(16) NOT NULL UNIQUE,
    ...
);

но теперь размер последовательного поля стал слишком низким, поэтому я хочу изменить его на 32. Средство сравнения схем Visual Studio предлагает сделать это следующим образом:

DROP INDEX ux_production_data_serial ON dbo.production_data;
GO
ALTER TABLE dbo.production_data ALTER COLUMN serial NVARCHAR(32) NOT NULL;
GO
CREATE INDEX ux_production_data_serial ON dbo.production_data(serial ASC);

Это действительно нужно? Или больше похоже на ультра экономичный способ сделать это?

Кроме того, будет ли заблокирована моя таблица при воссоздании уникального индекса? Потому что это было бы большой проблемой (так как таблица имеет 30 миллионов строк, и я думаю, что воссоздание индекса займет довольно много времени), потому что следующее окно обслуживания будет через несколько месяцев. Каковы мои альтернативы?

Staeff
источник

Ответы:

24

Нет необходимости удалять и заново создавать индекс.

Просто используйте

ALTER TABLE dbo.production_data
  ALTER COLUMN serial NVARCHAR(32) NOT NULL; 

Это только метаданные изменения.

Изменение столбца с NVARCHAR(16)на NVARCHAR(32)вообще не влияет на хранилище.

Переход в другую сторону раунд (от NVARCHAR(32)до NVARCHAR(16)) даст вам ошибку об объектах , находящихся в зависимости от колонки , хотя так может быть , Visual Studio просто всегда создает что котел пластины код вместо проверки , является ли он на самом деле требуется.

Мартин Смит
источник
2
Любопытно, почему Visual Studio записывает это как DROP / CREATE INDEX. Вероятно, ненужный, безусловный CYA.
Аарон Бертран
2
@AaronBertrand - я полагаю, это просто отсутствующая оптимизация для случаев, когда она не требуется. В онлайновых книгах указывалось, что это было необходимо в тех случаях, когда продукт фактически не требовал этого до этого обновления
Мартин Смит,