GUID прекрасны с точки зрения программиста - они гарантированно (почти) уникальны, так почему бы не использовать их повсюду, верно?
Если вы посмотрите на это с точки зрения администратора баз данных и с точки зрения базы данных, по крайней мере, для SQL Server, есть несколько вещей, которые следует учитывать:
- Идентификаторы GUID в качестве первичного ключа (который отвечает за уникальную идентификацию одной строки в вашей таблице) могут быть в порядке - в конце концов, они уникальны, верно?
- однако, SQL Server также имеет концепцию ключа кластеризации, который физически упорядочивает данные в вашей таблице; если вы не знаете об этом и ничего не делаете явно, ваш первичный ключ становится вашим ключом кластеризации.
Кимберли Трипп (Kimberly Tripp) - всемирно известный эксперт по индексированию и производительности SQL Server - имеет множество постов в блогах о том, почему GUID в качестве ключа кластеризации действительно плохая идея - посмотрите ее блог по индексам .
В частности, ее лучшие практики для ключа кластеризации:
- узкая
- статические
- уникальный
- постоянно увеличивающийся
GUID, как правило, являются статическими и уникальными, но они не являются ни узкими (16 байт против 4 байт для INT), ни постоянно увеличивающимися. Из-за своей природы они уникальны и (псевдо) случайны.
Узкая часть важна, потому что ключ кластеризации будет добавлен к каждой странице индекса для каждого и каждого некластеризованного индекса в вашей таблице - и если у вас есть несколько таких и несколько миллионов строк в вашей таблице это приводит к огромной трате пространства - и не только на вашем диске, но и в оперативной памяти вашего SQL Server.
Постоянно увеличивающаяся часть важна, потому что случайность GUID вызывает большую фрагментацию в ваших индексах, что негативно влияет на вашу производительность во всем. Даже newsequentialid()
SQL Server 2005 и выше на самом деле не создают последовательные идентификаторы GUID повсюду - они на некоторое время последовательные, а затем снова происходит скачок, вызывающий фрагментацию (меньше, чем полностью случайные идентификаторы GUID, но все же).
В общем, если вы действительно обеспокоены производительностью SQL Server, использование GUID в качестве ключа кластеризации - очень плохая идея - используйте INT IDENTITY () вместо этого, возможно, используя GUID как первичный (некластеризованный) ключ, если вам действительно нужно.
Марк