nicht angemeldet
Hallo Rolf,
ein ORDER BY ID ist sinnlos, wenn Du nach genau einer ID suchst.
klar, das stimmt.
Ich habe deinen Explain mal spaltengerecht verteilt. Was auffällt, ist das NULL bei "possible keys". Offenbar meint er, er hätte keinen passenden Index für Dich? Dann besteht immer die Gefahr, dass er einen Table Scan machen muss, und wenn sein Cache gerade anderweit belegt ist, dauert das lange.
"AND ID="60829" ID ist eine int-Spalte (übrigens ein Weglassen der Quotes ändert im Explain-Ergebnis nichts, das habe ich ausprobiert)
Bringt ein Index auf ID etwas?
Unter "keys" steht dann PRIMARY. Welche Spalte ist der Primary Key der Table? Welche Indexe hast Du noch? Wieviele Rows hat die Table?
Primary = B_ID (in der Query komplett unberücksichtigt) Key = R_ID (in der Query auch komplett unberücksichtigt) Rows sind etwas unter 100.000 Auffällig, dass die Anzahl der Rows durchaus Auswirkung auf die Slowqueryzeit zu haben scheint. In einem anderen System mit knapp über 40.000 Rows gehen die Sowqueryzeiten "nur" bis ca. 6-7 Sekunden hoch.
Die 20s können übrigens auch daher rühren, dass eine andere Query parallel die Table festhält. Das ist mit handgemachtem Logging kaum herauszubekommen, es sei denn, du loggst JEDEN SQL Zugriff und prüfst, ob während der slow-query andere Queries auf der Tabelle zeitgleich aktiv sind.
Hm, irgendwie befürchte ich, dass die Query selber wirklich nicht das Problem ist... denn sonst müßte sie immer geloggt werden, nicht nur ab und zu. Zudem läuft sie ja im phpmyadmin schnell.
Pit
Rolf B
MudGuard