Fehlerhafte Tabelle

Hi NG!

Ich hab eine Tabelle (MyISAM) die ein Feld abrechnung (char (1))
enthält. Diese Tabelle enthält z.Zt. nur 1 Datensatz, bei dem in diesem
Feld '1' drinsteht.

Mache ich nun einen Select auf diese Tabelle passiert etwas komisches:

select * from tabelle where abrechnung = '1'
liefert 1 Datensatz

select * from tabelle where abrechnung = '0'
liefert keine Datenmenge, weder Felder noch Datensätze, aber auch keinen
Fehler

explain select * from tabelle where abrechnung = '0'
liefert folgende Meldung:
"Impossible WHERE noticed after reading const tables"

Jetzt hab ich das auch mit anderen Werten im Feld abrechnung getestet,
und es ist immer dasselbe: frage ich im select nach dem Wert der in dem
Feld steht klappt es, frage ich nach beliebigen anderen Werten kommt der
Fehler.

Versuche ich einen Dump der Tabelle mit HeidiSQL zu erstellen hängt sich
das Programm auf. Ein Dump mit mysqldump klappt allerdings problemlos.

Offenbar ist irgendwas fehlerhaft an der Tabelle. Interessant ist aber
das "check table tabelle" keinen Fehler anzeigt.

Hat jemand eine Idee was mit meiner Tabelle los ist? Oder was ich noch
prüfen kann?

MySQL 5.0.27-com, WinXP SP2

MfG Thomas.

Re: Fehlerhafte Tabelle

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Fehlerhafte Tabelle

Am 29.08.2007 11:39 schrieb Borsdorf, Thomas:
> Hi NG!
>
> Ich hab eine Tabelle (MyISAM) die ein Feld abrechnung (char (1))
> enthält. Diese Tabelle enthält z.Zt. nur 1 Datensatz, bei dem in diesem
> Feld '1' drinsteht.
>
> Mache ich nun einen Select auf diese Tabelle passiert etwas komisches:
>
> select * from tabelle where abrechnung = '1'
> liefert 1 Datensatz
>
> select * from tabelle where abrechnung = '0'
> liefert keine Datenmenge, weder Felder noch Datensätze, aber auch keinen
> Fehler
>

Warum auch? Es gibt keine Daten, die dazu passen, also gibt's auch
nichts zu liefern.

> explain select * from tabelle where abrechnung = '0'
> liefert folgende Meldung:
> "Impossible WHERE noticed after reading const tables"
>

Das ist keine "Meldung", das ist einfach nur das *Ergebnis* von
EXPLAIN. Und wenn Du das komplette EXPLAIN hier gepostet hättest,
statt Prosa samt Deiner Interpretation zu liefern, hätte man es auch
sofort sehen können.

Lies die Dokumentation bei dev.mysql.com/doc.

> Jetzt hab ich das auch mit anderen Werten im Feld abrechnung getestet,
> und es ist immer dasselbe: frage ich im select nach dem Wert der in dem
> Feld steht klappt es, frage ich nach beliebigen anderen Werten kommt der
> Fehler.
>

Da kommt kein Fehler.

> Versuche ich einen Dump der Tabelle mit HeidiSQL zu erstellen hängt sich
> das Programm auf. Ein Dump mit mysqldump klappt allerdings problemlos.
>

HeidiSQL ist hier OT.

> Offenbar ist irgendwas fehlerhaft an der Tabelle.
>
Quatsch

> Hat jemand eine Idee was mit meiner Tabelle los ist? Oder was ich noch
> prüfen kann?

Ja. Du kannst *erst* die Dokumentation lesen. Du kannst den
Unterschied zwischen "Fehlermeldung" und "Ausgabe" verstehen.


--
Christian

Re: Fehlerhafte Tabelle

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Fehlerhafte Tabelle

Christian Kirsch schrieb:
> Warum auch? Es gibt keine Daten, die dazu passen, also gibt's auch
> nichts zu liefern.

Falsch!
JEDE Datenbank, auch MySQL, liefert in einem solchen Fall ein leeres
Dataset, welches zwar keine Daten aber zumindest Felder enthält! Und
wenn du mein Posting richtig liest passiert eben das NICHT!

Und es ist NUR diese eine Tabelle bei der das so passiert!

>> Offenbar ist irgendwas fehlerhaft an der Tabelle.
> Quatsch

