Наслідки використання унікального некластеризованого індексу з покриваючими стовпцями замість первинного ключа

У нас є велика таблиця, в [MyTable]якій зараз є і a Primary Key, і a Unique Non Clustered Indexв тому ж стовпці ( [KeyColumn]). Індекс U NC також має додаткові покривні колони.

Наявність як ПК, так і унікального індексу NC в одних стовпцях видається зайвим, тому я розглядав питання про видалення первинного ключа і замість цього використовував унікальний індекс, не кластеризований для цілей референтної цілісності.

Зауважте, що таблиця повністю кластеризована іншим стовпцем.

тобто у нас є:

ALTER TABLE [MyTable]
    ADD CONSTRAINT [PK_MyTable] 
    PRIMARY KEY NONCLUSTERED ([KeyColumn])
GO

І

CREATE UNIQUE NONCLUSTERED INDEX [IX_MyTable_SomeIndex] 
    ON [MyTable] ([KeyColumn]) 
    INCLUDE ([Column1], [Column2])
GO

Наскільки я знаю, не можна додати стовпці покриття до первинного ключа, тому я маю намір зробити:

• Скасувати обмеження зовнішніх ключів, на які покладається MyTable.KeyColumn
• Закрийте первинний ключ MyTable.KeyColumnповністю
• Повторно додайте в таблицю іноземні ключі (тобто RI буде застосовано через MyTable.KeyColumn)

Єдине значення, яке я можу зробити, це зробити те, що ми не отримаємо символ візуального ключа на наших ERD-діаграмах, і що (лист) щільність індексу буде меншою із-за включених стовпців.

Я прочитав /programming/487314/primary-key-or-unique-index і задоволений аспектами доброчесності та продуктивності.

Моє запитання: Чи є такий підхід хибним?

Редагувати те, що я намагаюся досягти : Оптимізація продуктивності та весняне прибирання . Видаляючи або ПК або індекс, буде менше сторінок, необхідних для моїх індексів = швидше записує, плюс також корисні для обслуговування / експлуатації переваги, тобто один менший індекс для збереження дефрагментів тощо.

Якщо говорити про це, я ніколи раніше не мав таблиці, на яку посилався, без ПК. Однак той факт, що до таблиці було додано індекс NC із стовпцями, що охоплює, означає, що мені потрібно адаптувати своє мислення.

Оптимізація продуктивності. Видаляючи або ПК або індекс, буде менше сторінок, необхідних для моїх індексів = швидше записує, плюс також корисні для обслуговування / експлуатації переваги, тобто один менший індекс для збереження дефрагментів тощо

Вам потрібно вміти доводити, що запропоноване насправді допоможе (вартість проти вигоди). З якої причини розглядається ця зміна? Чи є насправді проблеми з ефективністю цієї таблиці, чи вона просто "виглядає неправильно"?

Ось деякі інші питання, які допоможуть вам прийняти найкраще рішення для вашого оточення:

• Скільки часу буде збережено у вікні обслуговування? У резервному вікні?

• Скільки місця на цьому збережеться (файли даних, файли журналів, резервні копії тощо)?

• Чи справдіINSERT продуктивність на цьому столі справді вузьке місце? Наскільки це покращиться? Чи є видалення індексу найкращою стратегією для усунення цієї проблеми?

• Чи спричинить це проблеми з інструментами та структурами баз даних (особливо для ORM), які очікують, що кожна таблиця матиме первинний ключ, а не лише унікальний індекс? Транзакційна реплікація вимагає первинного ключа в опублікованих таблицях.

• Чи важлива схема бази даних самодокументування?

• Незважаючи на обмежене використання, чи обмеженість індексу первинного ключа все ж дозволяє оптимізатору створювати ефективніші плани для певних запитів? (Використовуйте, sys.dm_db_index_usage_statsщоб дізнатися.)

Особисто кажучи, з того, що ви нам сказали, я б залишив це в спокої, поки не буде доведено, що і (a) додатковий індекс є проблемою, і (b) усунення його - це рішення.

Єдиним типом запиту в цій таблиці, який буде працювати гірше (і лише трохи гірше), будуть ті, які вимагають діапазону значень KeyColumn - так як ці запити в даний момент найкраще обслуговуватимуться за допомогою індексу, який шукає ваш ПК.

Варто мати на увазі, що вартість перевірки референтності цілісності для таблиць, на які посилається ця таблиця, буде вище (знову лише трохи вище).

Поки ви дбаєте про мінливий аспект, тоді вам слід добре вписувати один індекс.

Якби це була моя БД, я, мабуть, пішов би за єдиним унікальним індексом, усі інші речі були б рівними.

Наскільки я знаю, не можна додати стовпці покриття до первинного ключа

Якщо у вас є кластерний індекс на KeyColumn, то, оскільки це кластерний індекс, усі інші стовпці неявно 'охоплені'. Таким чином, ви нічого не отримуєте, додаючи ще один індекс на KeyColumn. Насправді ви сповільнить свої вставки та використаєте більше місця.

Це тому, що кластерний індекс - це не індекс як такий, а лише інструкція зберігати рядки таблиці в порядку індексу. А після того, як ви закрепили рядок за допомогою основного ключа, ви маєте всі інші стовпці прямо там.