0

В базе данных SQL Server 2000 есть две таблицы с более чем 50 миллионами записей, в основном «прочитанные», а не «запись» или «удаление». Я хочу переконфигурировать таблицу.Большое разбиение таблиц в SQL Server 2000

Создает ли разделение на одном сервере, помогая улучшить скорость? (имеет ли смысл создавать раздел в один сервер?)

Создает новую файловую группу и помещает эту таблицу в это (на одном сервере) выгодно?

За исключением: переиндексации, каковы другие возможные способы повышения скорости сбора данных в таких таблицах?

Я вытаращил это много, но не нашли ничего, за 2000

Спасибо за любые предложения

+0

Сначала включите план выполнения и посмотрите, что ваш запрос имеет любое сканирование таблиц или индексов. Если это так, то это следует рассматривать, поскольку план выполнения результатов должен показывать только поиск индекса. Тем не менее он не отвечает ожиданию ответа, а затем ищет разбиение. –

+0

", которые имеют более 50 миллионов записей" - на самом деле это не так много. У меня есть таблицы с 150 миллионами строк и без разбиения и производительности. –

+0

@MitchWheat: как вы относитесь к моим столам? возможно, потому, что они присоединяются к другим таблицам, скорость неприемлема. –

ответ

0

Маловероятно, что разбиение (распределяли представление или таблица разделов) позволит повысить производительность в этом сценарии. Индексируйте настройку запроса, что является ключом к производительности, что еще более важно с большими таблицами. Если у вас проблемы с производительностью, я предлагаю вам отправить DDL и примерный запрос проблемы.

В начале сказано, что разбиение может улучшить управляемость. Например, секционированное представление может позволить удовлетворить SLA за счет сокращения времени, которое требуется для автономных задач, таких как перестройка индекса данных текущего года. Я бы не ожидал, что это будет болезненная точка с только 50 миллионами строк на современном оборудовании.

Разделение данных по отдельным файловым группам может повысить производительность в специализированных случаях, таких как параллельное сканирование разных лет данных. Однако вы упомянули, что данные за текущий год запрашиваются в 99% случаев, поэтому в вашей ситуации может не быть большой пользы.

+0

Guzman: Благодарю за ваш полный комментарий. только один вопрос, если рост в этой таблице был высоким (около 6 миллионов записей в год), индексирует лучшее решение для оптимизации? и другой вопрос: В этой таблице есть несколько столбцов, которые в большинстве случаев являются NULL. Является ли хорошей идеей, хочу ли я отделить таблицу и поместить эти столбцы во вторую таблицу, связанную с базовым, помогает ли она в производительности? ? –

+0

Индексирование позволяет запросам касаться минимальных страниц для задачи под рукой независимо от того, растет ли таблица или нет. Это ключ к производительности в OLTP или смешанной рабочей нагрузке. Добавление другой таблицы может быть лучше всего с точки зрения дизайна и повысить производительность в случаях, когда соединение с этой таблицей не требуется. Но производительность может быть хуже, если вы все LEFT JOIN для существующих запросов. Иногда возникают компромиссы между хорошим нормализованным дизайном и производительностью. –