mysql und PHP (wieder)

Re(13): mysql und PHP (wieder)

gepeinigter_aon_neukunde — Wed, 10 Aug 2005 16:58:32 GMT

Das ist nicht so wild...
Die Statement-Parser sind IMHO via flex/bison geschrieben - da ist das extrahieren der Infos net sooo schlimm. Klar steigt der Parse-Aufwand etwas an (minimst) - aber dazu legt er sich ja die geparsten Statements in einem eigenen Buffer ab... Damit er sie bei einem nächsten mal nicht nochmal Parsen muß.

Viel genialer find' ich die Postgres beim allgemeinen Optimizer-lauf...

Oracle verwendet ja immer cost-based und ab einer gewissen Tabellenanzahl fällt's zurück auf rulebased.

Postgres:
Dursucht bis zu konfigurierbaren Tiefe (AFAIK default 11) alle Variationen - wenn's mehr Tabellen sind: Plan B nicht cost-based sondern genetische algorithmen, um zumindest schnell zu einer sehr guten Lösung zu kommen...

So oder so, das Hirnschmalz, das in Datenbanken geflossen ist, ist so oder so phantastisch... Ich finde ja sogar schon die Transaktionsmodelle faszinierend (bin leicht zu begeistern )

Re(12): mysql und PHP (wieder)

Ingenico — Wed, 10 Aug 2005 16:52:45 GMT

Denn anstatt im Index die Werte mit Pointer auf die Rows wegzuspeichern, muß
er nur noch einen Zwischenschritt machen: Anstatt die Werte selbst zu
speichern, speichert er die Funktionsergebnisse der Werte.

Ja sicha!

Mir geht es darum, welche wahnsinns-mörder-irrsinns-DB-Engine kann eine komplexe SQL-Query derart auflösen, daß nicht nur das Statement zerlegt und in Indizierte Komponeneten geteilt werden, sondern auch noch (und dies auf intellliegente Weise) die Expression der Index-Defintion (über function-based-expressions) mit integrieren kann.

Spürst was ich denk?

Re(11): mysql und PHP (wieder)

gepeinigter_aon_neukunde — Wed, 10 Aug 2005 16:43:20 GMT

Sorry...

Ich habe eine Tabelle BUBU angelegt
=# CREATE TABLE bubu ( a varchar(20) );
CREATE TABLE

Habe einen Wert reingelegt:
x=# INSERT INTO bubu values('jsfkf');
INSERT 17145 1

Einen Function based Index(upper) angelegt:
x=# CREATE INDEX xxx on bubu(upper(a));
CREATE INDEX

Laß mir anzeigen, wie der Optimizer das SELECT auflöst
x=# EXPLAIN SELECT * from bubu where upper(a) = 'X';
                     QUERY PLAN
-----------------------------------------------------
Seq Scan on bubu  (cost=0.00..1.01 rows=1 width=24)
   Filter: (upper((a)::text) = 'X'::text)
(2 Zeilen)

Aaah - Sequentieller Scan, net Index. Logisch, da sowenig Werte drin sind.
Also hab ich ihm verboten, sequentielle Scans durchzuführen

x=# set enable_seqscan = off;
SET

Und nochmal die Query
x=# EXPLAIN SELECT * from bubu where upper(a) = 'X';
                           QUERY PLAN
-----------------------------------------------------------------
Index Scan using xxx on bubu  (cost=0.00..4.68 rows=1 width=24)
   Index Cond: (upper((a)::text) = 'X'::text)
(2 Zeilen)

Wir sehen - er macht einen INDEXscan.
Klappt dasselbe mit Like ?

x=# EXPLAIN SELECT * from bubu where upper(a) like 'X%';
                                     QUERY PLAN
------------------------------------------------------------------------------------
Index Scan using xxx on bubu  (cost=0.00..4.68 rows=1 width=24)
   Index Cond: ((upper((a)::text) >= 'X'::text) AND (upper((a)::text) < 'Y'::text))
   Filter: (upper((a)::text) ~~ 'X%'::text)
(3 Zeilen)

Ja.

Aus Sicht des RDBMS ist ein funtion-based Index primitiv zu implementieren, wenn du schon indizes hast...

Denn anstatt im Index die Werte mit Pointer auf die Rows wegzuspeichern, muß er nur noch einen Zwischenschritt machen: Anstatt die Werte selbst zu speichern, speichert er die Funktionsergebnisse der Werte.

Daher dauert das Indizieren länger, und bei jedem Insert muß er zusätzlich die Funktionsergebnisse berechnen... Macht also Primär bei Tabellen mit viel mehr Queries als Inserts Sinn - aber das gilt ja für alle Indizes. Deine DB wird's wohl intern genauso lösen.

Re(10): mysql und PHP (wieder)

Ingenico — Wed, 10 Aug 2005 16:37:29 GMT

