Производительность возврата целых таблиц, содержащих текст блога, в отличие от выбора определенных столбцов

Question

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

Если бы я только запросил всю таблицу, я мог бы использовать свой сопоставленный объект ORM, но я бы загружал весь текст блога.

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

Насколько сильно снижается производительность, если я запрашиваю целые строки?Стоит ли выбирать именно то, что мне нужно?

Answer 1

Ответ "это зависит".

На выбор столбцов влияют две вещи:

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

2. Размер столбцов.По сути, посчитайте, насколько велик размер всей строки по сравнению с размером только столбцов в меньшем запросе.

   • Если отношение является значительным (например, полная строка в 3 раза больше), то вы можете получить значительную экономию затрат на ввод-вывод (для поиска) и сеть (для передачи).

   • Если коэффициент больше похож на 10% -ную выгоду, это может не стоить того, чтобы повысить производительность БД.

Answer 2

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

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

Answer 3

, так как вы указываете, что это для 10 записей, ответ меняется с «Это зависит» на « Не тратьте ни секунды, беспокоясь об этом ».

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

Таким образом, в этом случае вы можете освободить свой ORM, чтобы получать эти записи как можно менее эффективно. Если ваша ситуация изменится, и вам вдруг понадобится больше, скажем, 1000 записей одновременно, тогда вы можете вернуться, и мы посмеемся над тем, что вы не указали столбцы, но на данный момент вы получаете бесплатный пропуск.

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