https://www.opennet.ru/openforum/vsluhforumID8/8349.html Доброго времени суток!<br><br>Есть таблица. И два запроса:<br><br>select id FROM articles WHERE id in ( 45, 46);<br>select id FROM articles WHERE id IN(SELECT 45 union SELECT 56);<br><br>В первом случае стоимость (cost) 1.82. В таблице articles используется Primary Index и идет Index Range Scan .<br><br>Во втором случае стоимость (cost) 2003.22. В таблице используется другой индекс и идет Full Index Scan.<br><br>Откуда такая разница и как заставить второй запрос использовать Primary Index?<br><br> https://www.opennet.ru/openforum/vsluhforumID8/8349.html#5 Tue, 20 Jun 2023 05:27:21 GMT Дать index hint пробовали?<br> https://www.opennet.ru/openforum/vsluhforumID8/8349.html#4 Mon, 19 Jun 2023 08:11:50 GMT &gt; У вас теоретический вопрос или практический?<br><br>Практический. Сам запрос достаточно сложный, чтобы его приводить, я выдернул упрощенный образец от туда.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID8/8349.html#3 Mon, 19 Jun 2023 08:05:17 GMT У вас теоретический вопрос или практический? <br><br>&gt;как заставить второй запрос использовать Primary Index?<br><br>Самое главное правило при написании запросов - не пытаться плохие запросы оптимизировать и заставлять что-то использовать. Пишите запросы, у которых будет оптимальный план.<br>Фактически вам нужен джойн к временной таблице составленной с помощью UNION. Значит надо написать к ней джойн, а не мутить с IN. <br><br>Чисто в практической плоскости. Если у вас в articles будет за все время жизни сервиса 1000 записей, а в том, из чего вы юнион собираете - и того меньше, вам должно быть все равно, у вас фулл индекс скан или что-то другое. Добавьте памяти под кэш запросов и забудьте навсегда. Напишите запросы попроще, чтобы через пару лет не путаться в их логике. По моему личному опыту - до 2-3 сотен тысяч записей таблицы не тормозят даже если из них выбирают крайне неоптимальным образом.<br> https://www.opennet.ru/openforum/vsluhforumID8/8349.html#2 Mon, 19 Jun 2023 07:14:13 GMT &gt; Доброго времени суток!<br>&gt; Есть таблица. И два запроса: <br>&gt; select id FROM articles WHERE id in ( 45, 46); <br>&gt; select id FROM articles WHERE id IN(SELECT 45 union SELECT 56); <br>&gt; В первом случае стоимость (cost) 1.82. В таблице articles используется Primary Index <br>&gt; и идет Index Range Scan .<br>&gt; Во втором случае стоимость (cost) 2003.22. В таблице используется другой индекс и <br>&gt; идет Full Index Scan.<br><br>Какой "другой" ?<br><br>&gt; Откуда такая разница <br><br>На момент составления плана выполнени запроса- количество возвращаемых подзапросом значений неизвестно. И оптимизатор берет необходимые параметры "с потолка". Проведя достаточное колдичество экспериментов с разными данными - вы поймете что статистически - он прав.<br><br>&gt; и как заставить второй запрос использовать Primary Index?<br><br>для конкретно двух этих значений?<br> https://www.opennet.ru/openforum/vsluhforumID8/8349.html#1 Sun, 18 Jun 2023 08:12:17 GMT &gt; Доброго времени суток!<br>&gt; Есть таблица. И два запроса: <br>&gt; select id FROM articles WHERE id in ( 45, 46); <br>&gt; select id FROM articles WHERE id IN(SELECT 45 union SELECT 56); <br>&gt; В первом случае стоимость (cost) 1.82. В таблице articles используется Primary Index <br>&gt; и идет Index Range Scan .<br>&gt; Во втором случае стоимость (cost) 2003.22. В таблице используется другой индекс и <br>&gt; идет Full Index Scan.<br>&gt; Откуда такая разница и как заставить второй запрос использовать Primary Index?<br><br>у вас есть стоимость, то наверняка можно посмотреть и план оптимизатора, а так, во в втором случае имеем запрос и оптимизатор считает его неопределенным, посему на каждую строчку "глобального" select'а его надо определить... т.е. выполнить сканированием всей таблицы...<br><br>