Сколько записей я могу сохранить в таблице SQL-сервера, прежде чем это станет ужасным?

У SQL Server не возникнет проблем с сохранением такого количества записей.

Если вы правильно спроектировали индексы и ваша база данных правильно нормализована, у вас не будет абсолютно никаких проблем с доступом к произвольному количеству записей. Часто люди принимают неверные проектные решения на раннем этапе, когда в их базе данных нет информации, и вы никогда не узнаете об этом, потому что все быстро для малых «n» .

Итак, хотя я скажу, что SQL Server может справиться с тем, что вы делаете, я бы также сказал, что сейчас самое подходящее время, чтобы расслабиться и посмотреть, как выполняются ваши запросы с SQL Server Profiler. Все еще быстро? Вы видите чрезмерное сканирование или хеширование в ваших частых запросах, что приводит к снижению производительности? Если да, то сейчас самое время проанализировать и исправить эти проблемы.

Кстати, людям очень нравится думать об ограничениях на размер, основанных на количестве строк и столбцов. Попробуйте пойти дальше и поговорить о байтах , потому что, в конечном счете, байты - это то, что сканируется в запросе отчета, а байты - это то, что сохраняется на диск.

Слишком много на самом деле. Я отвечаю за веб-сайт, на котором зарегистрировано 2 миллиона пользователей.

Некоторые из наших таблиц содержат более 100 миллионов записей, и мы можем достичь отличной производительности с 4 миллионами ежедневных просмотров страниц, но я должен признать, что кеширование с хорошей архитектурой является основной причиной того, что все не становится некрасивым.

Даже MS Access может посмеяться над таблицей в полмиллиона строк (в зависимости от размера строки).

Если у вас нет запросов для профилирования, подумайте о таблице как о файле. Строки не являются важным числом по сравнению с sp_spaceused .

Если у вас есть какие-то запросы, считайте таблицу структурой данных. Как можно выполнить запрос с минимальным количеством операций ввода-вывода. Используйте план запроса и УСТАНОВИТЕ ВХОД-ВЫВОД СТАТИСТИКИ ВКЛ.

Программное обеспечение может справиться с этим, может ваш сервер? Что ж, это зависит .

Вы просто архивируете? Конечно, получите сто миллиардов строк, это не волнует, проблемы с производительностью возникают тогда, когда вы запрашиваете данные. Чем больше он становится, тем больше места вам нужно с точки зрения общего хранилища и для операций (удаления, сегментов отката и т. Д.) С этими данными, предпочтительно в памяти, но в противном случае на быстром диске tempdb.

Что важнее для SQL-сервера, чем процессор для больших наборов данных (хотя процессор определенно влияет на время , которое он занимает, а не на порог запросов / данных, которые он может обрабатывать), то это память и пространство (и HD и ОЗУ, поскольку при больших операциях она будет переполняться в TempDB), это говорит о емкости . Для производительности вам потребуются операции ввода-вывода диска, память и мощность процессора - все вместе.

Краткий ответ на вопрос, справится ли он с этим да , если у вас достаточно места. Он справляется с этим достаточно быстро ? Это зависит от того, какие запросы вы выполняете и насколько важна производительность.

И последнее, не забудьте взглянуть на другие вопросы здесь по оптимизации больших таблиц .

Если вам нужна предельно высокая производительность, я бы разработал PK так, чтобы он не был уникальным идентификатором. Если вам нужно объединять наборы данных, я бы выбрал INT IDENTITY + SMALLINT (или даже tinyint) для определения места происхождения. Вы мало рассказываете о своем проекте, но есть проблемы при попытке использовать uniqueidentifier в качестве кластеризованного индекса.

При наличии соответствующего серверного оборудования большинство приличных проектов будут работать нормально. Не планируйте запускать на сервере ничего, кроме ОС и SQL Server. Основная проблема - оперативная память, для наилучшей производительности вам потребуется достаточно оперативной памяти для всей базы данных, индексов и т.д., и это сверх того, что будет потреблять ОС. Я даже видел, как массивные серверы помогают плохим проектам работать очень хорошо.

SQL Server может обрабатывать данные размером в терабайты. Главное, чтобы вы правильно спроектировали систему и правильно подобрали оборудование. Например, вам может понадобиться разбиение на разделы. Вам определенно нужно думать о каждой миллисекунде производительности каждого запроса и избегать плохо работающих конструкций и техник запросов, таких как таблицы EAV, коррелированные подзапросы, курсоры и "like '%sometext%'".

Если вы ожидаете, что ваша база данных будет настолько большой, то купите и прочитайте от корки до корки книгу по настройке производительности до начала проектирования. Плохой дизайн убивает производительность базы данных, и это очень трудно исправить, когда у вас есть 80 000 000 записей.

Я также советую вам найти администратора с опытом работы с высокопроизводительными базами данных большого объема. Это совершенно новая игра в плане дизайна, и она должна быть продумана с самого начала.

Молодцы, что проводите такое тестирование сейчас, пока в системе нет такого количества записей.