не используется индекс при джоине таблиц

[ReMaRk]

не используется индекс при джоине таблиц

Сабж!
Таблица (вложенные множества):

CREATE TABLE categories (
cat_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
cat_left INT UNSIGNED NOT NULL,
cat_right INT UNSIGNED NOT NULL,
cat_level INT UNSIGNED NOT NULL,
PRIMARY KEY(cat_id)
KEY (cat_left, cat_right, cat_level)
);

при запросе вида:

EXPLAIN
SELECT STRAIGHT_JOIN
    *
FROM
    categories AS c,
    categories AS b
WHERE
    c.cat_id = 1 AND
    b.cat_left BETWEEN c.cat_left AND c.cat_right

почему-то не использует индекс, хотя должен был и сканит всю таблицу, вместо скана индексов... При присутствии скажем 3(трех!!!) записей использует, а если записей больше 1000, то ни в какую!!! что делать??

 

[ForJest]

А выборка результирующая покрывает меньше чем треть записей?

 

[ReMaRk]

Нет, почти все записи в данном запросе... А как это влияет (где конкретно в мане можно об этом почитать)? И как можно максимально оптимизировать время выполнения запроса? Выборка занимает 1.8 секунды - это очень много!!! (выводится карта сайта)

 

[alexhemp]

Попробуй индекс сделать по двум полям cat_left и cat_right

 

[ForJest]

http://dev.mysql.com/doc/mysql/ru/query-speed.html

 

[Bambuk]

Автор оригинала: alexhemp
Попробуй индекс сделать по двум полям cat_left и cat_right

В таблице уже присутствует индекс по этим полям, так что смысла в этом нет. Может иметь смысл сменить порядок полей в индексе.

 

[slach]

что делать
менять WHERE на INNER JOIN
и принудительно указывать индекс через USING

 

[ForJest]

slach

Нет, почти все записи в данном запросе

какой толк от индекса, если идёт фулл-скан?

 

[ReMaRk]

через USING не получится, потому как там указывается только список полей, по которым надо склеивать записи, только через ON (some condition), но это по сути тоже самое что и в WHERE

-~{}~ 15.06.05 13:24:

Автор оригинала: ForJest

какой толк от индекса, если идёт фулл-скан?

Не всегда идет фулскан, в данной вариации запроса, который я привел - да, но есть ситуации, когда выводится кусок дерева, где возможна ситуация (я надеюсь) использования индексов. Ну а вообще - я тоже задаюсь вопросом толковости индекса!
Я не понимаю почему просмотр таблицы все же может оказаться быстрее просмотра дерева индексов в MySQL!

 

[ForJest]

ReMaRk
Я так предполагаю, что:
Потому что таблица это последовательная структура, а дерево - древовидная . Просматривая таблицу не нужно ходить по указателям. А т.к. дерево индекса должно быть считано практически всё, то операции с последовательной структурой должны быть быстрее.

 

[ReMaRk]

ForJest
А если таблица напичкана объемными полями с данными, то шерстить по ним будет быстрее нежели пройтись по указателям в дереве, где хранится только одно индексное поле???

 

[ForJest]

ReMaRk
Поспрашивай у оптимизатора MySQL, а? Я тут при чём - я же не хожу по таблице

 

[ReMaRk]

ForJest
=), на самом деле в твоем предыдущем посте есть логика - ведь в конечном итоге целью является выборка данных и оптимизатор решает, что если записей выбирается много, то не имеет смысла сначала шерстить по дереву индексов, а потом по таблице ищя соответствующие записи - имеет смысл сразу просмотреть всю таблицу с записями.