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

Question

У меня есть таблица, которая может содержать от 10 000 до 100 000 строк, и мне нужны переменные наборы, содержащие до 1 или 2 тысяч строк, но часто достаточно меньше. Я хочу, чтобы эти запросы выполнялись как можно быстрее, и я хотел бы знать, какой подход, как правило, умнее:

1. Всегда запрашивайте именно те строки, которые мне нужны, с предложением WHERE, которое постоянно отличается.
2. Загрузить всю таблицу в кэш в памяти внутри моего приложения и выполнить там поиск, регулярно синхронизируя кэш
3. Всегда запрашивать всю таблицу (без предложения WHERE), разрешить SQL-серверу обрабатывать кэш (это всегда один и тот же запрос, поэтому он может кэшировать результат) и фильтровать выходные данные при необходимости

Я бы хотел быть агностиком конкретного движка БД.

Answer 1

с 10K до 100K строк, номер 1 для меня явный победитель. Если бы он был <1K, я бы сказал, сохраняйте его в кэше в приложении, но с таким количеством строк, пусть БД делает то, для чего она была предназначена. При правильных индексах лучшим выбором будет номер 1. </p>

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Для # 3 вы просто говорите «фильтруйте вывод по мере необходимости», не говоря, где этот фильтр был выполнен. Если он находится в коде приложения, как в # 2, чем, как и в # 2, у вас та же проблема как № 2.

Базы данных были созданы специально для решения этой конкретной проблемы. Они очень хороши в этом. Пусть они это сделают.

Answer 5

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

Answer 6

Причина only для использования чего-либо, кроме варианта 1, заключается в том, что само предложение WHERE огромно (т. Е. Если ваше предложение WHERE идентифицирует каждую строку отдельно, например, WHERE id = 3 or id = 4 or id = 32 or ...).

Answer 7

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

Обратите внимание, что я сказал «позволить себе делать», а не просто «делать». Возможно, вам удастся сделать это лучше, но вам платят (предположительно) за предоставление функциональности, а не за кеширование.

Задайте себе вопрос ... Помогает ли вам тратить время на написание кода управления кешем для выполнения ваших требований?

Answer 8

Что-нибудь еще меняет ваши данные? Идея о том, чтобы механизм SQL оптимально нарезал кубиками, является хорошим. Но было бы удивительно, если бы вы работали с базой данных и не имели возможности «кого-то еще» изменять данные. Если изменения могут быть внесены в другом месте, вам, безусловно, нужно часто повторять запросы.

Answer 9

если вы сделаете это:

SELECT * FROM users;

mysql должен выполнить два запроса: один - узнать поля в таблице, а другой - вернуть запрашиваемые вами данные.

делает

SELECT id, email, password FROM users;

mysql достигает только данных, поскольку поля являются явными.

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