Forgein Keys - schlecht für die Performance

Vom Nutzen bin ich doch ein sehr großer Fan von Forgein Keys (ich nutze die bei MySQL mit der Tabellenengine InnoDB). Jedoch mache ich mir immerwieder Gedanken ob sich der Luxus von der Performance her lohnt. Im Internet findet man da wie so oft unterschiedliche Meinungen und um mal wieder bissl Schwung ins Entwicklerforum zu bringen dachte ich mir ich werf meine Gedanken mal in den Raum.

Im Internet liest man doch sehr oft, dass es für MySQL ja ein Mehraufwand ist durch Forgein Keys voneinander abhängige Tabellen zu durchsuchen und zu überprüfen ob da je nach Forgein Key auch alles passt.
Bis hierhin stimme ich dem auch zu, dass man dadurch Performance verliert.

Aber nehmen wir mal ein einfaches Beispiel. Ich habe eine Benutzer Tabelle und eine Gebäude Tabelle. Die Gebäude haben eine Spalte "Besitzer" welche via Forgein Key von der Spalte "BenutzerId" der Benutzer Tabelle abhängig ist. Falls der User gelöscht wird, sollen auch die Gebäude gelöscht werden (ON DELETE CASCADE).

Ohne Forgein Keys würde ich den User löschen und dann z.B. noch ein DELETE FROM Gebäude WHERE Besitzer = BenutzerId.

Mit Forgein Keys lösche ich nur den Benutzer und dann werden zusätzlich die ganzen Gebäude durchsucht und die entsprechenden gelöscht, was ja vom Aufwand von MySQL das gleiche ist, oder? Und zuästzlich spare ich mir ein Query!?

Wenn ich also 1 und 1 zusammen zähle sind in solchen Situationen Forgein Keys sogar schneller!?

Erfahrungen/Meinungen?

Beim Löschen und Aktualisieren sparst du dir mit Foreign Keys ein bisschen Performance. Allerdings ist das Löschen eines Spielers im Vergleich zu Einträgen in die Gebäudetabelle ein verschwindent seltenes Ereignis, wodurch der Performancevorteil da eher akademisch ist.

Im Endeffekt kostet dich jedes Hinzufügen oder Aktualisieren einer Zelle welche eine andere Tabelle referenziert ein zusätzliches SELECT Statement welches von der Datenbank intern ausgeführt wird um die Integrität der Daten zu prüfen. Wieviel das an Performance kostet kann man sich daher recht einfach ausmalen.

Tendenziell werden dir die zusätzlichen SELECTs nicht die Performance killen da ein SELECT auf einen Primary Key noch am wenigsten Zeit kostet und am wenigsten Datenbankbelastung produziert. Der einzige Nachteil ist das es SELECTs sind welche sich nicht durch memcached und co unterbinden lassen da sie direkt in der Datenbank ausgeführt werden.

Kein Select. Deswegen legen alle mir bekannten Datenbanken automatisch Indices auf die Fremdschlüssel, um eben nicht über die ganze Gegentabelle rutschen zu müssen.

Und ein Fremdschlüssel auf die Gebäudetabelle dürfte so auch ein "SELECT * FROM gebäude WHERE spielerid = '4711'" beschleunigen, da er ja nur über den Index des Fremdschlüssels laufen muss, nicht über die ganze Gebäudetabelle.

Original von Kampfhoernchen

Und ein Fremdschlüssel auf die Gebäudetabelle dürfte so auch ein "SELECT * FROM gebäude WHERE spielerid = '4711'" beschleunigen, da er ja nur über den Index des Fremdschlüssels laufen muss, nicht über die ganze Gebäudetabelle.

Dafür würde aber auch ein normaler Key auf spielerid reichen.

Das heisst allerdings nicht, dass ich foreign keys nicht auch mag. ;)

Zum Performance Impact kann ich allerdings nichts sagen, da würde mich mehr Feedback auch interessieren. Technisch sauberer ist es definitiv.

Original von exe

Beim Löschen und Aktualisieren sparst du dir mit Foreign Keys ein bisschen Performance. Allerdings ist das Löschen eines Spielers im Vergleich zu Einträgen in die Gebäudetabelle ein verschwindent seltenes Ereignis, wodurch der Performancevorteil da eher akademisch ist.

Im Endeffekt kostet dich jedes Hinzufügen oder Aktualisieren einer Zelle welche eine andere Tabelle referenziert ein zusätzliches SELECT Statement welches von der Datenbank intern ausgeführt wird um die Integrität der Daten zu prüfen. Wieviel das an Performance kostet kann man sich daher recht einfach ausmalen.

Tendenziell werden dir die zusätzlichen SELECTs nicht die Performance killen da ein SELECT auf einen Primary Key noch am wenigsten Zeit kostet und am wenigsten Datenbankbelastung produziert. Der einzige Nachteil ist das es SELECTs sind welche sich nicht durch memcached und co unterbinden lassen da sie direkt in der Datenbank ausgeführt werden.

Sehe es eigentlich wie EXE. Wobei ich mich hier in erster Linie auf meine Erfahrungen bei meinem eigenen Browsergame (mit ca. 3200 Usern) und als Datenbankentwickler eines mittelständischen Unternehmens stützen kann.