MySQL Abarbeitung einer WHERE Klausel....

[Paykoman]

Hallöchen,

ich würde gerne wissen ob der Datenbankserver eine WHERE-Klausel in der selben Reihenfolge abarbeitet wie er sie erhalten halt?
Also ähnlich wie bei php (if else)...

Es geht mir um eine überregionale Tabelle, dort enthält jeder Eintrag einmal den Länder-ISO-code als auch Geo-Daten (Latitude und Longitude).
Da diese Tabelle extrem viele Einträge hat, würde ich gerne wissen ob es Sinn macht am Anfang ein WEHRE iso = 'de' zusetzen, dann müsste die Datenbank ja eigentlich erstmal alle Einträge z.B. aus DE selektieren und im zweiten Schritt diese bei einer Umkreissuche dann entsprechend weiter selektieren.

Oder besser gleich für jedes Land ne eigene Tabelle? Würde natürlich die fortlaufende ID zerstören da müsste ich alles umbauen und den ISO-Code der ID voranstellen.

MfG: Paykoman

[akretschmer]

das hängt ganz von der Intelligenz der Datenbank ab. Andere DB-Systeme zeigen Dir im Explain, wie sie das abarbeiten. MySQL ist da etwas, ähm, weniger intelligent. Ach ja: wenn Du Umkreissuche machen willst, PostgreSQL kann das Indexbasiert machen, siehe KNN-Algorithmus. Das kann MySQL nicht.

[Paykoman]

das hängt ganz von der Intelligenz der Datenbank ab. Andere DB-Systeme zeigen Dir im Explain, wie sie das abarbeiten. MySQL ist da etwas, ähm, weniger intelligent. Ach ja: wenn Du Umkreissuche machen willst, PostgreSQL kann das Indexbasiert machen, siehe KNN-Algorithmus. Das kann MySQL nicht.

Hmm hab es mal ausprobiert:

Extra:"Using where; Using filesort"
id:"1"
key:null
key_len:null
possible_keys:null
ref:null
rows:"3"
select_type:"SIMPLE"
table:"auc_article"
type:"ALL"

Sagt mir jetzt nicht sonderlich viel

[akretschmer]

Sagt mir jetzt nicht sonderlich viel

Das macht nix, geht mir auch so. Das EXPLAIN von MySQL ist weitestgehend wertlos. Du kannst Dir mal https://explain.depesz.com/history Explain-Ausgaben von PostgreSQL ansehen, da sieht man erheblich mehr Details zur Ausführung.

[Paykoman]

Hmm okay, kann ja mal mein derzeitiges Query posten, falls wem was dazu einfällt...

SELECT auc_article.id, typ, tit, stit, start, ends, co, zip, lat, lng, bold, pp, db, bid, bids, ct, pic.ext, pic.srv, pic.ar FROM <pf>auc_article
    LEFT JOIN <pf>media_pic AS pic ON pic.oid = CONCAT('auc-', auc_article.id) AND pic.id = 1
    WHERE co = :iso AND cat = :cat AND top = :top AND (lat BETWEEN :minLat AND :maxLat) AND (lng BETWEEN :minLng AND :maxLng) ORDER BY ends ASC LIMIT 120

$argsArray = [
    ':iso' => 'de',
    ':cat' => '10',
    ':maxLat' => 53.06854067098578,
    ':maxLng' => 10.058623460966048,
   ':minLat' => 49.47125932901422,
   ':minLng' => 4.308976539033951,
​​​​​​​    ':top' => 'n'
];

Es änder sich natürlich dynamisch, je nach Filter & Suchbegriffe aber denke das Grundgerüst ist deutlich.

[protestix]

ISO hat keinen Index, setze den erst mal.
Ansonsten kannst du das so machen.
Vergiss die Antworten zu Postgres, wenn du deine DB nicht dahingehend umstellen willst.

[Paykoman]

ISO hat keinen Index, setze den erst mal.

Hmm, wie jetzt? Steht doch gleich am Anfang "WHERE co = :iso" :iso ist nur nen Platzhalter der im Argumenten-Array den gleichen Namen haben muss und dann auf die spalte "co" (Country) angewendet wird.
Oder gibts da noch ne Methode die mir entgangen ist, bzgl. index?

Naja habe noch nie eine Postgres-DB gehabt da müsste ich mich erst einarbeiten und zusehen wie ich`s administriere etc....
Aktuell lasse ich mir mit PHP das Quadrat errechnen in dem selektiert wird und dann mit foreach() die Ecken rausfiltern (da MySql ja kein Radius selektieren kann), weiß nicht wies dann alles wieder mit Postgree ausschaut, viel Aufwand.

[akretschmer]

Noch einmal, prinzipiell kann die DB das selber entscheiden, und wird dies auch tun, wenn sie Hinweise hat, wie es optimal wäre. Dazu führt z.B. PostgreSQL interne Statistiken über alle Spalten aller Tabellen (Histogramm, Verteilung der Werte, diverse andere Dinge) und berechnet daraus, wie viele Datensätze bei welchem JOIN entstehen und optimiert das dann passend. Dazu wird dann noch ein Kostenmodell erstellt, z.B. für Full-Table-Scans, Index-Scans, Index-only-scans, Bitmap-Index-Scans etc. Aus all diesen möglichen Varianten wird dann die aus Sicht des Planners/Optimizers beste Option ausgesucht. Per Default z.B.macht PostgreSQL das mit bis zu 8 Joins (join_collapse_limit), reicht das nicht, gibt es einen generischen optimizer.
Siehe auch https://www.postgresql.org/docs/curr...FIG-QUERY-GEQO Abschnitt 19.7.3.

Achtung: MySQL hat all das nicht, das ballert meines Wissens nach einfach drauf los.

[Meister1900]

Hmm, wie jetzt? Steht doch gleich am Anfang "WHERE co = :iso" :iso ist nur nen Platzhalter der im Argumenten-Array den gleichen Namen haben muss und dann auf die spalte "co" (Country) angewendet wird.
Oder gibts da noch ne Methode die mir entgangen ist, bzgl. index?

Mach dich mal schlau was ein INDEX ist, z.B. hier

[protestix]

Umkreissuche wird am einfachsten mit den GIS Funktionen umgesetzt, oder du schaust dir die Formel dazu an unter http://opengeodb.giswiki.org/wiki/Op...-_Umkreissuche

[hellbringer]

Formeln braucht man da gar keine. Das kann schon alles die Datenbank selber und in der Regel auch besser.