Ist der Primary Key bei MySQL ein Muss oder nur ein Kann?
Hallo! Bei MySQL gibt es ja verschiedene Indexierungs-Arten (Primary, Unique, Index). Ich verwende keinen numerischen Index, daher habe ich auch kein auto-increment. Bei kleineren Datenbanken habe ich festgestellt, dass es hierbei keinen Unterschied macht, welchen Index ich verwende, alle Abfragen sind gleich schnell. Was bringen die unterschiedlichen Indexierungen überhaupt und wirkt sich der Unterschied auf große Datenbanken aus? Danke! Flashbaer
4 Antworten
ohne Index muss die Datenbank immer einen Tablescan machen für Abfragen. D.h. es werden immer alle Datensätze geprüft on sie in die Ergebnismenge passen. Bei kleinen Datenbanken fällt das nicht ins Gewicht, bei grossen macht das einen himmelweiten Unterschied. Du solltest immer einen Primarykey auf Deinen Tabellen haben, da hier normalerwiese Joins drüber laufen. Welche anderen Inizes Du noch setzt hängt vom jeweiligen Anwendungsfall ab
Er ist optional, aber wenn du keinen unique key hast kann bei Ändern oder dem Löschen von Zeilen nicht sicher gestellt werden, dass du nur die gewünschte Zeile änderst. (Es gibt ja keinen eindeutigen Schlüssel, daher kann es sein, dass du einen Schlüssel verwendest durch den ausversehen noch andere Zeilen mitgelöscht werden, die zufällig den gleichen Wert für den verwendeten Schlüssel haben)
Wie das speziell bei MySql ist, weiß ich ich nicht. Ich nehme aber an, dass das wie auch in anderen SQL-Datenbanken gehandhabt wird. Die Unterschiede sind, auch wenn es zwischen den einzelnen Implementierungen welche gibt, meist von untergeordneter Natur.
Der Primary-Key ist im Prinzip ein ganz gewöhnlicher unique-Index, also eindeutig. Manche Datenbanken haben deshalb auch keinen speziellen Primary-Key. Der DB2 von IBM, den ich benutze, hat einen, weil es hierfür eine Zusatzfunktion gibt, den sogenannten Fremdschlüssel, den Foreign-Key. Man kann damit für eine DB-Tabelle festlegen, dass der Inhalt eines Datenfeldes (oder Datengruppe) dem Primary-Key einer anderen DB-Tabelle entsprechen muss. Bei den "Aufträgen" darf z.B. keine Kunden-Nr stehen, die nicht bei den "Kunden" definiert ist. Das nennt sich dann referenzielle. Diese Bedingung nennt sich referentielle Integrität und wird dann von der Datenbank überwacht. Der Unterschied zwischen einem einfachen und einem eindeutigen Index besteht darin, dass bei letzterem die Datenbank für die Eindeutigkeit sorgt, indem sie die Aufnahme von Sätzen verweigert, die die Eindeutigkeit verletzen würden. Beim Suchen über einen Index spielt es mitunter auch eine Rolle, wieviele Treffer möglich sind. Im Embedded-SQL, also SQL aus dem Programm heraus, gibt es einen Lesebefehl, der nur einen Satz lesen kann und nur die zwei Möglichkeiten gefunden oder nichtgefunden unterscheidet. Diesen Befehl kann man nur dann sinnvoll verwenden, wenn man für das Lesen einen eindeutigen Index zugrunde legt. Es gibt Daten, die von Natur aus keinerlei Ordnungsbegriffe aufweisen, die man für einen eindeutigen Index benutzen könnte. In so einem Fall nutzt es auch nichts, die Sätze durchzunummerieren, weil die Nummer ohne Bedeutung ist und man nicht danach sucht. Bei Arbeitsdateien zum Zwischenspeichern kommt sowas gelegentlich vor und man kann im Allgemeinen auch eine solche Tabelle ohne irgendeinen Index einrichten, also auch ohne Primary-Key.
Anmerkungen zu den beiden anderen Anworten:
Es hängt ja nicht von meiner Lust und Laune ab, ob ich einen Primary-Key vorsehe, sondern davon, ob die Daten das überhaupt hergeben. Für ein Telefonbuch z.B. ginge das gar nicht, weil der Name der Ordnungsbegriff ist und gleichnamige Einträge sich auch nicht vermeiden lassen.
Die Zeit für das Durchsuchen der Tabelle ist zwar eine wesentliches Kriterium, es gibt aber auch kleine Tabellen, wo das trotzdem schnell geht oder auch Anwendungen, wo gar nicht gesucht werden muss.
ein muss, denn das ist wie der Name schon sagt DER Schlüssel
Ein Muss ist das nicht. Es kommt darauf an, ob man einen benötigt und normalerweise trifft das auch zu. Es gibt aber Ausnahmen. Wenn man eine Tabelle hat, die immer nur sequentiell und komplett gelesen wird, braucht man weder Primärschlüssel noch irgend einen anderen Index. Ich habe eine Anwendung bei einem Kunden mit 55 Tabellen laufen, davon sind zwei ohne Primärschlüssel. Solche Ausnahmen sind natürlich nicht Sinn einer Datenbank. Normalerweise braucht man einen Primärschlüssel und meistens noch einige Indizes zusätzlich.