Как оптимизировать запрос?

Question

[Dark_Dante]

Здравствуйте.
Подскажите пожалуйста по такой ситуации. Есть вот такой запрос:

SELECT id, desctipription, IF (
EXISTS(
SELECT * FROM tree AS tree2 
WHERE tree2.parent_id=tree.id
)
1,0
) AS descendants
 FROM tree 
WHERE tree.parent_id=<ид_родителя> AND EXISTS (
SELECT * FROM articles WHERE tree.id=articles.tree_id LIMIT 1);

Грубо говоря, запрос выбирает все дочерние ветки для данного id, их идентификатор, имя, признак, есть ли у нее потомки, если этой ветке принадлежит хоть одна запись в таблице articles. Все это дергается рекурсией и строится красивое дерево категорий. Но, есть одно "но". В таблице articles примерно 147 миллионов записей. Хоть индексы и стоят по полям, запрос выполняется долго, примерно пару секунд. А так как все это дело делается еще и в рекурсивном вызове, то время построения дерева может доходить до минуты а то и нескольких минут.
При помощи EXPLAIN видно, что тормоза вызывает именно подзапрос проверки наличия хоть одного артикула, относящегося к этой ветке.
Подскажите пожалуйста, как ускорить данный запрос?
P.S. Все таблицы в InnoDB

Answer 1

[Rsa97]

Перейти на NestedSet, там признак листа left = right-1

Comments

[Dark_Dante]

Это все конечно хорошо, но дело то не в этом. На самой структуре дерева все хорошо. Дело в выборке из 147 миллионов записей.
Можно вообще упростить вопрос до: "Как сделать быструю выборку MySQL на больших объемах данных?".

[Rsa97]

Dark_Dante: Так NestedSet как раз позволяет быстро выбирать полное поддерево, сразу все уровни.

[Николай Конюхов]

Dark_Dante: дело как раз-таки в этом.

[Dark_Dante]

Николай Конюхов: Ладно, окей. Предположим, с деревом вопрос решили. Теперь надо выбрать все товары, принадлежащие данной ветке. Та же самая байда - на таком объеме селект по tree_id занимает несколько секунд драгоценного времени. Как ускорить селект на 147 миллионах записей?

[Rsa97]

Dark_Dante: В NestedSet запрос

WHERE `left` > :parentLeft AND `right` < :parentRight

выбирает всех потомков данного узла и по нему должен работать составной индекс.

Кстати, количество товаров в группе можно хранить прямо в дереве и обновлять триггером при изменении таблицы articles, это тоже ускорит выборку.