Я разрабатываю приложение с интенсивным использованием базы данных, которое поддерживает около 5 таблиц. Каждая из этих таблиц содержит многие тысячи записей. Все таблицы используют кластеризованные первичные ключи GUID. Для большей эффективности я удалил внешние ключи между таблицами.
Я запускаю сценарий длиной 65000 строк, который создает целую кучу таблиц (включая мои таблицы) и хранимых процедур (примерно половина времени, потраченного на них), затем продолжает вставлять в мои таблицы около 40000 записей, а затем обновляет около 20000 из этих записей.
На моей 8-ядерной машине AMD 3,5 ГГц это занимает 1:15.
Удивительно, но если я изменю эти 5 таблиц таким образом, что - Добавлю БОЛЬШОЙ первичный суррогатный ключ идентификации (запросы по-прежнему соединяются с использованием GUID) - Понижу предыдущий кластеризованный первичный ключ GUID до уникального столбца
то он работает в 3:00 минут!
Изменение его с BIGINT на INT занимает примерно 1:30!
Как возможно, что кластерный ПК GUID работает значительно быстрее, чем автоматически увеличивающийся INT, и намного быстрее, чем автоинкрементируемый кластерный ПК BIGINT?
ПРИМЕЧАНИЕ. Сами значения GUID генерируются в коде, а не в базе данных.
Посмотрите этот упрощенный тестовый скрипт, демонстрирующий, что я имею в виду.
int/bigintнужно поддерживать два индекса, а не один. И у некластеризованного Guid будут точно такие же проблемы с фрагментацией, как и у кластеризованного Guid. - person Martin Smith schedule 21.05.2013To make it efficient, I've dropped foreign-keys between the tables.- person tommy_o schedule 23.05.2013