[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Обратный индекс
Страницы: 1, 2
GET
Привет.

Знаю, что в mysql нет такого понятия, но чисто логически, нормально ли так делать:

Есть составной индекс:
INT1/INT2/INT3, таблица INNER джойнится по INT3 (по которому тоже есть индекс),
но поиск по ней делается все таки через WHERE INT1=N1 AND INT2=N2 AND INT3=N3 в этом порядке, т.к. INT 1 очень селективен.

Иногда, mysql может выбирать в качестве индекса именно INT3, по которому происходит соединение, тогда WHERE INT1=N1 AND INT2=N2 ей придется искать перебором.

Стоит ли вместо одиночного INT3 сделать составной (обратный) индекс: INT3/INT2/INT1? (т.е. будет 2 составных индекса)

Не будет ли это избыточным?

Или я уже глупость пишу...

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
GET
Вопрос снят, оставил один обратный: INT3/INT2/INT1 по которому идет соединение

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Игорь_Vasinsky
чем руководствовался? тестировал?

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
GET
Игорь_Vasinsky
Цитата
чем руководствовался? тестировал?


на бумажке нарисовал варианты smile.gif

вариант хорош, когда N3 последний столбец константа, когда это интервал ...ну апидется заходить во второй столбец, но зато таблица меньше и в моем случае это не должно быть особо часто. Можно конечно еще заставить использовать индекс, но как-то я противник в этом случае по крайней мере.

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
GET
Или сделать...? Пффф...

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
waldicom
пфффф... пффффф... пффффф..
Уже бы давно бы сделал и протестировал с explain и profiling

_____________
Свои мозги еще никто не отменял.
Телепатов нету.
Игорь_Vasinsky
biggrin.gif

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
GET
доложу позже...

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
glock18
А чего всего еще один индекс. Может быть стоит создать по индексу для каждой комбинации полей в таблице, и не париться!

Кол-во индексов получается весьма демократичным: всего 64 для таблицы с 4 полями.

К сожалению, это исчерпывает лимит на индексы в обоих myisam и innodb. Так что уже для 5 колонок так не получится (нужно 325 индексов уже). Тут уже придется ждать, когда mysql исправит это безобразие.

/sarcasm mode off
GET
Короче пока тестил нашел ошибку все пришлось переделать и оставить только один индекс INT3/INT2/INT1 по которому идет соединение ... тем более вдруг оказалость, что по INT1 может быть диапозон значений IN(), что ломает индекс.

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
glock18
Цитата (ABC @ 14.02.2014 - 11:15)
Короче пока тестил нашел ошибку все пришлось переделать и оставить только один индекс INT3/INT2/INT1 по которому идет соединение ... тем более вдруг оказалость, что по INT1 может быть диапозон значений IN(), что ломает индекс.


разве in() "ломает" индекс? Что "ломает" вообще значит?
GET
<> имел ввиду, не IN, короче голова уже в бреду каком-то.

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
glock18
Цитата (ABC @ 14.02.2014 - 11:33)
<> имел ввиду

мм... ну если "ломает" значит "нельзя использовать этот индекс", то это не так. <> не мешает использовать никакие индексы кроме хешовых. Если же "ломает" значит высокую селективность диапазона, то, возможно, да. Не меняет многое, если все равно все три поля индекса используются, в каком бы порядке они ни были, общее кол-во полученных строк будет таким же
GET
glock18

Ты можешь мне сказать такую вещь.

Когда несколько таблиц джойнится, если INNER JOIN то mysql сам решает какую взять основную, как правило берет ту у которой меньше строк. Сответственно вопрос встает если таблицы примерно равнозгначны в выборе индекса, в заглавном посте я вот задал вопрос...чтоб и волки сыты и овцы целы, ну да есть избыточность. Пришол к чему начал, в зависмости от запроса он выбирает какую таблицу использовать, в чем плох такой подход, ща исключение некоторой избыточности??? : INT3/INT2/INT1 + INT1/INT2/INT3

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
GET
ок... будем искать с перламутровыми пуговицами smile.gif

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.