Mysql умеет сам делать merge index, но быстрее ли это?

Question

[egoranisimov]

ALTER TABLE `some_db`.`some_table` ADD INDEX `some_index` (`field1` , `field2`, `field3`, `field4`)
или
ALTER TABLE `some_db`.`some_table` ADD INDEX (`field1`)
ALTER TABLE `some_db`.`some_table` ADD INDEX (`field2`)
ALTER TABLE `some_db`.`some_table` ADD INDEX (`field3`)
ALTER TABLE `some_db`.`some_table` ADD INDEX (`field4`)

Что должно быть быстрее? Тесты говорят, что выигрывает первый вариант (запрос был с указанием, что использовать надо именно этот общий индекс). Хотелось бы узнать, как поступать в таких случаях.

Answer 1

[Сергей Протько]

Что быстрее, сканирование одного индекса или манипуляции с четырьмя индексами с целью получить пересечение/объеденение (в зависимости от логики запроса) результатов сканирования?

Comments

[egoranisimov]

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

[Пума Тайланд]

egoranisimov: не умеет он делать манипуляции сразу с четырьмя индексами в этом ответе три писали искусственный интеллект mysql , что не есть правда.

Answer 2

[Пума Тайланд]

Мускул не умеет нормально использовать несколько индексов, собственно для этого и нужны составные индексы.
Легко проверить это с помощью explain

Comments

[Сергей Протько]

справедливости ради, с версии 5.6 умеет, но это не будет так же эффективно как составные индексы. Тут вопрос в количестве данных и индексов, насколько я понимаю merge index-ы стоит юзать когда у нас стоит выбор, либо сделать несколько составных индексов на все случаи жизни или же сделать отдельные индексы по полям которые учавствуют в условиях. Ну мол, может возникнуть ситуация при которой для 4-х полей нам нужно либо 16 составных индексов (крайний случай) либо 4 обычный. И если данных много то второй вариант как-то приятнее. Ну или опять же как первоначальный вариант когда логика поиска еще не проработана полностью.