"Konfiguration - Loggin-Optionen" bietet aber nur "Datenbankverändernde SQL-Befehle im Backend werden geloggt" "Select ..." ist aber nicht DB-Verändernd - oooder? Dann würde mich aber eigentlich nur eine einzelne DBquery interssieren.
(Link nur für registrierte Nutzer sichtbar.) (Link nur für registrierte Nutzer sichtbar.) die beiden hab ich da in meiner Lesezeichen Liste, aber leider nur in Englisch
weil ich halt ein Schatzi bin ... ne Spass beiseite ... bei größeren Sachen um generell in einem Script zu schauen, halt den (Link nur für registrierte Nutzer sichtbar.)
Holy Moly .. da gib es aber Unterschiede!! SELECT COUNT(*) ... => 0.0340099334717 seconds das gleiche als: SELECT COUNT(shipping_class) AS anzahl ... => 0.000118970870972 seconds
naja der erste ist halt einer mit allem * und der andere ist halt schon differenzierter ... ist doch klar das dort deutliche Unterschiede sind.
Wird in einer Schleife 3x aufgeruften .. nur mit jeweils anderer $mbr_shipping_status: $test_query = xtDBquery("SELECT COUNT(shipping_class) AS anzahl FROM ".TABLE_ORDERS." WHERE date_purchased LIKE '".date("Y-m-d")."%' AND shipping_class = '$mbr_shipping_status' "); Ergebnisse: 0.000120878219604 seconds 9.01222229004E-5 seconds 9.01222229004E-5 seconds dann mal : 0.000116109848022 seconds 5.72204589844E-5 seconds 0.0001220703125 seconds dann wieder so: 0.000113964080811 seconds 0.00011420249939 seconds 0.0001060962677 seconds ... und sach jetzt nicht: "Ist doch klar" !!
doch muss ich ... Du musst ja auch von unterschiedlicher Last auf dem Server ausgehen. Mal ist wenig los, gehts halt schneller, mal ist mehr los, dauerts halt länger, oder zu wenig Kaffee im System ... Dann ist ja auch die Abfrage nicht gleich sondern hat unterschiedliche $mbr_shipping_status. von dem einen muss er nur wenig zählen und von den anderen halt mehr ...
COUNT(*) ist immer vorzuziehen, da das intern schneller verarbeitet werden kann, als wenn man eine Spalte angibt. Da kursieren viele falsche Aussagen dazu im Netz herum. Meine Quelle ist das "High Performance MySQL" Buch von O'Reilly. Damit Performance-Tests nicht verfälscht werden nach dem SELECT noch ein SQL_NO_CACHE hinzufügen. So wird beim zweiten Ausführen nicht auf ein gecachtes Ergebnis zurückgegriffen. Im WHERE LIKEs nach = Vergleichen einfügen, damit noch die Chance besteht, dass ein Index greifen kann.
$test_query = xtDBquery("SELECT COUNT(*) AS anzahl FROM ".TABLE_ORDERS." WHERE shipping_class = '$mbr_shipping_status' AND date_purchased LIKE '".date("Y-m-d")."%' "); Bei Performancetests: $test_query = xtDBquery("SELECT SQL_NO_CACHE COUNT(*) AS anzahl FROM ".TABLE_ORDERS." WHERE shipping_class = '$mbr_shipping_status' AND date_purchased LIKE '".date("Y-m-d")."%' ");
So .. vier Varianten mehrfach getestet: xtDBquery("SELECT SQL_NO_CACHE COUNT(*) AS anzahl FROM ".TABLE_ORDERS." WHERE date_purchased LIKE '".date("Y-m-d")."%' AND shipping_class = '$mbr_shipping_status' "); xtDBquery("SELECT SQL_NO_CACHE COUNT(shipping_class) AS anzahl FROM ".TABLE_ORDERS." WHERE date_purchased LIKE '".date("Y-m-d")."%' AND shipping_class = '$mbr_shipping_status' "); xtDBquery("SELECT SQL_NO_CACHE COUNT(*) AS anzahl FROM ".TABLE_ORDERS." WHERE shipping_class = '$mbr_shipping_status' AND date_purchased LIKE '".date("Y-m-d")."%' "); xtDBquery("SELECT SQL_NO_CACHE COUNT(shipping_class) AS anzahl FROM ".TABLE_ORDERS." WHERE shipping_class = '$mbr_shipping_status' AND date_purchased LIKE '".date("Y-m-d")."%' "); Ergebniss: 0.0331320762634 seconds 0.0333468914032 seconds 0.0328979492188 seconds Bis auf die letzten 6-8 Stellen immer gleiche Ergebnisse! Kann es evtl. sein, das die vier Varianten theoretische Unterschiede haben aber den Servern (vielleicht je nach Ausstattung + Leistung) schnurz piep egal sind?
Also, die Reihenfolge der WHERE-Clauses darf rein theoretisch keinen Unterschied ergeben, weil derlei Effekte vom Query-Optimizer des RDBMS beseitigt werden sollten. Ob es in der Praxis je nach verwendeter MySQL-Version womöglich doch Unterschiede gibt, dazu habe ich auf die Schnelle keine belastbaren Quellen gefunden.
Du siehst mittels EXPLAIN, dass zumindest in MySQL 5.1 und niedriger die Indizes nicht (immer?!) greifen, wenn du sie nicht korrekt ansprichst, was über die Reihenfolge im WHERE-Part bestimmt wird. So jedenfalls meine bisherigen Erfahrungen und Informationen aus dem MySQL-Buch. Kommt vielleicht auf die Intelligenz des Query-Optimizers an. @Manfred: Hier ist MySQL wohl so intelligent, dass es den Befehl in allen Formen intern so optimiert, dass das Ergebnis das gleiche ist .
Das ist auch echt genau das, was mich beruhig: Am letzten Hebel in irgend einem Schaltschrank werden meine Bastelauswüchse wieder in brauchbare Bahnen gelenkt! War trotzdem eine (für mich!) interessante Lehrstunde! DANK Euch ALLEN!