Привет.
Есть таблица INNODB на ~150 тысяч строк.
id(int) / int1 / int2 / varchar / int3
Есть индекс по int1, который
всегда выхватывает не более 25 строк.
Вот такой запрос:
SELECT `id`,`varchar` WHERE `int1`= 355 AND `int3`<36 ORDER BY `int2`
Сижу мучаюсь, как выгоднее:
1. Сделать составной индекс по: int1/int3 , но тогда ORDER BY будет создавать file_sort
2. Сделать составной индекс по: int1/int2 , тогда ORDER BY будет использовать индекс, но int3 будет пересчитываться перебором все 25 строчек, чтоб отыскать int3<36
Что посоветуете?
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
T1grOK
31.01.2014 - 18:26
Опять же зависит от селективности, от преобладающих запросов в приложении и от размера индекса.
Почему не рассматриваешь вариан создания нескольких индексов?
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
T1grOK
Жалко как-то два индекса похожих делать на такое огромное количесвто строк.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Просто думаю...когда строк мало он же итак перебором считает, только что для него мало.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
T1grOK
31.01.2014 - 18:32
Тогда ты не сможешь добиться чего хочешь. У меня на проекте используется 10 индексов как составных так и одиночных, но по другому в моей ситуации не обойтись.
Сделай составной индекс на int1/int2 и на int3/int2 возможно...
Все это нужно смотреть, что и какую нагрузку создает, покрыть индексами все, если есть великое множество вариантов в принципе невозможно.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
T1grOK
Спасибо.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
MiksIr
| Цитата |
| Я бы просто по int1 обошелся индексом, если там и правда 25 строк =) Или int1/int3 + int2 |
Там от 10 до 25 строк, но не более (рабочие дни месяца). Я не знаю механизмов внутри mysql, что там происходит и насколько это все серьезно, вроде строк то совсем нечего, но что если само создание вспомогательно файла при file_sort, пусть он даже совсем небольшой, НО задействует "тяжелые" механизмы, которых и нужно избегать.
Написал, как писатель ...
В любом случае спасибо.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
| Цитата |
| Если все влезает в sort_buffer_size - то даже временных таблиц не создается. А "все" - это набор пар "сортируемое поле - ключ". |
Ммм...понятно. Ну спасибо еше раз!
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Партицирование сделать по одному из полей, и индексы по двум другим.
sergeiss
1.02.2014 - 00:28
| Цитата (ABC @ 31.01.2014 - 18:50) |
| Я не знаю механизмов внутри mysql, что там происходит и насколько это все серьезно... |
Используй EXPLAIN и ты попадёшь в "святая святых", внутрь Мускуля
И он тебе расскажет (сам, добровольно!!!), какие же, на самом деле, индексы он будет использовать. Если вообще будет их использовать. И ты будешь основываться не на умозрительных ощущениях, а на знании фактов.
PS. Ну вот что нашел за 30 секунд гугленья...
http://mattweb.ru/component/k2/item/65-isp...aprosov-k-mysqlМожет быть, есть и лУчшие описания - ищи.
PPS. А заголовок твоей темы "Стоит ли лепить индекс для 5 строк ORDER BY?" вообще не правильный. Потому что у тебя не 5, а ~150 тыщ строк, как ты сам сказал. И он будет в первую очередь для получения этих 5 строк (если индекс "правильный").
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
sergeiss
Все, что ты написал очевидно и понятно без гугла, думаешь я тут на форуме 4 года EXPLAIN не знаю что такое? Я про другие механизмы говорю, намного глубже чем ты видишь.
| Цитата |
| Потому что у тебя не 5, а ~150 тыщ строк, как ты сам сказал |
Читай внимательно пост.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Тема закрыта - сделал все же 2 индекса.
Всем спасибо.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.