Индексы MySQL 5.0 - Уникальный по сравнению с Не Уникальный
Предупреждение: недопустимое смещение строки 'XXX'
Это происходит, когда вы пытаетесь получить доступ к элементу массива с синтаксисом с квадратной скобкой, но вы делаете это по строке, а не по массиву, поэтому операция явно не имеет смысла .
Пример:
$var = "test";
echo $var["a_key"];
Если вы считаете, что переменная должна быть массивом, см., где она появляется и исправить там проблему.
2 ответа
УНИКАЛЬНЫЙ КЛЮЧ и PRIMARY KEY ограничения , не индексы. Хотя большинство баз данных реализует эти ограничения при помощи индекса. Дополнительные издержки ограничения в дополнение к индексу незначительны, особенно когда Вы считаете в обратном порядке стоимость отслеживания и исправления неумышленных дубликатов, когда (не, если) они происходят.
Индексы являются обычно более эффективными, если там у Вас есть высокое селективность . Это - отношение количества отличных значений к общему количеству строк.
, Например, в столбце для Номера социального страхования, у Вас может быть 1 миллион строк с 1 миллионом отличных значений. Таким образом, селективность является 1000000/1000000 = 1.0 (хотя существуют редкие исторические исключения, SSN's предназначаются, чтобы быть уникальным).
, Но другой столбец в той таблице, "пол" может только иметь два отличных значения более чем 1 миллион строк. 2/1000000 = очень низкая селективность.
индекс с УНИКАЛЬНЫМ КЛЮЧОМ или ограничением PRIMARY KEY, как гарантируют, будет иметь селективность 1,0, таким образом, это всегда будет столь эффективно, как индекс может быть.
Вы спросили о различии между первичным ключом и ограничением на уникальность данных. В основном именно, что у Вас может быть только одно ограничение первичного ключа на таблицу (даже если определение ограничения включает несколько столбцов), тогда как у Вас может быть несколько ограничений на уникальность данных. Столбец с ограничением на уникальность данных может разрешить, АННУЛИРУЕТ, тогда как столбцы в ограничениях первичного ключа не должны разрешать, АННУЛИРУЕТ. Иначе первичный ключ и уникальный очень похож в их реализации и их использовании.
Вы спросили в комментарии о том, использовать ли 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 достаточно часто, что ясно не возможно сказать, что каждый быстрее, чем другой.
Как с большинством связанных с производительностью вопросов, единственный способ ответить на него для Вашего приложения состоит в том, чтобы протестировать обе конфигурации с помощью приложения и репрезентативной пробы данных, и измерить результаты.
На групповом индексе, который просто, оказывается, уникален и уникальный индекс? Я не уверен, но я предположил бы не много. Оптимизатор должен исследовать кардинальность индекса и использования, что (это всегда будет количество строк для уникального индекса).
, Насколько первичный ключ затронут, вероятно, довольно много, но он зависит, какой механизм Вы используете.
механизм InnoDB (который используется многими людьми), всегда строки кластеров на первичном ключе. Это означает, что PK по существу объединен с фактическими данными строки. При выполнении большого количества поисков PK (или действительно, сканирования диапазона и т.д.), это - Хорошая Вещь, потому что это означает, что это не должно будет выбирать как много блоков от диска.
А уникальный индекс неPK никогда не будет кластеризироваться в InnoDB.
, С другой стороны, некоторые другие механизмы (MyISAM в особенности) не кластеризируют PK, таким образом, первичный ключ точно так же, как нормальный уникальный индекс.