Посмотрите http://dev.mysql.com/doc/refman/5.5/en/ind...timization.html

потому что если статус у вас не отекает почти ничего (селективность предиката высока) - преимущества использования этого индекса против индекса по id - не очевидны. Два индекса вам точно не нужны. Нужен ли индекс по паре - сомнительно. Вполне есть смысл задуматься окупятся ли расходы на его содержание профитом от его использования. И если  врезультате этих раздумий таки решите что - да, имеет смысл дропнуть индекс по id, ибо индекс по паре (id,status) может быть использван для тех же целей, для каких может быть использован индекс по id

Добавлено @ 16:10

хотя....

Akina, мася умеет такую хрень:

?

Добавлено @ 16:15

Это же совсем не о том... здесь нет индекс мержа.   
Здесь реньжскан индекса по balanse>100 + нестед луп, с уник/реньжскану  по индексу t2.id

Это сообщение отредактировал(а) Zloxa - 5.6.2013, 10:33

Парни, очень признателен за помощь! За эти сутки узнал много нового, по-другому начал смотреть на это дело. Утро вечера мудренее, тот мутный запрос уже удалось ускорить с 25 до <0.05сек  ну еще раза в два ускорить, и я буду совсем доволен.  

Такой еще вопрос по теме: а можно при JOIN как-то явно указать лидирующую таблицу? Просто я уверен что сейчас она не оптимальная, хотя бы попробовать что будет. Запихнул все индексы нового лидера в IGNORE, выполняет полное сканирование, но все равно выбирает эту таблицу! Можно как-то явно указать приоритетную?

И если у кого есть что интересного по теме, желательно на русском, буду рад ссылочкам. И инглыш тоже. МАН хорош, но местами суховат, описание, пример-другой, а особенностей применения не особо.

узнал про STRAIGHT_JOIN 

Не понял, что имеется в виду... если про то, что раньше первичным был один индекс, а теперь он стал обычный, а первичным стал другой - запросто.


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

использовать для контроля ограничения первичного/уникального ключа составной, не уникальный индекс, содержащий в себе перечисление большего количество полей нежели нужны для контроля ограничения.

Т.е. не уникальный индекс по (id,status), а ограничение ПК по (id) использует этот индекс

Добавлено через 4 минуты и 21 секунду

Может... но и в этих сценариях нет индексмержинга ))

Добавлено через 6 минут и 52 секунды

В оракле, кстате, очень не популярный метод жойна.

Составной первичный индекс? Да пжалста. Причём по текстовым полям можно не всё поле в индекс, а только необходимый префикс. 


ааа... не, вот чего нет того нет.

оракля в этом отношении вобще умняшка... может даже сам определить, что для поддержания ограничения нового индекса не надо

Угу... вот только у него так получается, что часть индекса - первична и уникальна, а сам индекс - NONUNIQUE. Не сообразил, аднака... косячок-с...

да нет косячка, нормуль все.

Структура уникального индекса ничем не отличается от структуры не уникального индекса. Если уж на то пошло, уникальный индекс сам по себе - пережиток старины. Для контроля целостности должны использоваться ограничения, а не индексы. Для своей работы ограничения могут требовать наличия индекса(и даже строить его самостоятельно, при создании). В общем-то индекс это просто некая вспомогательная структура данных, к логической организации данных отношения никоим местом иметь не должная. Но т.к. у нас есть богатое историческое наследие использования индексов для контроля целостности...

Это сообщение отредактировал(а) Zloxa - 5.6.2013, 14:36

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

Если, к примеру, не сильно опытный разработчик, ориентируясь только на сведения об уникальности, сделает допустимым дублирование, и в результате уткнётся в отражёнку - будет не совсем красиво, правда? а ведь вроде бы как всё честно, индекс неуникален - а даёт отлуп...   кстати, при нарушении уникальности при занесении данных в таблицу именно такой структуры - как именно будет выглядеть отражёнка? любопытно...

В том то все и дело. Повторюсь. Уникальный и не уникальный индекс имеют одинаковую структуру. Если бы уникальный имел более оптимальную какуюнить струтуру хранения, логику построения, строить его по заведомо уникальным полям имело бы какой-то смысл.


Сведения о требовании уникальности сохранены в структуре данных ограничением первичного ключа. Обеспечиватеся это требование уникальным ли индексом - не уникальным ли - какая разница?




с уникальным индексом - то же самое.

Надо заметить, что в ошибке сказано про ограничение, хотя ограничения, как такового не прописано и оно нигде не числится.


Однако, надо отдать должное, что исторически исключение ORA-00001 в PL/SQL имеет мнемонику dup_val_on_index

Это сообщение отредактировал(а) Zloxa - 5.6.2013, 15:17

То есть он правильно именно в констрейнт носом тычет. Гуд. 


Да понятно это - условие реально отделено от индекса.