Оптимизация MySQL где много условий where

#mysql #оптимизация

Сайт доска объявлений недвижимости, много фильтров (15-20) по параметрам недвижимости.
Каждый фильтр это одно where условие в select, в итоге если выбрать 4-5 фильтров,
получаем 4-5 условий в селекте. Есть текстовые поля, например улица, район. Подскажите
пожалуйста как правильно такое оптимизировать? Ставить индексы на все поля?
    

Ответы

Ответ 1

Вам нужно посмотреть поглубже - как работают индексы. MySQL выбирает только один
индекс - по которому будет идти выборка. Индекс является доп-колонкой в таблице - не
страшно для чтения если индексов очень много. Правда запись будет помедленнее - но
обычно терпимо. 

Если во where у нас 5 условий на 5 полей - максимальный прирост мы получим при добавлении
индекса на все 5 полей. В принципе если добавить индексы по наиболее частым выборкам
- будет достаточно быстро на объёме до 10 мил. записей. 

Если больше - нужно шардить(резать на кусочки) таблицу, или использовать NoSql решения
- которые ищут очень быстро по любым полям(в том числе не по точному совпадению) на
огромных объёмах. Например мы для аналогичной задачи - доска объявлений использовали
Apache Solr , влвали базу объяв 10 мил, остались довольны.


Ответ 2

20к записей - это мизер, даже без индексов все будет на приемлемой скорости работать. 

В идеале смотрите какие запросы будут чаще всего (из каких фильтров состоять), добавляете
индексы по таким полям, которые дадут максимальное сокращение выборки.


  Например, если фильтр по улице из 20к записей выберет 10, то индексы по другим
полям не нужны. Однако, если в фильтре улица не участвует, понадобится фильтр по другим
полям/комбинациям полей.


Ответ 3

Как вариант — да, можно (в смысле сделать столько индексов, что вся таблица будет
ими покрыта). Но лучше поработать с планировщиком запросов, скорее всего какие-то фильтры
будут более часто используемые плюс, оцените время на запрос-материализацию, скорее
всего, селект не самый ресурсоемкий. Т.е. выборка по одной таблице со множеством условий
- в принципе не самый тяжкий вариант, вот join-ы множества таблиц с подзапросами -
вот это уже поле для оптимизации. А так, о каком числе записей идет речь?