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

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

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

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

4

4 ответы

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

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

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

Также рекомендуется использовать отдельную таблицу Tom H.

2
добавлено

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

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

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

2
добавлено

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

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

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

2
добавлено

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

1
добавлено
SqlCom.ru - Стиль жизни SQL
SqlCom.ru - Стиль жизни SQL
908 участник(ов)

Правила чата - https://t.me/sqlcom/88269 @sqlcom - основной канал (только MS SQL) @sql_ninja - второй канал (SQL вопросы начального уровня и свободное общение) @Gopnegbot - Викторина по SQL Server (наберите в привате /quiz). Предложения в @sql_ninja

SQL_Ninja
SQL_Ninja
340 участник(ов)

Правила чата - https://t.me/sqlcom/88269 @sqlcom - основной канал (только SQL) @sql_ninja - второй канал (SQL вопросы начального уровня и свободное общение) @Gopnegbot - Викторина по SQL Server (наберите в привате /quiz)