эффективное упорядочение ключей в составном индексе MySQL (полиморфные ассоциации WRT Rails и STI)

Ранее Я задал этот вопрос о составных индексах полиморфных внешних ключей в ActiveRecord . В основе моего вопроса лежало мое понимание того, что индексы должны основываться на мощности вашего столбца, и, как правило, у Rails типа STI и полиморфных столбцов _type довольно низкая мощность.

Признавая, что ответ на мой вопрос правильный - в том, что индексирование столбцов _id с высокой мощностью и столбца _type с низкой мощностью имеет значение, потому что вместе они имеют высокую мощность, мой следующий вопрос: как вы должны упорядочить составные индексы?

При индексе [owner_id, owner_type] первым помещается поле с более высокой мощностью, а [owner_type, owner_id] - вторым. Является ли запрос с использованием первого ключа более производительным, чем запрос с использованием последнего ключа, или они одинаково эффективны?

Я спрашиваю, потому что это имеет особое отношение к тому, как я буду заказывать составные ключи для таблиц, обслуживающих модели STI. Поисковики STI Rails почти всегда запрашивают столбец типа, который, опять же, обычно имеет низкую мощность. Поэтому столбец типа запрашивается гораздо чаще, чем другие индексы. Если столбец типа запрашивается гораздо чаще, тогда, возможно, имеет смысл использовать ведущий по типу индекс, потому что менее конкретные запросы могут использовать преимущества первой части индекса, что приведет к повышению производительности. Тем не менее, я бы не стал уменьшать привилегию, чтобы нанести ущерб производительности узкоспециализированным запросам. которые используют часть индекса с более высокой мощностью.