Hello, Sasha!
sasha wrote:
У меня тут есть пример, в котором оптимизатор не использует индекс для
злополучной вьюхи:
FROM "RssFeedItems" I
LEFT JOIN (SELECT MIN(RDB$DB_KEY) AS ENCLOSURE_KEY, "FeedItemId" FROM
"RssFeedItemEnclosures" GROUP BY "FeedItemId")
AS EN ON EN."FeedItemId" = I."Id"
LEFT JOIN "RssFeedItemEnclosures" E ON E.RDB$DB_KEY = EN.ENCLOSURE_KEY;
план I NATURAL вполне нормален.
2) Тормозящий запрос (по таблице RssFeedItems, которая внутри вьюхи,
идёт натуральный скан):
FROM "UndeletableRssFeedItems" RFI
JOIN "RssCacheElements" RCE ON RFI."FeedId" = RCE."RssFeedId"
WHERE RCE."FeedDefinitionId" = 1540
я в упор не вижу, где накладывается доп. условие на запрос во view,
чтобы по rssfeeditems был хоть какой то отбор по другим столбцам,
по которым есть индексы.
3) Запрос с таблицей вместо представления быстрый:
быстрый, потому что JOIN, а не LEFT JOIN, и кроме того,
запрос не соответствует суммарному view+запрос.
4) Простой запрос, на котором для вьюхи оптимизатор использует индекс по
"FeedId"
WHERE RFI."FeedId" = 743
!!! ну наконец-то.
FROM "UndeletableRssFeedItems" RFI
RIGHT JOIN "RssCacheElements" RCE ON RFI."FeedId" = RCE."RssFeedId"
WHERE RCE."FeedDefinitionId" = 1540 AND RFI."Id" IS NOT NULL
при чем тут right join? в любом случае, взялся индекс по rfi.feedId.
Если интересно, могу выслать тестовую базу.
не надо. посмотри лучше еще раз joins.htm и dataaccesspaths.htm.
--
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
