Возникла следующая проблема. Может быть, она уже решалась на данном форуме, но пока не нашел ничего похожего.

Есть таблицы (менять структуру, скорее всего, нельзя,
но обоснованные советы по ее изменению тоже принимаются).
Таблицы достаточно большого объема.
Items - несколько тысяч записей,
Links - сотни тысяч записей, может быть, даже несколько миллионов.

Items (Id INT PRIMARY KEY, Name VARCHAR(64)) - справочник

Links (Id INT, PrevId INT) - ссылки на предков для организации дерева

DLinks (Id INT, PrevId INT) - ссылки на всех предков для ускорения
поиска по дереву

List (StrId, RDate DATE, ItemId, ...
FOREIGN KEY(ItemId) REFERENCES Items ON DELETE CASCADE)
- некая таблица со ссылками на Items

Требуется получить список элементов справочника с количеством записей в List,
ссылащихся на конкретный элемент и всех его потомков в дереве.

Сейчас это делается примерно так:

SELECT Id, PrevId, Name,
(
SELECT COUNT(DISTINCT StrId) FROM List
WHERE
ItemId=Items.Id OR
ItemId IN (SELECT Id FROM DLinks WHERE PrevId=Items.Id)
) AS Summ
FROM Items, Links WHERE Links.Id=Items.Id

Запрос выполняется непростительно долго. План доступа показывает, что
основные затраты (больше половины единиц времени) идут на поиск по DLinks.

Как можно перестроить запрос для существенного ускорения его выполнения?

Виктор

Запрос делается по всему справочнику (запрос, кстати, приведен).
Индексы сделаны именно так, как рекомендовал советчик по индексам, хотя и до того при любой комбинации индексов картина была аналогичная, с точностью до небольшого ускорения или замедления, на общем фоне малозаметного. RUNSTAT и REORG выполнялись регулярно (реорганизовывалась вся БД), эффект опять совершенно незначительный.
В ближайшее время получить план доступа и заполнение таблиц не получится, не доберусь до компьютера с БД.
Могу пока только обрисовать на словах.
Согласно плану доступа (как я его запомнил) основное время тратится на индексскан по индексу таблицы DLinks, включающему оба поля таблицы.
У меня сложилось впечатление, что это все из-за того, что для каждого элемента справочника запрашиваются все его потомки. Ветвистость дерева преизрядная, глубина до 10 доходит.
Потому подумалось, что, может быть, можно построить рекурсивный запрос, обходящий дерево от листьев, и постепенно суммирующий результаты при движении к корню, чтобы постоянно эти листья не ворошить при подсчете в каждом узле. Или я что-то не совсем понимаю?
Если подсчитывать количество только для каждого узла дерева, без учета потомков, то все выполняется шустренько, но потомков надо учитывать полюбому. Уже подумываю о том, чтобы сначала получить сумму по каждому узлу, а потом в таблице-результате уже ручками дерево обойти от листьев до корня, и просуммировать.