GUID проблематичны как кластерные ключи из-за высокой случайности. Эта проблема была рассмотрена Полом Рэндалом в последнем столбце вопросов и ответов журнала Technet Magazine: Я хотел бы использовать GUID в качестве ключа кластеризованного индекса, но другие утверждают, что это может привести к проблемам с производительностью индексов. Это правда, и если да, то можете ли вы объяснить, почему?
Теперь имейте в виду, что речь идет именно о кластеризованных индексах. Вы говорите, что хотите использовать столбец как «ID», поэтому неясно, имеете ли вы в виду его как кластерный ключ или просто первичный ключ. Обычно эти два перекрываются, поэтому я предполагаю, что вы хотите использовать его в качестве кластерного индекса. Причины такого неудачного выбора объясняются в ссылке на статью, о которой я упоминал выше.
Для некластеризованных индексов GUID по-прежнему имеют некоторые проблемы, но не такие большие, как когда они являются крайним левым кластеризованным ключом таблицы. Опять же, случайность идентификаторов GUID приводит к разбивке страниц и фрагментации, будь то только на уровне некластеризованного индекса (гораздо меньшая проблема).
Существует множество городских легенд, связанных с использованием GUID, которые осуждают их на основании их размера (16 байт) по сравнению с int (4 байт) и обещают ужасную гибель производительности, если они используются. Это немного преувеличено. Ключ размера 16 может быть очень полезным ключом в правильно спроектированной модели данных. Хотя верно то, что, будучи в 4 раза больше целого, приводит к большему количеству неконечных страниц с меньшей плотностью в индексах, это не представляет реальной проблемы для подавляющего большинства таблиц. Структура b-дерева - это естественно хорошо сбалансированное дерево, и глубина обхода дерева редко является проблемой, поэтому поиск значения на основе ключа GUID в отличие от ключа INT схож по производительности. Обход листовой страницы (т. Е. Сканирование таблицы) не учитывает не листовые страницы, и влияние размера GUID на размер страницы, как правило, довольно мало, поскольку сама запись значительно больше, чем введенные дополнительные 12 байтов. по GUID. Поэтому я бы взял совет «услышь-скажи», основанный на «16 байтов против 4» с довольно большой долей соли. Проанализируйте каждый отдельный случай и решите, действительно ли влияние на размер имеет реальное значение: сколько других столбцов находится в таблице (т. Е. Какое влияние имеет размер GUID на листовых страницах) и сколько ссылок используют его (т.е. сколько других таблиц увеличится из-за того, что им нужно хранить больший внешний ключ).
Я выкрикиваю все эти детали в некой импровизированной защите GUID, потому что в последнее время они получают много плохой прессы, а некоторые незаслуженно. Они имеют свои достоинства и незаменимы в любой распределенной системе (в момент, когда вы говорите о перемещении данных, будь то через репликацию или синхронизацию или что-то еще). Я видел плохие решения, основанные на плохой репутации GUID, когда их избегали без должного рассмотрения. Но это правда, если вам нужно использовать GUID в качестве кластерного ключа, убедитесь, что вы решаете проблему случайности: используйте последовательные направляющие , когда это возможно.
И, наконец, чтобы ответить на ваш вопрос: , если у вас нет конкретной причины использовать GUID, используйте INT.