Like oder nicht like bei mysql

Moin

Ein Kunmpel ist da auf ein kleines Problem mit mysql gestossen (FC3, Basisinstallation):

Diese 2 Commandos suchen (nach meinem Verständniss von SQL) die gleichen Zeilen raus:

1. select count(id) from result where name like 'H1\_0059.9\_\_%';

2. select count(id) from result where name\>'H1\_0059.9\_\_' and name

Das Ergebniss auf den Testdaten ist gleich. Die 2. Variante ist aber viel langsamer als die erste. Grund:


    mysql\> explain select count(id) from result where name like 'H1\_0059.9\_\_%';
    +----+-------------+--------+-------+---------------+------+---------+------+-------+--------------------------+
    | id | select\_type | table | type | possible\_keys | key | key\_len | ref | rows | Extra |
    +----+-------------+--------+-------+---------------+------+---------+------+-------+--------------------------+
    | 1 | SIMPLE | result | range | name | name | 254 | NULL | 53967 | Using where; Using index |
    +----+-------------+--------+-------+---------------+------+---------+------+-------+--------------------------+



Wogegen:


    mysql\> explain select count(id) from result where name\>'H1\_0059.9\_\_' and name
    
    Wieso durchsucht das eine Statment 53967 rows, das andere aber "nur" 1440 ? Müste der optimierer das nicht rausfischen ?
    
    cu

Hallo,

Diese 2 Commandos suchen (nach meinem Verständniss von SQL)
die gleichen Zeilen raus:

Bist Du sicher? Geht das überhaupt, ‚‘ mit Wildcards?
Werden da nicht die Unterstriche als solche genommen? Würde ich jedenfalls erwarten. Aber vielleicht ist mysql da anders als Oracle.

cu, muzel

Hallo pumpkin!

Vorweg gleich mal: Ich habe eine mySQL-Installation schon einmal aus der Ferne gesehen, weiter ist meine Erfahrung damit noch nicht gediehen, ich schliesse also eher aus meiner Oracle-Erfahrung.

Diese 2 Commandos suchen (nach meinem Verständniss von SQL)
die gleichen Zeilen raus:

  1. select count(id) from result where name like
    ‚H1_0059.9__%‘;
  2. select count(id) from result
    where name>‚H1_0059.9__‘ and name nicht). Das würde auch erklären, warum da eine unterschiedliche Anzahl von Rows durchsucht wird.

Das Ergebniss auf den Testdaten ist gleich. Die 2. Variante
ist aber viel langsamer als die erste. Grund:
mysql> explain select count(id) from result where name
like ‚H1_0059.9__%‘;
[…]

Äääähm, abgesehen davon, dass ich mit mySQL-Plänen keine Erfahrung habe, finde ich die Ausgabe etwas dürftig: Gibt’s eine Möglichkeit herauszufinden, wie mySQL auf die Indices zugreift, bzw. wie er zu seinen Zahlen kommt? Vielleicht wäre das hilfreich. Ausserdem finde ich es seltsam, dass es schneller läuft 53967 Rows zu checken als derer 1440…

Wieso durchsucht das eine Statment 53967 rows, das andere aber
„nur“ 1440 ? Müste der optimierer das nicht rausfischen ?

Ich halte das zweite Statement für eine (leichte, aber doch) Vergewaltigung von SQL. Vor allem angesichts der Tatsache, dass du dich da auf eine bestimmte Sortierreihenfolge verlässt. Meine Prämisse: Let the Optimizer do its Work (ausser, wenn ich weiss dass er falsch liegt :wink:).

Gruß
Martin

Hallo,

Diese 2 Commandos suchen (nach meinem Verständniss von SQL)
die gleichen Zeilen raus:

Bist Du sicher? Geht das überhaupt, ‚‘ mit
Wildcards?
Werden da nicht die Unterstriche als solche genommen?

Nein, mysql nimmt die _-Zeichen auch da als 1 Zeichen-Wildcard, genau wie bei like. Das war’s nicht.

cu

Moin

Ich vermute mal du hast recht, allerdings nur, wenn folgendes
zutrifft: ‚~‘ liegt in der aktuellen Sortierung nach jedem
anderen Zeichen

Ja, das ist so bei mysql.

Weiters: Unter Oracle ist ‚%‘ eine Wildcard für ein oder
mehrere beliebige Zeichen, ‚_‘ eine Wildcard für genau ein
beliebiges Zeichen.

gilt auch für mysql.

(Wildcards werden
bei LIKE interpretiert, bei nicht).

Da stimmten die 2 nicht mehr überein: mysql nimmt auch da _ als Wildcard.

Äääähm, abgesehen davon, dass ich mit mySQL-Plänen keine
Erfahrung habe, finde ich die Ausgabe etwas dürftig: Gibt’s
eine Möglichkeit herauszufinden, wie mySQL auf die
Indices zugreift, bzw. wie er zu seinen Zahlen kommt?

Leider nein, jedenfalls nicht auf der Version. Müsste mal die debug-version installieren…

Ich halte das zweite Statement für eine (leichte, aber doch)
Vergewaltigung von SQL.

*g*… das sagen viele Leute zu den Statment in dem Programm.

Danke.

Ich halte das zweite Statement für eine (leichte, aber doch)
Vergewaltigung von SQL.

*g*… das sagen viele Leute zu den Statment in dem Programm.

Thou shalt not lie to the optimizer, for verily its perception and judgment oft exceed thine.

SCNR
Martin