Кешируются ли подзапросы MySQL при использовании в предложении WHERE?

Question

Кешируются ли подзапросы MySQL при использовании в предложении WHERE?

12

В следующем запросе:

SELECT column_a, column_b FROM table_a WHERE
    column_b IN (SELECT b_id FROM table_b)

Является ли подзапрос SELECT b_id FROM table_b кэшированным синтаксическим анализатором SQL, или было бы быстрее выполнить запрос заранее, сохранить его как переменную (например, в PHP), а затем передать эти значения в виде строки CSV?

например.

SELECT column_a, column_b FROM table_a WHERE
    column_b IN (1,3,4,6,8,10,16,18)

Julian H. Lam 08 авг. 2012, в 18:47

Источник

0

Использование IN с подзапросом - ужасная идея. Вам лучше получить желаемые результаты с помощью объединения, поскольку запрос по сути является равноправным объединением. SELECT column_a, column_b FROM table_a JOIN table_b ON column_b = b_id
Tim Seguine 21 янв. 2014, в 14:56
0

@TimSeguine: Почему это ужасная идея? Если table_b является N: отношение таблица M, один будет получить несколько строк из table_a если JOIN используется. Это может быть нежелательным.
naitsirch 30 май 2016, в 13:46
1

@naitsirch Это плохая идея, потому что MySQL плохо поддерживает зависимые подзапросы. Если вы можете каким-либо образом избежать их, вы, вероятно, должны. Правильно выбранный GROUP BY устраняет посторонние результаты в большинстве случаев.
Tim Seguine 30 май 2016, в 15:13
0

У нас нет зависимого (я думаю, вы имели в виду коррелированные ) подзапроса в вопросе (см. Здесь для объяснения коррелированных подзапросов). Насколько я вижу, этот запрос должен быть таким же быстродействующим, как JOIN , потому что он должен быть выполнен только один раз.
naitsirch 30 май 2016, в 15:49
0

@naitsirch вы правы, это не связано. Тем не менее, старые версии MySQL иногда очень плохо оптимизировали подзапросы IN (оценивая весь подзапрос для каждой строки внешней таблицы, в данном случае a). И когда я говорю старый, я имею в виду до 5,5. Переписывание с JOIN , когда это было возможно, обычно было очень хорошей идеей.
ypercubeᵀᴹ 11 нояб. 2016, в 11:58

Показать ещё 3 комментария

Теги:

mysql

database

sql-server

optimization

sql

1 ответ

Ещё вопросы

Использование IN с подзапросом - ужасная идея. Вам лучше получить желаемые результаты с помощью объединения, поскольку запрос по сути является равноправным объединением. SELECT column_a, column_b FROM table_a JOIN table_b ON column_b = b_id
@TimSeguine: Почему это ужасная идея? Если table_b является N: отношение таблица M, один будет получить несколько строк из table_a если JOIN используется. Это может быть нежелательным.
@naitsirch Это плохая идея, потому что MySQL плохо поддерживает зависимые подзапросы. Если вы можете каким-либо образом избежать их, вы, вероятно, должны. Правильно выбранный GROUP BY устраняет посторонние результаты в большинстве случаев.
У нас нет зависимого (я думаю, вы имели в виду коррелированные ) подзапроса в вопросе (см. Здесь для объяснения коррелированных подзапросов). Насколько я вижу, этот запрос должен быть таким же быстродействующим, как JOIN , потому что он должен быть выполнен только один раз.
@naitsirch вы правы, это не связано. Тем не менее, старые версии MySQL иногда очень плохо оптимизировали подзапросы IN (оценивая весь подзапрос для каждой строки внешней таблицы, в данном случае a). И когда я говорю старый, я имею в виду до 5,5. Переписывание с JOIN , когда это было возможно, обычно было очень хорошей идеей.

Daniel Li · Accepted Answer · 2012-08-08T16-00-00.000Z

Посмотрите на использование EXPLAIN EXTENDED, чтобы полностью проиллюстрировать эффекты, оказанные в подзапросе.

Например:

EXPLAIN EXTENDED
SELECT column_a, column_b FROM table_a WHERE
    column_b IN (SELECT b_id FROM table_b)

Если они не дают желаемых результатов кэширования, вы можете быть заинтересованы в их хранении в памяти (memcache, redis), в файле (используя библиотеки файлов PHP) или в отдельном кэше SQL.

Это самый неправильный ответ, который я видел сегодня.
@ypercubeᵀᴹ ypercubeᵀᴹ и всем, кто проголосовал против, можете ли вы объяснить или предоставить альтернативные ответы?