#mysql
#mysql
Вопрос:
Существуют ли какие-либо масштабируемые способы выбора тысяч строк с использованием mysql или чего-то подобного?
Например.
SELECT * FROM awesomeTable WHERE id IN (1,2,3,4......100000)
Возможно ли это или я просто мечтаю? Схема InnoDB, может быть изменена, если другая предоставит более масштабируемое решение.
Для справки я получаю результаты поиска по набору идентификаторов, возвращаемых из Solr. Я хотел бы использовать mysql для окончательного извлечения, поскольку это значительно упростило бы сортировку и окончательную фильтрацию этих результатов (я не буду вдаваться в подробности почему).
Редактировать:
Запрос может использовать предложение LIMIT, если в IN все еще содержатся все 100000 идентификаторов
Например.
SELECT * FROM awesomeTable WHERE id IN (1,2,3,4......100000) LIMIT 10;
Комментарии:
1. лучше использовать сортировку solr, если вы хотите добиться производительности.
2. Вам действительно нужно извлекать фактическое содержимое всех тысяч строк? Разве вы не можете выполнить свой алгоритм разбивки на страницы, а затем начать выборку для каждой страницы?
3. @cherouvim ему нужно выполнить сортировку. вот почему он выбирает все записи, которые я предполагаю.
4. @sathis точно. Сортировка в этом случае основана на другой таблице. Консолидация всего этого в solr — это не то, чем я хотел бы заняться прямо сейчас, поскольку это может занять значительное время
5. Не уверен, что это действительно может быть более эффективным. Подумайте об этом. Вы должны перенести все идентификаторы в mysql (простой список, разделенный запятыми, довольно компактный), и mysql должен обработать список. Возможно, подготовленные инструкции помогли бы (правильные, а не эмулируемые программным обеспечением), поскольку идентификаторы могли бы быть отправлены в виде двоичного списка ( что сэкономило mysql немного времени на разбор текста), но в конце дня все равно считают, что вы делаете это неправильно. Если вы не можете выполнить окончательную сортировку и фильтрацию в solr, перейдите на что-нибудь другое!
Ответ №1:
Я, который был мной, и не очень хорошо знал вашу структуру, вы должны попробовать вставить эти идентификаторы во временную таблицу и использовать эту таблицу с простым внутренним соединением. Это может оказаться таким же быстрым, как это В.
Комментарии:
1. Я думал об этом, но не будут ли накладные расходы на запись при вызове INSERT для потенциально сотен тысяч идентификаторов перевешивать любые преимущества, полученные от внутреннего соединения?
2. Что еще более важно, обычно существует верхний предел размера (в символах), который может получить один SQL-запрос. Длинный
IN()список — хороший способ достичь этого предела. Использование временной таблицы позволяет избежать этого. Кроме того, решение с использованием временных таблиц может быть намного более эффективным, если вам нужно использовать список более одного раза.3. Что, вероятно, имело бы место, если это поиск, поскольку вы можете захотеть разбить результат на страницы.
4. Я попробовал это на относительно большой таблице, и хотя для завершения требуется около одной минуты, ВНУТРЕННЕЕ СОЕДИНЕНИЕ завершается менее чем за 100 мс.
Ответ №2:
Я столкнулся с тем же вопросом при вставке в таблицы mysql. Возможный размер запроса зависит от вашей конфигурации mysql.
Мой подход состоял в том, чтобы разделить большую коллекцию идентификаторов на несколько частей.
Использование Ruby на Rails:
all_ids.each_slice(10000) do |ids_part|
query = "INSERT INTO ..."
end
Возможно, это также могло бы быть решением для выбора строк по идентификаторам.