Форум MySQL

id     select_type     table     type     possible_keys     key     key_len     ref     rows     Extra  1    SIMPLE    f    index    NULL    filter5    32    NULL    2    Using index 1    SIMPLE    q    ALL    NULL    NULL    NULL    NULL    6600

Как я понимаю, если индекс форсированно применился к перовой таблица - к которой подлкючается вторая, то во второй таблица индексы уже не применятся?

А можно запрос увидеть? А еще лучше исходные таблицы и индексы?

SELECT * FROM `suppliers_filters` AS f FORCE INDEX(filter5) LEFT JOIN suppliers_queries AS q FORCE INDEX (QueryForFilter) ON IF(f.filter_brand != '', q.car_brand_id = f.filter_brand, q.car_brand_id != '')  AND  IF (f.filter_model != '', q.car_model_id = f.filter_model, q.car_model_id != '')  AND q.Year BETWEEN IF(f.filter_start_year = 0, 1901, f.filter_start_year) AND IF(f.filter_end_year = 0, 2155, f.filter_end_year)

CREATE TABLE IF NOT EXISTS `suppliers_filters` (   `filterID` int(11) NOT NULL auto_increment,   `supplierID` int(11) NOT NULL COMMENT '__',   `filter_brand` int(5) NOT NULL COMMENT '__',   `filter_model` varchar(5) collate utf8_unicode_ci default NULL COMMENT '__',   `filter_start_year` year(4) NOT NULL COMMENT '___',   `filter_end_year` year(4) NOT NULL COMMENT '__',   PRIMARY KEY  (`filterID`),   KEY `supplierID` (`supplierID`),   KEY `filter5` (`filterID`,`supplierID`,`filter_brand`,`filter_model`,`filter_start_year`,`filter_end_year`) ) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=3 ;

CREATE TABLE IF NOT EXISTS `suppliers_queries` (   `QueryID` int(11) NOT NULL auto_increment,   `OrderID` int(11) NOT NULL,   `AddDate` datetime NOT NULL,   `Archive` int(1) NOT NULL,   `ferio_name` varchar(100) collate utf8_unicode_ci NOT NULL,   `OrderCity` varchar(100) collate utf8_unicode_ci NOT NULL,   `Mark` varchar(50) collate utf8_unicode_ci NOT NULL,   `Model` varchar(50) collate utf8_unicode_ci NOT NULL,   `Vin` varchar(50) collate utf8_unicode_ci NOT NULL,   `Year` int(11) NOT NULL,   `Power` int(11) NOT NULL,   `Basetype` varchar(20) collate utf8_unicode_ci NOT NULL,   `Geartype` varchar(20) collate utf8_unicode_ci NOT NULL,   `Fueltype` varchar(20) collate utf8_unicode_ci NOT NULL,   `Capacity` int(11) NOT NULL,   ` Gearbox` varchar(20) collate utf8_unicode_ci NOT NULL,   `Region` varchar(50) collate utf8_unicode_ci NOT NULL,   ` body_code` varchar(20) collate utf8_unicode_ci NOT NULL,   `engine_code` varchar(20) collate utf8_unicode_ci NOT NULL,   `PartID` varchar(256) collate utf8_unicode_ci NOT NULL,   `Partname` varchar(1024) collate utf8_unicode_ci NOT NULL,   `car_brand_id` int(10) NOT NULL,   `car_model_id` int(10) NOT NULL,   PRIMARY KEY  (`QueryID`),   KEY `OrderID` (`OrderID`),   KEY `AddDate` (`AddDate`),   KEY `Archive` (`QueryID`,`Archive`),   KEY `QueryForFilter` (`OrderID`,`Year`,`car_brand_id`,`car_model_id`) ) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=224401 ;

В такой форме индекс может использоваться только один, при помощи FORCE вы можете заставить использовать альтернативный индекс. Однако, заставить MySQL использовать два индекса в одном запросе - невозможно, она этого не умеет.

