Thread SQL_CALC_FOUND_ROWS()
(18 answers)
Opened by Froschpopo at 2007-05-13 21:14
Morgen!
Das Ergebnis von EXPLAIN mit und ohne SQL_CALC_FOUND_ROWS ist haargenau dasselbe. Das Problem ist eigentlich, dass zu dem Statement später noch zahlreiche weitere JOIN's, Sub-Select's und eine große Menge von WHERE-Bedingungen folgt. Ich müsste dasselbe Statement dann nochmal ausführen, nur wegen einem COUNT(). Da bietet es sich schon an, SQL_CALC_FOUND_ROWS beim ersten Query schon zu implentieren, dann muss ich später nur noch das Ergebnis abgreifen. Insofern ist SQL_CALC_FOUND_ROWS genau das was ich suche! Soll heißen: Auch ohne LIMIT und ORDER wäre die Abfrage ohnehin schon relativ mächtig. Zu "FORCE INDEX" habe ich noch eine Frage: Welchen INDEX soll ich erzwingen? Habs schon versucht mit Code: (dl
)
FORCE INDEX(PRIMARY) aber das macht die Abfrage nur noch langsamer. Mit FORCE INDEX dauert sie 18 Sekunden, ohne 12 Sekunden. Das alles muss etwas mit der Größe von "photos" zu tun haben. Denn die Tabelle ist trotz der wenigen Spalten (4) sehr groß: über 400.000 Datensätze ergeben insg. fast 1.2GB. Ich habe mich aber ordnungsgemäß an sämtliche Optimierungstipps gehalten und verwende auch keinen INDEX auf die LongBlob-Spalte. hab dazu auch noch im bugreport etwas gefunden: http://bugs.mysql.com/bug.php?id=25976 das soll angeblich kein bug sein. So ganz versteh ich es aber noch nicht. Ich könnt schon wieder and die Decke gehen und das um 8 Uhr in der Früh. Alles wieder scheisse hier.\n\n <!--EDIT|Froschpopo|1179124355--> |