Tut mir leid, aber ich verstehe hier nur "bubu"!
Du hast eine Table mit einem Record erstellt?

Naja - wie auch immer, ich weiß daß Indizies auch Funktions-Basierend aufgebaut werden können. Wie diese über den DB-Server sinnvoll aufgelöst werden können, wenn die Query mal komplexer wird, und die Syntax zwar auf einen funktionsbasierenden Index refernziert, aber mit anderen Konditionen verknüpft werden, kann ich mir nimma vorstellen.

Den Ansatz mit function based indizes...

gepeinigter_aon_neukunde — Wed, 10 Aug 2005 16:24:50 GMT

Mag ich eh sehr... Dadurch, daß er so generell ist - die verwende ich echt öfter.

EDIT:
Scheint so, als ob sich doch mehr getan hat als Du verarbeiten willst, hehe

EDIT²:
Wobei function based Indizes zwar immer (PostgreSQL und Oracle) auch bei selbstdefinierten Funktionen klappen - aber nur, wenn sie IMMUTABLE sind, d.h. wenn bei derselben Eingabe dieselbe Ausgabe resultiert. Dabei baut er halt den Index statt über die Werte über die Funktionsergebnisse der Werte - aus Sicht der DB eine sehr primitive Ergänzung, für den Benutzer aber extrem praktisch.

Den Ansatz mit function based indizes...

gepeinigter_aon_neukunde — Wed, 10 Aug 2005 16:24:50 GMT

Mag ich eh sehr... Dadurch, daß er so generell ist - die verwende ich echt öfter.

EDIT:
Scheint so, als ob sich doch mehr getan hat als Du verarbeiten willst, hehe

Den Ansatz mit function based indizes...

gepeinigter_aon_neukunde — Wed, 10 Aug 2005 16:24:50 GMT

Mag ich eh sehr... Dadurch, daß er so generell ist - die verwende ich echt öfter.

Re(9): mysql und PHP (wieder)

gepeinigter_aon_neukunde — Wed, 10 Aug 2005 16:23:59 GMT

Wie gesagt... Mit function based Index schon...

Beweis:


=# CREATE TABLE bubu ( a varchar(20) );
CREATE TABLE
x=# INSERT INTO bubu values('jsfkf');
INSERT 17145 1
x=# CREATE INDEX xxx on bubu(upper(a));
CREATE INDEX
x=# EXPLAIN SELECT * from bubu where upper(a) = 'X';
                     QUERY PLAN
-----------------------------------------------------
 Seq Scan on bubu  (cost=0.00..1.01 rows=1 width=24)
   Filter: (upper((a)::text) = 'X'::text)
(2 Zeilen)

x=# set enable_seqscan = off;
SET
x=# EXPLAIN SELECT * from bubu where upper(a) = 'X';
                           QUERY PLAN
-----------------------------------------------------------------
 Index Scan using xxx on bubu  (cost=0.00..4.68 rows=1 width=24)
   Index Cond: (upper((a)::text) = 'X'::text)
(2 Zeilen)

x=# EXPLAIN SELECT * from bubu where upper(a) like 'X%';
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Index Scan using xxx on bubu  (cost=0.00..4.68 rows=1 width=24)
   Index Cond: ((upper((a)::text) >= 'X'::text) AND (upper((a)::text) < 'Y'::text))
   Filter: (upper((a)::text) ~~ 'X%'::text)
(3 Zeilen)

Re(8): mysql und PHP (wieder)

Ingenico — Wed, 10 Aug 2005 16:14:40 GMT

Danke! Daß Du mir mein naives Weltbild bezüglich Indizierung nicht ruiniert hast.
Ich dachte schon, hier hätte sich mehr getan als ich geistig aufnehmen könnte

Es gibt ja DB´s (und ich arbeite mit einer solchen), wo die zu indizierenden Felder vom Typ "char" innerhalb der Index-Kette jeweils als "case-sensitive" / "case-insensitive" gekennzeichnet werden können. Daher hab ich mir bei SQL-Abfragen nie wirklich Gedanken darüber gemacht.
Aber ich war mir sicher, daß Funktionen innerhalb einer Query, die sich auf DB-Felder beziehen, nie indiziert ablaufen können.

Re(7): mysql und PHP (wieder)

gepeinigter_aon_neukunde — Wed, 10 Aug 2005 15:52:40 GMT

AUTSCH! Ich bin ein /DILLO/.
Ich war gedanklich völlig falsch und bei einer Abfrage wie

SELECT xyz FROM tabelle WHERE UPPER(benutzereingabe) = feld

- einfach weil ich das oft brauch .

Du hast Recht, im Normalfall kann er dann so keinen Index verwenden - außer du hast einen Function based Index wie


CREATE INDEX idx ON tabelle(UPPER(feld))

Dann natürlich schon (PostgreSQL-Syntax)

Re(6): mysql und PHP (wieder)

Ingenico — Wed, 10 Aug 2005 10:50:16 GMT

