Форум MySQL

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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