Und wieso hab ich dann bei dieser Tabelle anderes Verhalten als bei
allen anderen Tabellen?

MfG Thomas.

Re: Fehlerhafte Tabelle

Am 29.08.2007 12:06 schrieb Andreas Kretschmer:
> begin Christian Kirsch schrieb:
>>> select * from tabelle where abrechnung = '0'
>>> liefert keine Datenmenge, weder Felder noch Datensätze, aber auch keinen
>>> Fehler
>>>
>> Warum auch? Es gibt keine Daten, die dazu passen, also gibt's auch
>> nichts zu liefern.
>>
>>> explain select * from tabelle where abrechnung = '0'
>>> liefert folgende Meldung:
>>> "Impossible WHERE noticed after reading const tables"
>>>
>> Das ist keine "Meldung", das ist einfach nur das *Ergebnis* von
>> EXPLAIN.
>
> Was natürlich reichlich sinnfrei ist, denn immerhin hat es eine
> Bedingung zu prüfen und diese liefert halt auch was zurück. Das SQL wird
> ja auch ausgeführt und nögelt nicht rum, also hat der Planner wohl auch
> sich überlegt, wie er die Abfrage ausführt.
>

Was stört dich? Der Text ist im Handbuch erklärt, er bedeutet halt
nur, dass die WHERE-Bedingung für keinen Datensatz zutrifft.

--
Christian

Re: Fehlerhafte Tabelle

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Fehlerhafte Tabelle

Am 29.08.2007 12:42 schrieb Andreas Kretschmer:
> begin Christian Kirsch schrieb:

>> Was stört dich? Der Text ist im Handbuch erklärt, er bedeutet halt
>> nur, dass die WHERE-Bedingung für keinen Datensatz zutrifft.
>
> Mich stört (nein, nicht wirklich, trifft mich ja nicht) daran, daß das
> EXPLAIN eine IMHO dumme Meldung ausgibt. Das SELECT könnte ja auch
> umfangreicher sein, möglicherweise weiß man vorher nicht, ob es
> Datensätze geben wird. Oder anders formuliert: Das SELECT wird ja auch
> ausgeführt, also ist dazu ein Ausführungsplan nötig. Und diesen sollte
> EXPLAIN anzeigen. Dazu ist es bestimmt. Auch bei Mondschein und Ebbe.
>

Ja, und? Das *ist* der Ausführungsplan: Die WHERE-Bedingung trifft auf
keinen Datensatz zu ("Impossible"). Also passiert nix. So what?

> Oder noch anders formuliert: man findet im slow_query_log ein Select,
> welches sehr lange braucht.
> Man will es optimieren bzw. analysieren.
> Und anstatt eines Ausführungsplanes bekommt man eine unsinnige Meldung,
> denn ich gehe davon aus, daß MySQL bei komplexen Querys, die kein
> Resultat liefern, dennoch das Query an sich ausführen und MySQL kein
> /dev/glaskugel nach der Anzahl der Datensätze befragen kann.

Vielleicht doch ausnahmsweise mal ein Blick in dev.mysql.com/doc,
Kapitel 6 (bei Version 5.1), Unterabschnitt zum Thema "EXPLAIN".
>
> Aber hey, dafür hat MySQL so geile Dinge wie vorn mit Nullen aufgefüllte
> numerische Datentypen...
>
Sach ich doch. Das ist mal wirklich innovativ - und die Welt braucht
es, wie wir wissen :-)

--
Christian

Re: Fehlerhafte Tabelle

Borsdorf, Thomas schrieb:

> Ich hab eine Tabelle (MyISAM) die ein Feld abrechnung (char (1))
> enthält. Diese Tabelle enthält z.Zt. nur 1 Datensatz, bei dem in diesem
> Feld '1' drinsteht.
>
> Mache ich nun einen Select auf diese Tabelle passiert etwas komisches:
>
> select * from tabelle where abrechnung = '1'
> liefert 1 Datensatz

Was ist daran komisch?

> select * from tabelle where abrechnung = '0'
> liefert keine Datenmenge, weder Felder noch Datensätze, aber auch keinen
> Fehler

Was ist daran komisch?

> explain select * from tabelle where abrechnung = '0'
> liefert folgende Meldung:
> "Impossible WHERE noticed after reading const tables"

Kluges EXPLAIN. Es hat festgestellt, dass die WHERE-Bedingung nie
eintreten kann. Was ist daran komisch?

