Индексы MySQL 5.0 - уникальные и не уникальные

Question

В чем разница между уникальным и неуникальным индексом MySQL с точки зрения производительности?

Допустим, я хочу создать индекс для комбинации из 2 столбцов, и комбинация уникальна, но я создаю неуникальный индекс. Повлияет ли это на производительность или объем памяти, используемый MySQL?

Тот же вопрос, есть ли разница между первичным ключом и уникальным индексом?

Answer 1

UNIQUE и PRIMARY KEY являются ограничениями , а не индексами. Хотя большинство баз данных реализуют эти ограничения с помощью индекса. Дополнительные издержки ограничения в дополнение к индексу незначительны, особенно когда вы подсчитываете стоимость отслеживания и исправления непреднамеренных дубликатов, когда (не если) они возникают.

Индексы обычно более эффективны, если у вас высокая селективность . Это отношение количества различных значений к общему количеству строк.

Например, в столбце «Номер социального страхования» может содержаться 1 миллион строк с 1 миллионом различных значений. Таким образом, селективность составляет 1000000/1000000 = 1,0 (хотя существуют редкие исторические исключения, SSN предназначены для уникальности).

Но другой столбец в этой таблице, «пол», может иметь только два различных значения более 1 миллиона строк. 2/1000000 = очень низкая селективность.

Индекс с ограничением UNIQUE или PRIMARY KEY гарантированно имеет селективность 1,0, поэтому он всегда будет настолько эффективным, насколько может быть индекс.

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

Вы спросили в комментарии о том, использовать ли MyISAM или InnoDB. В MySQL они используют термин механизм хранения . Есть несколько тонких различий между этими двумя механизмами хранения, но главные из них:

• InnoDB поддерживает транзакции, поэтому вы можете откатить или зафиксировать изменения. MyISAM эффективно всегда автокоммит.
• InnoDB обеспечивает ограничения внешнего ключа. MyISAM не применяет и даже не хранит ограничения внешнего ключа.

Если вам нужны эти функции в вашем приложении, вам следует использовать InnoDB.

---

Чтобы ответить на ваш комментарий, это не так просто. InnoDB на самом деле быстрее, чем MyISAM, во многих случаях, поэтому он зависит от того, какое сочетание приложений выбирает, обновляет, одновременно выполняет запросы, индексы, конфигурирует буфер и т. Д.

См. http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/ для очень тщательного сравнения производительности механизмов хранения. InnoDB выигрывает у MyISAM достаточно часто, так что явно нельзя сказать, что один быстрее другого.

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

Answer 2

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

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

Механизм InnoDB (который используется многими людьми) всегда группирует строки на первичном ключе. Это означает, что PK по существу объединен с фактическими данными строки. Если вы выполняете много поисков по PK (или даже сканируете диапазон и т. Д.), Это хорошая вещь, потому что это означает, что вам не нужно будет извлекать столько блоков с диска.

Уникальный индекс не-PK никогда не будет кластеризован в InnoDB.

С другой стороны, некоторые другие механизмы (в частности, MyISAM) не кластеризуют PK, поэтому первичный ключ аналогичен обычному уникальному индексу.