Я хочу создать базу данных SQL Server с одной таблицей, которая будет содержать 200 000 000 записей.Быстрый ключевой ключ SQL Server
Таблица имеет 2 столбца: Id и значение, где Id является PrimaryKey и индексируется.
Вопрос о производительности SQL Server, насколько быстро я могу получить значение с помощью первичного ключа?
В целом очень быстро, поскольку SQL Server хранит данные в деревьях, и он может быстро найти данные, хранящиеся таким образом (я предполагаю, что «индексированный» означает, что это кластеризованный ключ).
Однако есть много других аспектов, таких как аппаратное обеспечение (память, скорость диска и т. Д.) И шаблон использования, который играет роль, так что нет четкого ответа на ваш вопрос.
Индексированный столбец, в частности первичный ключ, можно получить очень быстро. Если вы намерены часто обращаться к записям в порядке сортировки, кластерный первичный ключ может улучшить время доступа. С кластеризованным индексом строки хранятся в физическом порядке, соответствующем порядку индекса.
См: What do Clustered and Non clustered index actually mean?
Запись должна быть вставлена последовательно (по отношению к колонку (ы) индекса) при использовании кластерного индекса, в противном случае страница вставка и фрагментация индекса будет происходить. Кластерные индексы лучше всего работают с столбцами идентификации. Если вы используете GUID в качестве столбца индекса, используйте функцию newsequentialid(). (Согласно разъяснениям @Lucero)
Другой оптимизация будет использовать индекс покрытия. Это индекс, включающий все столбцы запроса. С индексом покрытия SQL-сервер нуждается только в доступе к индексу. Строки не должны быть доступны отдельно. Это уменьшает количество обращений к диску.
Using Covering Indexes to Improve Query Performance
Первичный ключ генерируется в виде букв и цифр: что-то вроде этого: 'A2B3C4D5X'. Приказ на самом деле не имеет значения. Мне нужно получить значение этого первичного ключа – user2818430
. Тогда, вероятно, кластерный индекс не будет улучшать запросы, а замедляет вставки, если первичные ключи вставлены в неупорядоченный путь. –
Вставка в случайные позиции приведет к вставкам и разбиению страниц (то есть фрагментации), однако она не будет физически перемещаться по многим записям (как правило, только на их странице, то есть на 8 КБ). Поэтому, в то время как записи следует лучше всего вставлять последовательно, ваше описание проблемы неточно. Кроме того, GUID не являются плохими сами по себе, они просто проблематичны, если они используются в качестве кластеризованного ключа и генерируются случайным образом. Чтобы решить эту проблему, SQL Server имеет функцию 'newsequentialid()', которая может использоваться как столбец по умолчанию, причем производительность в значительной степени совпадает с характеристиками столбцов. – Lucero
Звучит достаточно просто - почему бы вам не попытаться построить и не увидеть сами ..? Очевидно, что спецификация машины, на которой работает сервер, будет иметь значение, но она должна быть довольно быстрой, я бы подумал. –
С правильно оборудованным сервером правильно проиндексированная таблица (т. Е. Кластерная, чтобы избежать накладных расходов на поиск предметов в сгенерированном индексе), вы должны найти записи почти мгновенно. Тем не менее, если ваш ПК - это строка или что-то еще, вы, вероятно, будете недовольны работой. –
@ DavidT.Macknet: Первичный ключ - это строка, генерирующая нечто вроде этого: A2B3C4D5X – user2818430