Индексы и много первичные ключи столбца
Пошел ища и не нашел ответ на этот определенный вопрос о новичке. Мои извинения, если я пропустил его.
В базе данных MySQL у меня есть таблица со следующим первичным ключом
Идентификатор PRIMARY KEY (счет, объект)
В моем приложении я буду также часто выбирать на "объекте" отдельно и менее часто только на "счете". Я предполагаю, что извлек бы выгоду из индексов на этих столбцах.
MySQL не жалуется, когда я определяю следующее:
ИНДЕКС (счет), ИНДЕКС (объект), идентификатор PRIMARY KEY (счет, объект)
Но я не вижу доказательства (использование ОПИСЫВАЮТ - единственный способ, которым я знаю, как посмотреть), что отдельные индексы были установлены для этих двух столбцов.
Таким образом, вопрос, столбцы, которые составляют первичный ключ, автоматически индексированный индивидуально? Кроме того, есть ли лучший путь, чем ОПИСЫВАЮТ для исследования структуры моей таблицы?
4 ответа
Я не очень хорошо знаком с внутренним устройством индексов mySql, но в двух знакомых мне продуктах поставщиков баз данных (MsSQL, Oracle) индексы представляют собой структуры сбалансированного дерева, узлы которых организованы в виде последовательного кортежа столбцы, для которых определен индекс ( В Определенной последовательности )
Итак, если mySql не делает это совсем иначе (вероятно, нет), любой составной индекс (более чем для одного столбца) может может использоваться любым запросом, который должен фильтровать или сортировать по подмножеству столбцов в индексе, пока список столбцов является совместимым, т. Е. Если столбцы при одинаковом порядке упорядочены как упорядоченный список столбцов в полном индексе, это упорядоченное подмножество полного набора столбцов индекса, которое начинается в начале фактической последовательности индекса, без пробелов, кроме конца ...
Другими словами , это означает, что если у вас есть индекс по (a, b, c, d), запрос, который фильтрует по (a), (a, b) или (a, b, c), также может использовать индекс, но запрос, который нужно фильтровать по (b), или (c), или (b, c), не сможет использовать индекс ...
Так что в вашем случае, если вам часто нужно фильтровать или сортировать по столбцу элемент , вам нужно добавить еще один индекс в этот столбец отдельно ...
Чтобы вернуть информацию об индексе таблицы, вы можете использовать:
SHOW INDEX FROM <table>;
См .: http://dev.mysql.com/doc/refman/5.0/en/show-index.html
Для просмотра таблицы информация:
SHOW CREATE TABLE <table>;
См .: http://dev.mysql.com/doc/refman/5.0/en/show-create-table.html
Первичные ключи являются индексами, поэтому нет необходимости создавать дополнительные индексы. Дополнительную информацию о них можно найти в синтаксисе CREATE TABLE (здесь слишком много, чтобы вставить):
Я лично использую phpMyAdmin для просмотра и редактирования структуры баз данных MySQL. Это веб-приложение, но оно работает достаточно хорошо на локальном веб-сервере (я запускаю экземпляр apache на своей машине для этого и phpPgAdmin).
Что касается составного ключа (invoice, item), то он действует как индекс для (invoice, item) и для invoice. Если вы хотите индексировать только по item, вы должны добавить этот индекс самостоятельно. Ваш PK будет отсортирован по invoice, а затем по item, где invoice одинаков в нескольких записях. Хотя порядок в составном PK не имеет значения для обеспечения уникальности, он имеет значение для доступа.
На вашей таблице я бы использовал:
PRIMARY KEY id (invoice, item), INDEX (item)
Я не так хорошо знаком с MySQL, но обычно многоколоночный индекс одинаково полезен как для первого столбца в индексе, так и для индекса только для этого столбца. Многоколоночный индекс становится менее полезным для запросов к одному столбцу, чем дальше столбец находится в индексе.
Это имеет определенный смысл, если рассматривать многостолбцовый индекс как иерархию. Первый столбец в индексе является корнем иерархии, поэтому поиск по нему сводится к сканированию первого уровня. Однако для того чтобы просканировать второй столбец, база данных должна просмотреть дерево для каждого уникального значения, найденного в первом столбце. Это может быть достаточно дорогостоящим, поэтому большинство оптимизаторов не станут углубляться в многостолбцовый индекс, а предпочтут полное сканирование таблицы.
Например, если у вас есть таблица следующего вида:
Col1 |Col2 |Col3
----------------
A | 1 | Z
A | 2 | Y
A | 2 | X
B | 1 | Z
B | 2 | X
Предполагая, что у вас есть индекс на все три столбца по порядку, дерево будет выглядеть примерно так:
A
+-1
+-Z
+-2
+-X
+-Y
B
+-1
+-Z
+-2
+-X
Искать Col1='A' легко: вам нужно просмотреть только 2 упорядоченных значения. Однако, чтобы найти col3='X', необходимо просмотреть все значения в 4 больших ведрах, каждое из которых упорядочено по отдельности.