Увеличивает ли количество столбцов производительность запросов?

CASE 1: У меня есть таблица с 30 столбцами, и я запрашиваю, используя 4 столбца в предложении where.

CASE 2: У меня есть таблица с 6 столбцами, и я запрашиваю, используя 4 столбца в предложении where.

В чем разница в производительности в обоих случаях?

Например, у меня есть таблица

table A
{
  b varchar(10),
  c varchar(10),
  d varchar(10),
  e varchar(10),
  f varchar(10),
  g varchar(10),
  h varchar(10)

}

SELECT b,c,d
FROM A
WHERE f='foo'

create table B
{
  b varchar(10),
  c varchar(10),
  d varchar(10),
  e varchar(10),
  f varchar(10)

}

SELECT b,c,d
FROM B
WHERE f='foo'

Обе таблицы A и B имеют одинаковую структуру, это означает только разницу в количестве столбцов и столбцов, используемых в том случае, когда условие тоже одно и то же, что и столбец в select. разница в том, что таблица B имеет только неиспользуемый столбец, которые не используются в select и где условие в этом случае есть ли разница в производительности обоих запросов?

Ответы

Ответ 1

Преимущество main для возврата меньше столбцов в SELECT заключается в том, что SQL может избежать чтения из таблицы/кластера, а вместо этого, если он может получить все данные selected от индекса (как индексированные столбцы, так и/или включенные столбцы в случае индекса покрытия). Столбцы, используемые в предикате, т.е. f в вашем примере, ДОЛЖНЫ быть в индексированных столбцах индекса.

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

Изменить. В ответ на обновленное сообщение OP:

Без индексов вообще оба запроса будут выполнять сканирование таблиц. Учитывая, что Table B имеет меньшее количество столбцов, чем Table A, строки на странице (плотность) будут выше на B, и поэтому B будет немного быстрее, поскольку SQL потребуется выборка на меньшее количество страниц.

Однако с показателями ниже

  • Индекс на A(f) INCLUDE (b,c,d)
  • Индекс на B(f) INCLUDE (b,c,d)

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

Изменить

Некоторые другие планы:

  • Индекс на B(f) без каких-либо других клавиш или столбцов INCLUDE или с неполным набором столбцов INCLUDE (то есть один или несколько из b, c or d):

SQL Server, вероятно, потребуется сделать Key или RID Lookup, так как даже если используется индекс, будет необходимо "присоединиться" к таблице, чтобы получить недостающие столбцы в предложении select. (Тип поиска зависит от того, имеет ли таблица кластерный ПК или нет)

  • Прямой некрупный индекс на B(f,b,c,d)

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

Ответ 2

Проверьте это и посмотрите!

Будет разница в производительности, но в 99% случаев вы ее не заметите - обычно вы даже не сможете ее обнаружить!

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

Технический мусор: (с точки зрения Microsoft SQL Server)

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

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

Тем не менее, SQL-сервер невероятно эффективен с доступом к данным, поэтому вы вряд ли увидите заметное влияние на производительность, за исключением чрезвычайных ситуаций.

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

Ответ 3

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

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

Ответ 4

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

  • Получите то, что вам нужно.
  • избежать второго запроса базы данных в той же таблице для тех же строк
  • используйте индекс в столбцах выбора (ограничитель предложения WHERE)
  • ограничить столбцы, если они вам не нужны, чтобы повысить эффективность/пейджинг памяти сервера данных.

Ответ 5

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