Индекс MariaDB для запросов подмножества column1 и диапазона column2

Question

У меня есть этот запрос:

SELECT column1 FROM table WHERE column2 IN (*small set of values*) AND column3 > number

В моей таблице 3 столбца, первичный ключ - (column1, column2).

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

Итак, как построено дерево, и поможет ли оно мне больше, чем создание и индексирование, например, только для column2?

Бонусный вопрос: я видел кое-что о «покрывающем» индексе, который, кажется, работает для меня здесь, но, поскольку нет «бесплатного питания», каково это? Меньше индекса умещается в памяти? Сохраняет ли MariaDB индекс в памяти?

Answer 1

(я полагаю, вы используете InnoDB.)

• INDEX(col2, ...) будет лучше, если IN будет более избирательным, чем >.
• INDEX(col3, ...) будет лучше, если > будет более избирательным.
• InnoDB всегда помещает столбцы PRIMARY KEY в конец каждого вторичного индекса. Следовательно, INDEX(col2, col3) очень похож на INDEX(col2, col3, col1), который "покрывает". То же самое для (col3, col2).
• Ожидая, что PK будет добавлен, я явно добавляю его - это подсказка другим пользователям (и мне), что я стремился к «покрытию» или что-то в этом роде.
• Оптимизатор (ср. «MRR») может иметь возможность перепрыгнуть через IN значения, поэтому ...

Я рекомендую специально:

INDEX(col2,        -- hoping to leapfrog
      col3,        -- assuming the leapfrogging works
      col1)        -- covering

Это , может лучше изменить на PRIMARY KEY(col2, col1), а не имеют дополнительный индекс. Это предполагает , что у вас не было col1 первым на ПК, чтобы воспользоваться некоторыми другими запросами / запросами.

Как составной индекс создается в BTree? Подумайте о соединении столбцов (col1, col2) вместе, чтобы создать один ключ. (Детали могут быть более запутанными, но думать об этом "работает".)

Примечание: данные - это дерево данных, упорядоченное в соответствии с PK. Вторичный индекс - это BTree столбцов во вторичном индексе, плюс PK, в конечных узлах ничего лишнего.

MySQL и MariaDB хранят все индексы на диске (см. Выше), затем кэшируют блоки по 16 КБ в «buffer_pool», который находится в ОЗУ. После некоторого времени работы системы блоки индекса стремятся в этот кеш ; блоки данных могут или не могут.

Если вы смотрите, скажем, «новые» строки в большой, ориентированной по времени таблице, то блоки, индексированные по дате или идентификатору AUTO_INCREMENT, будут иметь тенденцию быть в оперативной памяти, тогда как «старые» строки остаются на диске.

В этом прелесть «кеширования» - вы приближаетесь к «бесплатной еде», чем неуклюжими техниками. Например ... «Я загружу все свои индексы в оперативную память». Но что, если я использую только «новые» его части; это вытеснит другие виды использования оперативной памяти. «Я заблокирую эту таблицу в оперативной памяти». Опять же, это связано с другим использованием ОЗУ, которое может быть более эффективным.