влияние количества прогнозов на производительность запроса

Question

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

Answer 1

Я мог бы неправильно понять вопрос, но здесь все равно:

Абсолютное число выбранных вами столбцов не имеет большого значения. Однако , какие выбранные столбцы могут иметь существенное значение в зависимости от индексации таблицы.

Если вы выбираете только столбцы, которые охватываются индексом, то механизм БД может использовать только индекс для запроса, даже не извлекая данные таблицы. Если вы используете хотя бы один столбец, который не охвачен, он должен извлечь всю строку (поиск ключей), и это значительно снизит производительность. Иногда это приводит к снижению производительности настолько, что ядро ​​БД предпочитает выполнять полное сканирование, а не беспокоиться об индексе; это зависит от количества выбранных строк.

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

Быстрый пример для SQL Server 2005+ - допустим, это ваша таблица:

ID int NOT NULL IDENTITY PRIMARY KEY CLUSTERED,
Name varchar(50) NOT NULL,
Status tinyint NOT NULL

Если мы создадим этот индекс:

CREATE INDEX IX_MyTable
ON MyTable (Name)

Тогда этот запрос будет быстрым:

SELECT ID
FROM MyTable
WHERE Name = 'Aaron'

Но этот запрос будет медленным (er):

SELECT ID, Name, Status
FROM MyTable
WHERE Name = 'Aaron'

Если мы изменим индекс на индекс покрытия, то есть

CREATE INDEX IX_MyTable
ON MyTable (Name)
INCLUDE (Status)

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

Answer 2

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

Answer 3

Ограничение количества столбцов не оказывает ощутимого влияния на запрос. Почти повсеместно вся строка извлекается в кеш. Проекция происходит последней в конвейере SQL.

Проекционная часть обработки должна выполняться последней (например, после GROUP BY), поскольку она может включать создание агрегатов. Также для обработки JOIN, WHERE и ORDER BY может потребоваться множество столбцов. Больше столбцов, чем в итоге возвращается в наборе результатов. Вряд ли стоит добавлять шаг в план запроса для выполнения проекций, чтобы как-то сэкономить небольшой ввод-вывод.

Проверьте документацию вашего плана запроса. В плане запроса нет узла "project". Это небольшая часть формулировки набора результатов.

Чтобы уйти от «выборки всей строки», вам нужно обратиться к столбчатой ​​(«инвертированной») базе данных.

Answer 4

Чтобы продемонстрировать, что уже написал tvanfosson, что существует «стоимость передачи», я выполнил следующие два оператора в базе данных MSSQL 2000 из анализатора запросов.

ВЫБРАТЬ длину данных (текст) ОТ системного комментария

ВЫБРАТЬ текст ОТ СИСТЕМЫ

Оба результата вернули 947 строк, но первый занял 5 мс, а второй - 973 мс.

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

Answer 5

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

Answer 6

Это может зависеть от сервера, с которым вы имеете дело (и, в случае MySQL, от механизма хранения). Например, есть хотя бы один механизм хранения MySQL, который выполняет хранение по столбцам вместо хранения по строкам, и в этом случае большее количество столбцов действительно может занять больше времени.

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