Доброго времени суток!

Есть таблица. И два запроса:

select id FROM articles WHERE id in ( 45, 46);
select id FROM articles WHERE id IN(SELECT 45 union SELECT 56);

В первом случае стоимость (cost) 1.82. В таблице articles используется Primary Index и идет Index Range Scan .

Во втором случае стоимость (cost) 2003.22. В таблице используется другой индекс и идет Full Index Scan.

Откуда такая разница и как заставить второй запрос использовать Primary Index?

• Почему при использовании оператор IN пропадает индекс?,Сергей, 11:12 , 18-Июн-23
• Почему при использовании оператор IN пропадает индекс?,ыы, 10:14 , 19-Июн-23
• Почему при использовании оператор IN пропадает индекс?,Аноним, 11:05 , 19-Июн-23
  • Почему при использовании оператор IN пропадает индекс?,Дмитрий, 11:11 , 19-Июн-23
• Почему при использовании оператор IN пропадает индекс?,Tron is Whistling, 08:27 , 20-Июн-23

> Доброго времени суток!
> Есть таблица. И два запроса:
> select id FROM articles WHERE id in ( 45, 46);
> select id FROM articles WHERE id IN(SELECT 45 union SELECT 56);
> В первом случае стоимость (cost) 1.82. В таблице articles используется Primary Index
> и идет Index Range Scan .
> Во втором случае стоимость (cost) 2003.22. В таблице используется другой индекс и
> идет Full Index Scan.
> Откуда такая разница и как заставить второй запрос использовать Primary Index?

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

> Доброго времени суток!
> Есть таблица. И два запроса:
> select id FROM articles WHERE id in ( 45, 46);
> select id FROM articles WHERE id IN(SELECT 45 union SELECT 56);
> В первом случае стоимость (cost) 1.82. В таблице articles используется Primary Index
> и идет Index Range Scan .
> Во втором случае стоимость (cost) 2003.22. В таблице используется другой индекс и
> идет Full Index Scan.

Какой "другой" ?

> Откуда такая разница

На момент составления плана выполнени запроса- количество возвращаемых подзапросом значений неизвестно. И оптимизатор берет необходимые параметры "с потолка". Проведя достаточное колдичество экспериментов с разными данными - вы поймете что статистически - он прав.

> и как заставить второй запрос использовать Primary Index?

для конкретно двух этих значений?

У вас теоретический вопрос или практический?

>как заставить второй запрос использовать Primary Index?

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

Чисто в практической плоскости. Если у вас в articles будет за все время жизни сервиса 1000 записей, а в том, из чего вы юнион собираете - и того меньше, вам должно быть все равно, у вас фулл индекс скан или что-то другое. Добавьте памяти под кэш запросов и забудьте навсегда. Напишите запросы попроще, чтобы через пару лет не путаться в их логике. По моему личному опыту - до 2-3 сотен тысяч записей таблицы не тормозят даже если из них выбирают крайне неоптимальным образом.

> У вас теоретический вопрос или практический?

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

Дать index hint пробовали?