SQL Server 2005 - влияние размера строки на производительность запросов?

Question

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

Какой-нибудь хороший ресурс, детализирующий такие эффекты? Есть опыт?

Спасибо.

Answer 1

Настройка размера строки является серьезной проблемой только в том случае, если СУБД выполняет полное сканирование строки таблицы, если ваш запрос может выбирать строки, используя только индексы, тогда размер строки не так важен (если вы не возвращаете очень большое количество строк, в которых важен IO возврата фактического результата).

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

Я бы ожидал, что это будет главным фактором в относительно небольшом числе ситуаций.

Answer 2

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

Однако, то, что вы ищете, это iostatistics. Есть несколько способов их собрать. Хорошее введение можно найти -> здесь .

Answer 3

Первое, что я хотел бы сделать, это убедиться, что ваши индексы были перестроены; если вы имеете дело с огромным объемом данных и перестроение индекса невозможно (если SQL Server 2005 и более поздних версий вы можете выполнять перестроения в режиме онлайн, не блокируя всех пользователей), убедитесь, что ваша статистика актуальна (подробнее об этом позже). 1001 *

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

SET STATISTICS IO ON
GO


-- Execute your query here


SET STATISTICS IO OFF
GO

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

Answer 4

Если вы заинтересованы в минимизации ввода-вывода при чтении данных, вам нужно проверить, покрывают ли индексы запрос или нет. Чтобы минимизировать IO, вы должны выбрать столбец, включенный в индекс, или индексы, которые охватывают все столбцы, используемые в запросе, таким образом оптимизатор будет считывать данные из индексов и никогда не будет читать данные из фактических строк таблицы.
Если вы изучаете детали такого рода, возможно, вам следует подумать об обновлении HW, замене контроллеров или добавлении большего количества дисков, чтобы иметь больше дисковых шпинделей, доступных для обработчика запросов, и, таким образом, позволяя SQL считывать больше данных одновременно
< бр /> Дисковый ввод-вывод SQL Server часто является причиной узких мест в большинстве систем. Подсистема ввода / вывода включает в себя диски, платы контроллера дисков и системную шину. Если дисковый ввод / вывод постоянно высок, рассмотрим:

Переместите некоторые файлы базы данных на дополнительный диск или сервер.
Используйте более быстрый дисковод или избыточный массив недорогих дисков (RAID).
Добавьте дополнительные диски в массив RAID, если он уже используется.
Настройте свое приложение или базу данных, чтобы уменьшить количество операций доступа к диску.
Рассмотрите охват индекса, лучшие показатели и / или нормализацию.

Microsoft SQL Server использует вызовы ввода-вывода Microsoft Windows для чтения и записи на диск. SQL Server управляет, когда и как выполняется дисковый ввод-вывод, но операционная система Windows выполняет основные операции ввода-вывода. Приложения и системы, связанные с вводом-выводом, могут поддерживать диск постоянно активным.

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

Answer 5

Если приложение является транзакционным, посмотрите на используемые в таблице индексы. Разделение таблиц вряд ли поможет в этой ситуации.

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

Если вы выполняете соединение между двумя большими таблицами, которые не находятся в отношении 1: M, оптимизатору запросов может потребоваться разрешить предикаты для каждой таблицы отдельно, а затем объединить относительно большие промежуточные наборы результатов или запустить медленный оператор, например, вложенный петли, соответствующие одной стороне соединения. В этом случае вы можете получить выгоду от поддерживаемой триггером денормализованной таблицы для выполнения поиска. Я видел хорошие результаты, полученные из денормализованных таблиц поиска для сложных экранов в нескольких больших приложениях.

Answer 6

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

Таким образом, единственный верный ответ на ваш вопрос: Это зависит:)

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

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

Answer 7

Я думаю, что вы будете дальше, используя стандартные методы оптимизации - проверьте ваш план выполнения, трассировку профилировщика и т. Д. И посмотрите, нужно ли вам настроить индексы, создать статистику и т. Д., - прежде чем смотреть на физическая структура вашего стола.