- у вас есть стоимость, то наверняка можно посмотреть и план оптимизатора, а так, , Сергей (??), 11:12 , 18-Июн-23 (1)
> Доброго времени суток! > Есть таблица. И два запроса: > 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'а его надо определить... т.е. выполнить сканированием всей таблицы... - Какой другой На момент составления плана выполнени запроса- количество возвра, ыы (?), 10:14 , 19-Июн-23 (2)
> Доброго времени суток! > Есть таблица. И два запроса: > 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? для конкретно двух этих значений?
- У вас теоретический вопрос или практический Самое главное правило при написании, Аноним (3), 11:05 , 19-Июн-23 (3)
У вас теоретический вопрос или практический? >как заставить второй запрос использовать Primary Index? Самое главное правило при написании запросов - не пытаться плохие запросы оптимизировать и заставлять что-то использовать. Пишите запросы, у которых будет оптимальный план. Фактически вам нужен джойн к временной таблице составленной с помощью UNION. Значит надо написать к ней джойн, а не мутить с IN. Чисто в практической плоскости. Если у вас в articles будет за все время жизни сервиса 1000 записей, а в том, из чего вы юнион собираете - и того меньше, вам должно быть все равно, у вас фулл индекс скан или что-то другое. Добавьте памяти под кэш запросов и забудьте навсегда. Напишите запросы попроще, чтобы через пару лет не путаться в их логике. По моему личному опыту - до 2-3 сотен тысяч записей таблицы не тормозят даже если из них выбирают крайне неоптимальным образом.
- Дать index hint пробовали , Tron is Whistling (?), 08:27 , 20-Июн-23 (5)
Дать index hint пробовали?
|