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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

Отдельная рекомендация таблицы Тома Х также является хорошей идеей.