> Jetzt hab ich das auch mit anderen Werten im Feld abrechnung getestet,
> und es ist immer dasselbe: frage ich im select nach dem Wert der in dem
> Feld steht klappt es, frage ich nach beliebigen anderen Werten kommt der
> Fehler.

Welcher Fehler? Ich sehe keinen Fehler. Du fragst nach einem Wert, der
vorhanden ist, und bekommst ihn ausgegeben. Du fragst nach einem Wert,
der nicht vorhanden ist, und bekommst nichts ausgegeben. Ist doch alles
in bester Ordnung.

> Versuche ich einen Dump der Tabelle mit HeidiSQL zu erstellen hängt sich
> das Programm auf. Ein Dump mit mysqldump klappt allerdings problemlos.

Was hat HeidiSQL mit MySQL zu tun?

> Offenbar ist irgendwas fehlerhaft an der Tabelle. Interessant ist aber
> das "check table tabelle" keinen Fehler anzeigt.

Den Ergebnissen nach zu urteilen, ist Deine Tabelle vollkommen in Ordnung.

> Hat jemand eine Idee was mit meiner Tabelle los ist? Oder was ich noch
> prüfen kann?

Da gibt es nichts zu prüfen. Es ist alles in Ordnung.

Gruß. Claus

Re: Fehlerhafte Tabelle

Andreas Kretschmer wrote:
> begin Christian Kirsch schrieb:
>>> select * from tabelle where rechnung = '0'
>>> liefert keine Datenmenge, weder Felder noch Datensätze, aber auch keinen
>>> Fehler
>>>
>>
>> Warum auch? Es gibt keine Daten, die dazu passen, also gibt's auch
>> nichts zu liefern.
>>
>>> explain select * from tabelle where abrechnung = '0'
>>> liefert folgende Meldung:
>>> "Impossible WHERE noticed after reading const tables"
>>>
>>
>> Das ist keine "Meldung", das ist einfach nur das *Ergebnis* von
>> EXPLAIN.
>
> Was natürlich reichlich sinnfrei ist, denn immerhin hat es eine
> Bedingung zu prüfen und diese liefert halt auch was zurück. Das SQL wird
> ja auch ausgeführt

Nein. Es wird eben nichts ausgeführt. In einer sehr frühen Phase des
Planner/Optimizer Laufs wurde festgestellt, daß diese Query eine
unmögliche Bedingung im WHERE enthält und daß es deswegen unnötig ist,
sich überhaupt Gedanken um einen Ausführungsplan zu machen. Statt
dessen wird sofort ein leeres Ergebnis geliefert und fertig.

[postgres gesnipt]

Wie arm bist du eigentlich, hier immer mit einem fremden Schwanz
angeben zu müssen? (schließlich ist PostgreSQL ja nicht auf deinem Mist
gewachsen)


XL

Re: Fehlerhafte Tabelle

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Fehlerhafte Tabelle

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Fehlerhafte Tabelle

On Wed, 29 Aug 2007 12:06:09 +0200, Andreas Kretschmer wrote:

> begin Christian Kirsch schrieb:
>>> select * from tabelle where abrechnung = '0' liefert keine Datenmenge,
>>> weder Felder noch Datensätze, aber auch keinen Fehler
>>>
>>>
>> Warum auch? Es gibt keine Daten, die dazu passen, also gibt's auch
>> nichts zu liefern.
>>
>>> explain select * from tabelle where abrechnung = '0' liefert folgende
>>> Meldung:
>>> "Impossible WHERE noticed after reading const tables"
>>>
>>>
>> Das ist keine "Meldung", das ist einfach nur das *Ergebnis* von
>> EXPLAIN.
>
> Was natürlich reichlich sinnfrei ist, denn immerhin hat es eine
> Bedingung zu prüfen und diese liefert halt auch was zurück. Das SQL wird
> ja auch ausgeführt und nögelt nicht rum, also hat der Planner wohl auch
> sich überlegt, wie er die Abfrage ausführt.

Die Meldung tritt nur für "const" Tabellen auf. Der Tabellentyp existiert
nur für den Optimizer und es handelt sich entweder um eine Tabelle, die
nur eine Zeile enthält, oder eine Tabelle aus der Anhand der konstanten
Bedingungen der Anfrage max. eine Zeile gefunden werden kann (d.h. ein
Wert für einen vollständigen Superschlüssel wurde als Bedingung gegeben).

