Привет.
Знаю, что в 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 составных индекса)
Не будет ли это избыточным?
Или я уже глупость пишу...
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Вопрос снят, оставил один обратный: INT3/INT2/INT1 по которому идет соединение
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Игорь_Vasinsky
14.02.2014 - 13:19
чем руководствовался? тестировал?
_____________
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
Игорь_Vasinsky
Цитата |
чем руководствовался? тестировал? |
на бумажке нарисовал варианты
вариант хорош, когда N3 последний столбец константа, когда это интервал ...ну апидется заходить во второй столбец, но зато таблица меньше и в моем случае это не должно быть особо часто. Можно конечно еще заставить использовать индекс, но как-то я противник в этом случае по крайней мере.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Или сделать...? Пффф...
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
waldicom
14.02.2014 - 13:36
пфффф... пффффф... пффффф..
Уже бы давно бы сделал и протестировал с explain и profiling
_____________
Свои мозги еще никто не отменял.
Телепатов нету.
Игорь_Vasinsky
14.02.2014 - 13:39
_____________
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
доложу позже...
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
glock18
14.02.2014 - 14:03
А чего всего еще один индекс. Может быть стоит создать по индексу для каждой комбинации полей в таблице, и не париться!
Кол-во индексов получается весьма демократичным: всего 64 для таблицы с 4 полями.
К сожалению, это исчерпывает лимит на индексы в обоих myisam и innodb. Так что уже для 5 колонок так не получится (нужно 325 индексов уже). Тут уже придется ждать, когда mysql исправит это безобразие.
/sarcasm mode off
Короче пока тестил нашел ошибку все пришлось переделать и оставить только один индекс INT3/INT2/INT1 по которому идет соединение ... тем более вдруг оказалость, что по INT1 может быть диапозон значений IN(), что ломает индекс.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
glock18
14.02.2014 - 15:17
Цитата (ABC @ 14.02.2014 - 11:15) |
Короче пока тестил нашел ошибку все пришлось переделать и оставить только один индекс INT3/INT2/INT1 по которому идет соединение ... тем более вдруг оказалость, что по INT1 может быть диапозон значений IN(), что ломает индекс. |
разве in() "ломает" индекс? Что "ломает" вообще значит?
<> имел ввиду, не IN, короче голова уже в бреду каком-то.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
glock18
14.02.2014 - 15:38
Цитата (ABC @ 14.02.2014 - 11:33) |
<> имел ввиду |
мм... ну если "ломает" значит "нельзя использовать этот индекс", то это не так. <> не мешает использовать никакие индексы кроме хешовых. Если же "ломает" значит высокую селективность диапазона, то, возможно, да. Не меняет многое, если все равно все три поля индекса используются, в каком бы порядке они ни были, общее кол-во полученных строк будет таким же
glock18
Ты можешь мне сказать такую вещь.
Когда несколько таблиц джойнится, если INNER JOIN то mysql сам решает какую взять основную, как правило берет ту у которой меньше строк. Сответственно вопрос встает если таблицы примерно равнозгначны в выборе индекса, в заглавном посте я вот задал вопрос...чтоб и волки сыты и овцы целы, ну да есть избыточность. Пришол к чему начал, в зависмости от запроса он выбирает какую таблицу использовать, в чем плох такой подход, ща исключение некоторой избыточности??? : INT3/INT2/INT1 + INT1/INT2/INT3
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
ок... будем искать с перламутровыми пуговицами
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.