Hallöchen meine Freunde der Sonne,
an welcher Schraube muss man drehen, wenn Subselects eine Ewigkeit brauchen (>1 Sekunde pro Query) um resolved zu werden?
Beispiel:
UPDATE tablex SET y = z WHERE a IN (SUBSELECT) dauert ewig.
Zuerst den Subselect auszuführen und die erhaltenen Werte dann in oben stehende Query einzusetzen dauert nichtmal ne 1000stel Sekunde.
Thema: MySQL DB Optimierung
-
02.03.2012, 14:37 #1Lieutenant
- Dabei seit
- Sep 2009
- Beiträge
- 514
[SQL] MySQL DB Optimierung
- Anzeige
Logge dich ein, um diese Anzeige nicht zu sehen. -
02.03.2012, 15:26 #2Cadet 1st Year
- Dabei seit
- Nov 2010
- Beiträge
- 15
[SQL] AW: MySQL DB Optimierung
MySQL verwendet keinen Index bei Subselects mit IN()! Daher kann ich davon produktiv nur abraten!
Du musst die Query auf JOIN umschreiben oder die IN()-Werte vorfetchen.
Ansatz siehe hier:
http://www.johnewart.net/posts/2011/...ql_in_queries/
-
02.03.2012, 15:51 #3Lieutenant
Ersteller dieses Themas
- Dabei seit
- Sep 2009
- Beiträge
- 514
[SQL] AW: MySQL DB Optimierung
Danke dir, umgeschrieben ist das Script schon lange auf pre-fetchen, weil es unsäglich lange brauchte.
Ich wusste nur nicht wieso das der Fall ist, aber dank dir bin ich nun schlauer
-
02.03.2012, 15:55 #4Captain
- Dabei seit
- Nov 2008
- Beiträge
- 3.431
[SQL] AW: MySQL DB Optimierung
Generell ist noch immer in den meisten Fällen von Subselects abzuraten, denn MySQLs Optimierungen dafür sind immernoch sehr düftig, das ändert sich erst mit 6.0 - die meisten Sub-Selects werden sowieso aktuell von MySQL in Joins umgeschrieben, also entweder man schreibt den Join gleich selbst oder baut ihn, wie in dem von PeteC verlinkten Artikel, um.
-
03.03.2012, 20:57 #5Lieutenant
- Dabei seit
- Jul 2010
- Beiträge
- 818
[SQL] AW: MySQL DB Optimierung
Gib uns doch mal 'nen Ausschnitt deiner Datenbank und eine ganze Beispielabfrage. Von Hand kann man da bestimmt was reißen. Evtl. könntest du sonst auch noch mit Prepared Statements ein Quäntchen beschleunigen (viel bringt's meist nicht, eher mehr Sicherheit).

Zitieren