Ob es sich um eine solche Abfrage für die jeweiligen Tabellen handelt,
kann der Optimizer bereits vorab anhand der Indexdefinitionen feststellen
und liest dann die entsprechende Zeile schon vor der eigentlichen
Ausführung der Anfrage, um die jeweiligen Werte als Konstanten in die
Anfrage einzubauen und zur Optimierung zu benutzen.

Das man die Kosten für die Feststellung, dass halt in diesem Fall keine
Zeile gelesen werden konnte, wie immer raten muss ist zwar unschön, aber
sinnfrei ist die Meldung nicht.

Beispiel:
mysql> create table x1 (a int, b int, primary key (a));
Query OK, 0 rows affected (0.02 sec)

mysql> create table x2 (b int, c int);
Query OK, 0 rows affected (0.03 sec)

mysql> insert into x1 values (1,2), (2,3);
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0

mysql> insert into x2 values (2,5), (3,8);
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0

mysql> EXPLAIN EXTENDED SELECT * FROM x1 NATURAL JOIN x2 WHERE x1.a = 1\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: x1
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: const
rows: 1
Extra:
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: x2
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2
Extra: Using where
2 rows in set, 1 warning (0.00 sec)

Note (Code 1003): select '2' AS `b`,'1' AS `a`,`test`.`x2`.`c` AS `c`
from `test`.`x1` join `test`.`x2` where ((`test`.`x2`.`b` = '2'))

Wie man sieht wurde bereits während der Optimierungsphase der Wert 2 aus
der einen Zeile in x1 in die Anfrage übernommen, obwohl diese Konstante
in der ursprünglichen Anfrage _nicht_ vorkam, sondern anhand der "const"
Optimierung ermittelt wurde.

mysql> EXPLAIN EXTENDED SELECT * FROM x1 NATURAL JOIN x2 WHERE x1.a = 5\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: NULL
type: NULL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: NULL
Extra: Impossible WHERE noticed after reading const tables
1 row in set, 1 warning (0.00 sec)

Note (Code 1003): select '0' AS `b`,'0' AS `a`,`test`.`x2`.`c` AS `c`
from `test`.`x1` join `test`.`x2` where 0

Hier wurde direkt ein "where 0" in die optimierte Abfrage gesetzt, und
die Optimierung abgebrochen, da bereits bekannt ist, dass nichts gefunden
werden kann.

Warum da allerdings der ganze Join drinbleibt ist mir schleierhaft, nen
"SELECT 0 WHERE 0" hätte es ja auch getan ;-)

Björn

Re: Fehlerhafte Tabelle

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Fehlerhafte Tabelle

Andreas Kretschmer wrote:
> begin Axel Schwenke schrieb:
>> Nein. Es wird eben nichts ausgeführt. In einer sehr frühen Phase des
>> Planner/Optimizer Laufs wurde festgestellt, daß diese Query eine
>> unmögliche Bedingung im WHERE enthält und daß es deswegen unnötig ist,
>
> Ja. MySQL ist echt clever. Es weiss schon vor Abfrage einer Tabelle, was
> als Resultat bei rauskommt.

Das ist keine Magie. SELECT ... WHERE 0=1 liefert *immer* ein leeres
Ergebnis. Und wenn da noch ein fetter JOIN drin steht, ist es auch
absolut wünschenswert, das zu erkennen *bevor* man sich Gedanken macht
in welcher Reihenfolge man die Tabellen joint.

>> sich überhaupt Gedanken um einen Ausführungsplan zu machen.
>
> Genau. Das ist ja auch echt komplex. Vor allem wenn ja schon das
> Resultat vorher bekannt ist. Clever. Kann MySQL mir einklich die
> Lottozahlen für nächste Woche sagen?

Kannst du eigentlich diskutieren?

>> Statt dessen wird sofort ein leeres Ergebnis geliefert und fertig.
>
> Das Problem ist nur, das ich von einem EXPLAIN kein leeres Ergebniss
> erwarte.

Ach was. Kannst du lesen?

Explain liefert mitnichten ein leeres Ergebnis:

mysql> explain select * from t1 where 0=1\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: NULL
type: NULL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: NULL
Extra: Impossible WHERE


