Müssen Sie explizit einen Index erstellen oder ist dieser beim Definieren des Primärschlüssels implizit? Ist die Antwort für MyISAM und InnoDB dieselbe?
Müssen Sie explizit einen Index erstellen oder ist dieser beim Definieren des Primärschlüssels implizit? Ist die Antwort für MyISAM und InnoDB dieselbe?
Antworten:
Der Primärschlüssel ist immer indiziert. Dies gilt auch für MyISAM und InnoDB und gilt im Allgemeinen für alle Speicher-Engines, die überhaupt Indizes unterstützen.
Laut http://dev.mysql.com/doc/refman/5.0/en/constraint-primary-key.html scheint dies implizit zu sein
Obwohl dies 2009 gefragt wurde, stellte ich fest, dass ich einen tatsächlichen Verweis auf die MySQL-Dokumentation zu Primärschlüsseln veröffentlichen würde. http://dev.mysql.com/doc/refman/5.5/en/optimizing-primary-keys.html
Der Primärschlüssel für eine Tabelle repräsentiert die Spalte oder den Satz von Spalten, die Sie in Ihren wichtigsten Abfragen verwenden. Es verfügt über einen zugeordneten Index für eine schnelle Abfrageleistung
Eine Referenz zu MySQL 5.0 finden Sie unter: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
Die meisten MySQL- Indizes ( PRIMARY KEY , UNIQUE, INDEX und FULLTEXT) werden in B-Bäumen gespeichert. Ausnahmen sind, dass Indizes für räumliche Datentypen R-Bäume verwenden und dass MEMORY-Tabellen auch Hash-Indizes unterstützen.
Der Primärschlüssel ist implizit sowohl für MyISAM als auch für InnoDB indiziert. Sie können dies überprüfen, indem Sie EXPLAIN für eine Abfrage verwenden, die den Primärschlüssel verwendet.
Ich denke das ist die Antwort
mysql> create table test(id int primary key, s varchar(20));
Query OK, 0 rows affected (0.06 sec)
mysql> show indexes from test \G
*************************** 1. row ***************************
Table: test
Non_unique: 0
Key_name: PRIMARY
Seq_in_index: 1
Column_name: id
Collation: A
Cardinality: 0
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
1 row in set (0.00 sec)Indizes werden am besten für Spalten verwendet, die häufig in where-Klauseln und bei jeder Art von Sortierung verwendet werden, z. B. "order by". Möglicherweise arbeiten Sie an einer komplexeren Datenbank. Beachten Sie daher einige einfache Regeln.
Indizes beschleunigen, wo Klauseln und Reihenfolge nach. Denken Sie daran, darüber nachzudenken, wie Ihre Daten beim Erstellen Ihrer Tabellen verwendet werden. Es gibt noch ein paar andere Dinge zu beachten. Wenn Ihre Tabelle sehr klein ist, dh nur wenige Mitarbeiter, ist es schlimmer, einen Index zu verwenden, als ihn wegzulassen und ihn einfach einen Tabellenscan durchführen zu lassen.
Indizes sind wirklich nur bei Tabellen nützlich, die viele Zeilen enthalten.
Eine andere Sache, die Sie beachten sollten, ist ein Nachteil in der Situation der Datenbank unserer Mitarbeiter: Wenn die Spalte eine variable Länge hat, arbeiten Indizes (wie auch die meisten von MySQL) viel weniger effizient.
Vergessen Sie nicht, sich auch anzuschließen! Indizierte Join-Felder beschleunigen die Arbeit.
Der Primärschlüssel wird immer automatisch indiziert und ist eindeutig. Achten Sie also darauf, keine redundanten Indizes zu erstellen.
Zum Beispiel, wenn Sie eine Tabelle als solche erstellt haben
CREATE TABLE mytable (foo INT NOT NULL PRIMARY KEY, bar INT NOT NULL, baz INT NOT NULL,
UNIQUE(foo), INDEX(foo)) ENGINE=InnoDB;Da Sie den Primärschlüssel indizieren und eine Eindeutigkeitsbeschränkung erzwingen möchten, werden am Ende tatsächlich drei Indizes erstellt foo!
Man kann sich eine Primärschlüsselspalte wie jede andere indizierte Spalte mit den Einschränkungen des Primärschlüssels vorstellen.
In den meisten Anwendungsfällen benötigen wir sowohl Primärschlüssel als auch indizierte Spalten / Spalten in einer Tabelle, da unsere Abfragen an Tabellen Zeilen basierend auf Spalten / Spalten filtern können, die kein Primärschlüssel sind. In diesem Fall indizieren wir normalerweise diese Spalten / Spalten auch.