каков совет тогда? проставить во стоврой таблице индексы к каждому полю по отдельности?

Прогнать запрос с одним и с другим индексом, посмотреть где лучше type и меньше rows. Сделать предположение относительно роста rows, т.е. что будет быстрее увеличиваться в размерах filter5 или QueryForFilter и остановиться на том, который короче.

вот мне интересно как избегают JOINов для огромных таблиц. В одну превратить никак

Вы же можете не огромные таблицы в JOIN помещать, а небольшие выборки из этих огромных таблиц (индексы не сработают для JOIN, но сработают для выборок). Ухищрений много всяких, вплоть до кэш-таблиц, которые заполняются регулярно cron-заданиями.

Доброго дня! Вот хотел создать новую тему по данному вопросу, но решил просто присоединиться к обсуждению.... Значит, как я понял, спрашивать почему при JOIN работает только один индекс смысла нет, ответ найден - "однако, заставить MySQL использовать два индекса в одном запросе - невозможно, она этого не умеет"

Но почитав обсуждение у меня возник новый вопрос.... Прогнать запрос с одним и с другим индексом, посмотреть где лучше type и меньше rows Что значит лучше TYPE? т..е к чему надо стремиться, к какому TYPE?

И КСТАТИ.......... От чего зависит выбор, много одностолбцовых индексов или один индекс на несколько столбцов?

От чего зависит выбор, много одностолбцовых индексов или один индекс на несколько столбцов?
от условия выборки, больше ни от чего индексы не зависят

Ну это понятно, однако хотелось бы более подробно... ну вот напрмиер.... есть 2 поля... filed1 и field 2


select что-то from table where field1=что-то and field2=что-то

лучше add index xfields(field1, field2) или add index xfield1(field1) и add index xfield2(field2)

можно какой-нить простенький пример, когда лучше одно, а когда другое?

>Что значит лучше TYPE? т..е к чему надо стремиться, к какому TYPE?
Есть такой оператор EXPLODE. type - это название одного из столбцов его отчета.

>И КСТАТИ.......... От чего зависит выбор, много одностолбцовых индексов или один индекс на
>несколько столбцов?
Это зависит от запроса, который вы оптимизируете, если он использует несколько столбцов - для него нужно многостолбцовый индекс.

PS Под новые вопросы лучше заводить новые темы, более того, лучше под каждый вопрос заводить отдельную тему - и обсуждение качественнее получается и ссылаться потом на такие обсуждения проще. Они получаются небольшими и емкими - читающему не приходиться перелопачивать горы информации, а то иногда на других темах посылают поискать информацию в теме из 5000 сообщений - проще застрелиться. У нас принято, чтобы в теме было как можно меньше сообщений, идеально - два: вопрос и ответ :)))

Замечание учел, в следующий раз - 1 вопрос=1 тема
Но раз уж мы тут, тогда я непонял насчет explode.... наврено имелось ввиду explain, им то я пользуюсь, просто чем один type лучше другого...... или я просто неправильно понял всю фразу((((( или имелось в виду выбрать тот TYPE при котором будет меньше rows?

>тогда я непонял насчет explode.... наврено имелось ввиду explain
Да, конечно, у меня беда с этими двумя английскими словами :)))

>или имелось в виду выбрать тот TYPE при котором будет меньше rows?
Нет имеется в виду что сначала следует ориентироваться на лучший type, а потом уже на меньший rows. Просто если type вам говорит, что будет использоваться индекс - лучше предпочесть его, чем случай, когда будет перелопачена вся таблица. Как правило, файл индекса сильно меньше файла данных, в индексах нет переменных строк и индексы упорядочены заранее. Поэтому работа с таким файлом идет много быстрее. Понятно, что существуют исключения: бывают очень здоровые файлы индексов, есть FULLTEXT к которому это все не относится... но факт остается фактом, индексы - это сильно быстрее перебора данных из таблицы.