>> Wie arm bist du eigentlich, hier immer mit einem fremden Schwanz
>> angeben zu müssen? (schließlich ist PostgreSQL ja nicht auf deinem Mist
>> gewachsen)
>
> Wie arm bist Du, nicht über den eigenen Tellerrand schauen zu können und
> sehen zu können, daß es für eigene Probleme woanders vielleicht bessere
> Lösungen gibt?

Wie kommst du eigentlich darauf, daß ich das nicht tue? Ich bin es nur
leid, daß du Kasper hier *jedes* *verdammte* Mal eine PostgreSQL-Lösung
präsentierst, wenn eine MySQL-Frage gestellt war. Meistens garniert mit
einem Hinweis, daß das in MySQL vielleicht auch geht, du aber absolut
keine Ahnung hast, ob oder wie. Muß ich Dieter Nuhr zitieren?

> Ist MySQL einklich auf Deinem Mist gewachsen?

Gehe ich unter PostgreSQLer trollen?


XL

Re: Fehlerhafte Tabelle

Andreas Kretschmer schrieb:

> Ja. MySQL ist echt clever. Es weiss schon vor Abfrage einer Tabelle, was
> als Resultat bei rauskommt.

Ja, Echt innovativ. Nennt sich "Index". Neumodisches Zeugs da...


> Genau. Das ist ja auch echt komplex. Vor allem wenn ja schon das
> Resultat vorher bekannt ist. Clever. Kann MySQL mir einklich die
> Lottozahlen für nächste Woche sagen?

Wenn sie in einem Index stehen, ja.


> Wie arm bist Du, nicht über den eigenen Tellerrand schauen zu können und
> sehen zu können, daß es für eigene Probleme woanders vielleicht bessere
> Lösungen gibt?

Was ist am Weglassen einer Optimierung zu einem frühen Zeitpunkt besser?


Thomas

Re: Fehlerhafte Tabelle

Hallo,

Christian Kirsch wrote:
> Am 29.08.2007 12:42 schrieb Andreas Kretschmer:
>> begin Christian Kirsch schrieb:
>
>>> Was stört dich? Der Text ist im Handbuch erklärt, er bedeutet halt
>>> nur, dass die WHERE-Bedingung für keinen Datensatz zutrifft.
>>
>> Mich stört (nein, nicht wirklich, trifft mich ja nicht) daran, daß das
>> EXPLAIN eine IMHO dumme Meldung ausgibt. Das SELECT könnte ja auch
>> umfangreicher sein, möglicherweise weiß man vorher nicht, ob es
>> Datensätze geben wird. Oder anders formuliert: Das SELECT wird ja auch
>> ausgeführt, also ist dazu ein Ausführungsplan nötig. Und diesen sollte
>> EXPLAIN anzeigen. Dazu ist es bestimmt. Auch bei Mondschein und Ebbe.
>
> Ja, und? Das *ist* der Ausführungsplan: Die WHERE-Bedingung trifft auf
> keinen Datensatz zu ("Impossible"). Also passiert nix. So what?

Ich glaube, den Andreas Kretschmer stört hier bloss, das die Datenbank ja
erst einmal in die Tabelle schauen muss, um festzustellen, dass es keine
Daten zu liefern gibt. Dafür ist jedoch eine Anfrage notwendig und
MySQL liefert hier nicht die Daten für die Anfrage sondern praktisch
das Ergebnis.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Fehlerhafte Tabelle

Andreas Scherbaum!

> Ich glaube, den Andreas Kretschmer stört hier bloss, das die Datenbank ja
> erst einmal in die Tabelle schauen muss, um festzustellen, dass es keine
> Daten zu liefern gibt.

Kann ja sein, aber wo ist das Problem? Werte aus Tabellen, die nur einen
Record enthalten, behandelt der Optimizer als Konstanten. In einem solchen
Fall kann der Optimizer die Daten schon einlesen, anstatt dass das erst
später bei der Bearbeitung der optimierten Anfrage geschieht. Eigentlich
ist das eine Optimierung für JOINs. Der Optimizer macht das aber halt
auch, wenn kein JOIN kommt, weil es ja nicht teurer ist, als die Daten
erst einen Schritt später zu lesen...

EXPLAIN erzählt, was der Optimizer gemacht hat, bevor die Anfrage
ausgeführt worden wäre. Niemand sagt, dass da keine Daten gelesen
werden. Selbstverständlich darf der Optimizer soviele Daten lesen wie er
will, wenn er dann besser optimiert.


Gruß
Daniel