Ограничения на количество строк в таблице SQL Server

Question

Существуют ли жесткие ограничения на количество строк в таблице в таблице сервера SQL? У меня сложилось впечатление, что единственное ограничение основано на физической памяти.

В какой момент производительность значительно снижается, если она вообще наблюдается, для таблиц с индексом и без индекса. Есть ли общие практики для очень больших столов?

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

Answer 1

В дополнение ко всему вышесказанному, которые являются отличными рекомендациями, я подумал, что дам немного больше контекста в отношении индекса / производительности.

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

Если вы действительно обеспокоены скоростью вставки, разбиением, а также ОЧЕНЬ тщательным рассмотрением индекса, то это будет ключевым.

Рекомендовать отдельную таблицу для Tom H также хорошая идея.

Answer 2

BrianV правильно. Трудно дать правило, потому что оно сильно меняется в зависимости от того, как вы будете использовать таблицу, как она проиндексирована, каковы фактические столбцы в таблице и т. Д.

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

Еще одна вещь, которую следует учитывать, - это иметь отдельную таблицу журнала изменений для каждой из ваших реальных таблиц, если вы еще не планируете это делать. Использование одной таблицы журналов делает ОЧЕНЬ сложным работу. Вы обычно должны регистрировать информацию в текстовом поле произвольной формы, которое трудно запросить и обработать. Кроме того, сложно взглянуть на данные, если у вас есть строка для каждого столбца, которая была изменена, потому что вам нужно сделать много объединений, чтобы посмотреть на изменения, которые происходят одновременно в одно и то же время.

Answer 3

Вы правы в том, что количество строк ограничено вашим доступным хранилищем.

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

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

Answer 4

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