Und wennst hast ...

(like 'Mustermann%' or like 'mustermann%' or like 'MUSTERMANN%' or like 'MusterMann%' or ........)

.. dann wirds aber ein bisserl öd!

Und vor allem, was machst wenn der Vergleich nicht mit einer Konstante, sondern einer Variable erfolgt?

Re(6): mysql und PHP (wieder)

Da Horstl — Wed, 10 Aug 2005 10:24:31 GMT

Hallo und sorry, dass ich mich da Reinhänge.

Aber was ist, wenn ich jetzt einen längeren String vergleichen möchte und nicht nur einen Buchstaben?

Re(5): mysql und PHP (wieder)

Rennegade — Wed, 10 Aug 2005 09:55:17 GMT

kannst da aber eh sparen mit
... (like 'a%' or like 'A%' )

is sicher besser und schneller als eine columnfunction.

Re(4): mysql und PHP (wieder)

Ingenico — Wed, 10 Aug 2005 09:45:39 GMT

problematischer is es schon wenn du mit irgend welchen funktionen auf ne
column losgehst;

Genau darum geht es ja! (upper)

Re(3): mysql und PHP (wieder)

Rennegade — Wed, 10 Aug 2005 08:16:10 GMT

sicherlich, sonst könntest die datenbank gleich scmeissen problematischer is es schon wenn du mit irgend welchen funktionen auf ne column losgehst; da streiken auch die meisten großen datenbanken.

Re(6): mysql und PHP (wieder)

Ingenico — Wed, 10 Aug 2005 07:37:13 GMT

Das UPPER() wird nur einmal ausgewertet - und über das Ergebnis der Index-Scan
(eben nicht ein Full-Table-Scan) gemacht.

Du hast die "upper()"-Function ja nicht auf den zu vergleichenden Wert, sondern auf das DB-Feld angewendet.
Wennst jetzt 2Mio Records hast, müssen doch zwangsweise 2Mio Felder via "upper()" umgerechnet und danach vergleichen werden um auf das Ergebnis zu kommen.
Ich selber verwende diese Art des vergleiches ja nie. Da bei meiner DB die Indizies automatisch auf Kleinbuchstaben umgerechnet werden (nicht die Felder ).

Re(5): mysql und PHP (wieder)

gepeinigter_aon_neukunde — Tue, 09 Aug 2005 19:16:20 GMT

Das UPPER() wird nur einmal ausgewertet - und über das Ergebnis der Index-Scan (eben nicht ein Full-Table-Scan) gemacht.

Da bin ich mir bei der PostgreSQL 100pro sicher (habe selbst öfter eigene Datentypen plus dazugehörige Indizes für die Firma entwickelt) und bei Oracle ebenso (Optimizer-Ausgabe kontrolliert).

Re(4): mysql und PHP (wieder)

Ingenico — Tue, 09 Aug 2005 17:45:24 GMT

Meine Bedenken galten eher der "upper()" als der "like"-Angabe

Re(3): mysql und PHP (wieder)

gepeinigter_aon_neukunde — Tue, 09 Aug 2005 17:26:45 GMT

Ich kenn die MySQL auch net

Bei "richtigen" DBs wie Oracle, DB2 und PostgreSQL kommt bei
LIKE aber sehr wohl ein Index zur Anwendung, wenn möglich und sinnvoll (Optimizer-Entscheidung).

Also LIKE 'ABC%' kann index Nutzen, LIKE '%ABC' net.

Ein beliebter Fehler [auch in prof. Programmen] ist ja, daß wer
WHERE SUBSTR(feld,1,3) = 'ABC'
schreibt... anstelle von
WHERE feld LIKE 'ABC%'.

Denn ersteres kann niemals den Index nutzen, zweiteres schon...

Re(2): mysql und PHP (wieder)

Ingenico — Mon, 08 Aug 2005 18:06:16 GMT

Ich kenn ja "mysql" nicht, aber würde bei einem solchen SQL-Statement überhaupt noch ein Index Anwendung finden?

Re: mysql und PHP (wieder)

gepeinigter_aon_neukunde — Sun, 07 Aug 2005 18:53:41 GMT

Wenn du alle a's willst - also groß und klein:

SELECT * FROM tabelle WHERE UPPER(feld) LIKE 'A%';
wenn's aber nur die mit kleinem a sein sollen:
SELECT * FROM tabelle WHERE feld LIKE 'a%';

Re(5): mysql und PHP (wieder)

Somnatic — Sun, 07 Aug 2005 16:28:25 GMT

probiers aus

Re(3): mysql und PHP (wieder)

Somnatic — Sun, 07 Aug 2005 16:20:41 GMT

kA
würde mal auf nein tippen (kann aber auch ja sein )

Re: mysql und PHP (wieder)

Somnatic — Sun, 07 Aug 2005 16:07:37 GMT

a%

google -> wildcard mysql