При проектировании базы данных мы часто используем guid или int в качестве основного ключа, и согласно полученным знаниям, мы всегда считали, что int эффективнее как основной ключ, но это невозможно без тщательного тестирования
Объясните причину. Сегодня во время оптимизации базы данных я столкнулся с этой проблемой, поэтому провёл тест.
Среда тестирования:
Настольный ПК Pentiun(R) 4 процессора 3.06 ГГц Win XP professional 1,5G DDR RAM SQL Server 2005 Personal
Процесс тестирования:
Сначала создайте тестовую базу данных, Test
Результаты теста следующие:
Как уже упоминалось, эффективность использования 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. Добавление некластерных индексов к соответствующим полям внешних ключей, то есть в поля, используемые для запросов к объединению, значительно помогает повысить производительность. Поле условия где также может быть добавлено по мере необходимости для некластерных индексов.
2. При использовании типа Guid в качестве первичного ключа тип данных должен быть уникальным идентификатором, и обязательно отменяйте «агрегатный индекс» первичного ключа
3. Для систем, которые не требуют миграции, или для небольших систем, всё равно очень удобно использовать int в качестве первичного ключа, и есть определённое повышение эффективности.
|