INT по сравнению с Уникальным идентификатором для поля ID в базе данных

GUID проблематичны как кластерные ключи из-за высокого случайность. Эта проблема была рассмотрена Полом Рэндалом в последней колонке вопросов и ответов журнала Technet Magazine: Я хотел бы использовать GUID в качестве ключа кластеризованного индекса, но другие утверждают, что это может привести к проблемам с производительностью индексов. Верно ли это, и если да, то можете ли вы объяснить, почему?

Теперь имейте в виду, что речь идет именно о кластерных индексах. Вы говорите, что хотите использовать столбец как «ID», но неясно, имеете ли вы в виду его как кластерный ключ или просто первичный ключ. Обычно они перекрываются, поэтому я предполагаю, что вы хотите использовать их как кластерный индекс. Причины, по которым это плохой выбор, объясняются в ссылке на упомянутую выше статью.

Для некластеризованных индексов GUID все еще имеют некоторые проблемы, но не настолько большие, как когда они являются крайним левым кластеризованным ключом таблицы. Опять же, случайность идентификаторов GUID приводит к разделению и фрагментации страниц, будь то только на уровне некластеризованного индекса (проблема гораздо меньшего размера).

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

Я вызываю все эти детали в своего рода импровизированной защите GUID, потому что они получают в последнее время много плохой прессы, и некоторые из них незаслуженно. У них есть свои достоинства, и они незаменимы в любой распределенной системе (в тот момент, когда вы говорите о перемещении данных, будь то репликация, структура синхронизации или что-то еще). Я видел, как плохие решения принимались на основе плохой репутации GUID, когда их избегали без должного рассмотрения. Но это правда, , если вам нужно использовать GUID в качестве кластеризованного ключа, убедитесь, что вы решили проблему случайности: по возможности используйте последовательные направляющие .

И, наконец, чтобы ответить на ваш вопрос: if у вас нет конкретной причины использовать идентификаторы GUID, используйте INT.