Мое почтение!
Уже бесить начинает, либо просто отдохнуть надо! Дело вот в чем: В книге написано что инедксы ставятся на те поля, которые учавсвуют в WHERE условии или в ORDER BY выражении. Есть такая таблица (обрисую образно, на самом деле там таблица гораздо больше и не одна, в запросе учавствует, но этот пример за образец прокатит):

В ней более 50 000 записей. Цифра не значительная, т.к. в постгрисе пашет на ура. Далее... делабюю запрос:

Ноль реакции, EXPLAIN пишет что кеи не юзаются и using filesort, т.е. понятно что перебирает всю таблицу. 
Делаю такой запрос:

`created` - это int - unix_timestamp, ясно что он никогда 0 равняться не будет. Кей начинает быть заюзаным, EXPLAIN в extra показывает using where, т.е. применение индексу пошло. И выполняется моментально (ну как и должно в принципе быть).
Так вот я что-то вообще не пойму эту систему, что надо делать чтоб желаемые индекированые поля были использованы в запросе? Это же не выход, добавлять голимые условия в WHERE !!!
Плз, обяъсните, или ткните носом. 

P.S. В мане читал, и читал из этой темы http://forum.vingrad.ru/index.php?showtopi...st&p=828643 но так нифига и не понял    Блин....

Вы упоминули, что в запросе участвует не одна таблица, это важно. Покажите запрос целиком.
Дело в том, что при джойне нескольких таблиц использовать индекс для сортировки уже сложнее, и он его начинает использовать только(?), если уже использует его же для WHERE (типа а почему бы не применить заодно для ORDER BY) и то не всегда (думаю, зависит от порядка джойна таблиц).

А описанный пример вообще должен в обоих случаях использовать индекс. Если не хочет - можно ему сказать после имени таблицы: FORCE INDEX (имя_индекса). 

Это сообщение отредактировал(а) muzer - 20.9.2006, 01:35

Я тоже так думал...но...


Вот табличка:

Вот собсна сам запрос:

Выполняется где-то секунд 30. Вот результаты EXPLAIN:

Немного не в тему, но все же:
unix_timestamp - это же неотрицательное число. Может тогда следует объявить и само поле не

а как 


И такой вопрос: а чем именно обусловлен выбор int + unix_timestamp. Как я понял (из таблиц) у нас есть категории и продукты с датами создания и модификации. Мне кажется, что здесь гораздо лучше использовать тип TIMESTAMP, который обладает возможностью автоматического обновления своего значения.
http://dev.mysql.com/doc/refman/5.0/en/timestamp-4-1.html

Добавлено @ 11:21 
Пока искал информацию о timestamp'е нашел такую вещь
http://dev.mysql.com/doc/refman/5.0/en/datetime.html
(см. сообщение в комментариях)

Что "но"? Не вижу ни одного опровержения, посмотрите explain'ы к тем запросам, которые у вас в первом примере, увидите сами.

-=Ustas=-, а какой индекс он должен по-вашему использовать?  
Логично ведь, что сначала он выбирает категории, потом все товары из выбранных категорий, затем отбирает только активные, затем сортирует. Можно попробовать его заставить сначала товары отбирать, т.е. STRAIGHT_JOIN после SELECT написать и оставить порядок таблиц такой же. Но я всё равно не уверен, что он начнёт индекс использовать..

Я же написал еще в первом посте результаты EXPLAIN.

Нет, я привык с INT  работать.

Вечером буду пробовать запросы переписывать.

У меня в базах результаты explain'ов для аналогичных вашим запросов получаются логичные, с использованием индекса. Попробуйте написать FORCE INDEX.

Странно, а версия мускула какая?

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

Sardar, для убыстрения сортировки (индекс-то уже отсортирован). MySQL считает, что затратнее при выборке всех строк идти по индексу и seek'ать данные из файла данных, нежели сортировать их налету при выборке. Спорить с разработчиками mysql'я не берусь, но считаю, что зависит от конкретного случая, кол-ва данных и т.д.

-=Ustas=-, я понял в чём разница, я тестировал учитывая условия вашей задачи, а вы просто абстрактный пример, так вот, если LIMIT добавить, в который написать число меньшее раза в два чем кол-во строк в таблице, то индекс подхватывается без FORCE INDEX, иначе нет..  Поведение одинаковое наблюдаю на 4.1.11 и 5.0.22.

Хм... счас попробовал под никсами на 5-ой версии мускула, все нормально и молниеностно выполняет. В EXPLAIN правильные ключи отображает  
Может быть что у меня на винде корявый мускул стоит?

Да, но суть в реальном запросе не меняется обсолютно.

Ну как зачем, для ORDER BY

Вот на винде, версия 4.1.6, 20 тыс записей, запрос:

В EXPLAIN выдает filesort, сама выборка проходит около 30 сек.

Вот. Этот же самый запрос на никсе, версия 5.хх, 20 тыс записей, запрос абсолютно такой же - в EXPLAIN выдает key - created, время 0.00 sec

Что жу это получается, что гонки на винде?

Верно, видно я не выспался...   
Запусти ANALYZE TABLE на таблице, достаточно что бы мускул "увидел" индексы.


Может таблица в кеше была, а под виндой чего сложного делалось параллельно...... да мало ли чего может быть 
Запусти тест раз 50, по идее не должно быть таких разительных различий.

Запустил  :

EXPLAIN выдал тодже самое что и до этого.


Не думаю, сразу после перегрузки пробую.


Тоже мысль такая была, все процессы килял, оставлял только mysqld-nt.

Добавлено @ 23:14 
Наверное переснесу все, по-новой поставлю.

Добавлено @ 23:15 
Посмотрю, что получится 

Мужики, такой вопрос. Может чего-то не догоняю... Следуя мануалу, цитаты:



Это что, противоречие?! И что здесь в этих примерах подразумавается под key и key_part?
Я сделал аналогично этому:


Т.е. :

Делаю запрос:

И он мне говорит что Using filesort. В чем дело, или я что-то не понимаю?
P.S. Не пинайте сильно, и по возможности, если я не прав, объясните в чем я не прав. Или я неправильно себе представляю работу индексов?!