У проєктуванні бази даних ми часто використовуємо guid або int як основний ключ, і згідно з отриманими знаннями, ми завжди вважали, що int ефективніший як основний ключ, але це неможливо без ретельного тестування
Поясніть причину. Сталося, що під час оптимізації бази даних сьогодні я зіткнувся з цією проблемою, тож провів тест.
Тестове середовище:
Настільний ПК Pentiun(R) 4 процесори 3.06GHz
Win XP professional
1,5G DDR RAM
SQL Server 2005 Особистий
Процес тестування:
Спочатку створіть тестову базу даних, Тестуйте
Результати тесту такі:
Як згадувалося вище, ефективність використання int як первинного ключа покращується порівняно з використанням guid як основного ключа, особливо коли є запит до з'єднання та видалення записів.
Більше того, у запиті даних із основним ключем у GUID сьогодні тайм-аут запиту повторювався через вкладення кількох результатів підзапиту. Тому я підтримую використання int як основного ключа і не погоджуюся з guid як основним ключем.
Вищенаведені погляди відображають особисті думки, і кожен може висловити свою думку та пояснити переваги та недоліки guid і int як основного ключа.
Подальші тести:
Після того, як брати нагадали про це, сьогодні до двох підтаблиць додано некластерний індекс:
СТВОРИТИ НЕКЛАСТЕРИЗОВАНИЙ ІНДЕКС Index_Detail_Guid на Test_Guid_Detail(Guid)
СТВОРИТИ НЕКЛАСТЕРИЗОВАНИЙ ІНДЕКС Index_Detail_id на Test_Int_Detail(id)
Потім я провів внутрішній запит щодо підключення і виявив, що, як @Xu сказала Шаося, ефективність дійсно недостатньо очевидна, щоб свідчити про понад 50%, і фактично лише близько 23% покращення, що все ще прийнятно.
Тому рекомендується
1. У системах, які часто потребують міграції даних, рекомендується використовувати Guid. А додавання некластеризованих індексів до відповідних полів зовнішніх ключів, тобто полів, що використовуються для запитів на об'єднання, дуже корисне для підвищення продуктивності. Поле умови where також можна додавати для некластеризованих індексів.
2. При використанні типу Guid як первинного ключа тип даних має бути унікальним ідентифікатором, і обов'язково не забудьте скасувати «агрегатний індекс» первинного ключа
3. Для систем, які не потребують міграції, або для невеликих систем, дуже зручно використовувати int як первинний ключ, і є певне підвищення ефективності.
|
Опубліковано 09.10.2019 16:48:35
|
|
|
|
Орендодавець|
Опубліковано 08.02.2021 11:03:12
|
Опубліковано 20.03.2025 16:13:51