Множественный или единственный составной индекс

Question

Предположим, у вас есть таблица с id,a,b,c,d,e,f,g примерно с 1 миллионом строк. Затем можно было сделать запрос с несколькими условиями WHERE ...AND...AND...etc в нескольких комбинациях. Это, например, a AND b AND e или a AND f AND g или e AND f AND g.

Так что для учета всех комбинаций вам нужно было бы создать несколько составных индексов, но что, если a,b,c,d,e,f,g имеют диапазон от [1,10], следовательно, нет нуля.

Может один просто сделать одно соединение за переменной начальной, так и a,b,c,d,e,f,gb,a,c,d,e,f,g и т.д .. и во время запроса сделать что-то вроде

#b and e have not been chosen 
    SELECT * FROM WHERE a=3 AND b!=0 AND c=4 AND d=5 AND e!=0 AND f=1 AND g=9 
    #I think you get the logic 

Может ли такая процедура позволит MySQL по-прежнему использовать индекс соединения или сделать I действительно необходимо создать все возможные комбинации составных индексов.

В конечном итоге приведет к сокращению числа индексов до 7 вместо числа левых комбинаций, которая является-плюсом образом выше, чем 7.

Answer 1

MySQL будет использовать составные индексы в порядке, если это возможно. Поэтому, если ваши данные представляют некоторую таксономию, будет действовать один индекс. Допустим, клиенты могут быть типа бизнеса или личного, и жить в той или иной почтовый индекс, и быть премиум статус или регулярно, то запрос, как

SELECT * FROM customer 
WHERE type = 'business' 
AND postal_code = '12345' 
AND status = 'premium'; 

будет иметь возможность использовать индекс на основе составного ключа, построенного от type + postal_code + status. Если вы не знаете status, индекс все равно будет полезен. Но если вы только знали postal_code, но не type, указатель не использовался - вопросы заказа.

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

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

Стоимость поддержания индекса может быть тривиальной ... или нет. В сильно настроенных транзакционных системах одна вставка, обновление или удаление приведут к записи N + 1: одному для строки, а другой N для каждого индекса. Если вы в основном читаете, то это может быть хорошо. Если нет, то некоторая комбинация составных ключей может иметь некоторую выгоду, уменьшая количество записей.

Но я работаю с реляционной базой данных уже более нескольких десятилетий. Случаи, когда этот сценарий возникает, почти всегда решались путем пересмотра дизайна схемы; Я не помню случая, когда составной ключ имел больше смысла, чем несколько индексов в типичной реляционной и хорошо нормированной схеме.