Merkwürdiges Verhalten von MySQL!?

Moin,

ersteinmal möcht ich mich für die warscheinlich missglückte Überschrift entschuldigen. Mir ist allerdings nichts kurzes und knappes eingefallen, was mein "Problem" trifft.

Irgendwie ist mir erst heute ein merkwürdiges Verhalten von MySQL aufgefallen. Undzwar geht es um folgenen Query:

SELECT Subject FROM post WHERE ID = '1asfgh'

Der Eintrag mit der ID 1 wird dennoch gefunden. Ich kann da sonst was reinschreiben... sobald die ersten Stellen übereinstimmen(funktioniert auch mit mehrstelligen Eingaben) ist MySQL der Meinung, dass die IDs übereinstimmen. Gibt es eine Möglichkeit, genau nach dem gesuchten Wert zu suchen?

Ist dieses Verhalten normal? Ich mein... ich 'arbeite' jetzt schon ewig lange mit MySQL und irgendwie ist mir das noch nie aufgefallen.

Kann ich nicht nachvollziehen.

CREATE-Table-Statement ist...?

"Vermutlich" ist ID ein nummerisches Feld und MySQL holt aus dem alpha-nummerischen Value den nummerischen Anteil und nutzt ihn weiter.

Weiterhin gilt natürlich, was ghostgambler gefordert hat ...

Sieht wie folgt aus:

CREATE TABLE `post` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `User_ID` int(11) NOT NULL,
  `Date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `Subject` varchar(255) NOT NULL,
  `Text` text NOT NULL,
  `Tags` text NOT NULL,
  PRIMARY KEY (`ID`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1;

Ich habe das Verhalten bei mir getestet. Wenn eine ID-Spalte vom Typ INT - oder ein anderer Zahlentyp - ist, werden in deinem Fall der Query beim Value die nummerischen Werte - wenn sie am Anfang stehen - genutzt und der Rest abgeschnitten.

Wenn dein Value 'asd1asfgh' ist, findest du keine Ergebnisse mit Id=1

Zitat von JimmDaBimm

SELECT Subject FROM post WHERE ID = '1asfgh'

Der Eintrag mit der ID 1 wird dennoch gefunden. Ich kann da sonst was reinschreiben...

Das ist das normale Casting-Verhalten bei der Umwandlung von Strings in nummerische Werte; in PHP ist es ganz analog.

Du kannst bspw. BINARY benutzen, um die ID ebenfalls in einen String zu casten - SELECT BINARY 1 = '1xyz' liefert 0, also false.

Ob das der optimalste Weg ist, darüber kann man ggf. streiten. Du könntest ja auch vorher schon dafür sorgen, dass nur nummerische bzw. INT-Werte in der Query landen.

Vielen Dank für die hilfreichen Antworten. Selbstverständlich sorge ich schon im Script dafür, dass nur numerische Werte im Query ankommen. Das lässt sich mit PHP ja glücklicher Weise recht gut lösen. Mir ging es in erster Linie auch nur um das Verhalten an sich.

Das Verhalten ist unter PHP genauso:

PHP-Code:

var_dump(1 == '1asfgh');
// bool(true) 


PHP und MySQL haben ein automatisches Type-Casting.

naja, ich prüfe jetzt einfach mit ctype_digit() ob nur Ziffern enthalten sind und dann past das schon .

Dann mach dir auch schon mal über negative Integerwerte und Doublewerte allgemein Gedanken.

Zitat von JimmDaBimm

naja, ich prüfe jetzt einfach mit ctype_digit() ob nur Ziffern enthalten sind und dann past das schon .

Ein reiner Cast auf Integer reicht in den meisten Fällen. Was soll schon passieren? Im blödesten Fall wird auf 0 gecastet, dann bekommt der "Angreifer" kein Ergebnis. Ich würd mir den Stress nicht antun, immer auf Dezimalziffern zu prüfen. Und wie bereits PHP-Desaster treffend bemerkt hat, ist es ja mit einer reinen Überprüfung auf Dezimalziffern nicht getan, wenn du wirklich eine wasserdichte Prüfung willst. Also entweder ganz oder gar nicht.

Ah, mit viel Aufwand "klappt" es bei mir dann auch.

Die Frage die ich mir allerdings eher stelle ist: Warum fragst du für eine int-Spalte mit einem String ab?
intval() in PHP vorher schon drauf und gut ist.
Wenn man dann - trotz falsch übergebenem Wert - trotzdem den korrekten Datensatz liefert, ist das doch umso besser.

Zitat von ghostgambler

Wenn man dann - trotz falsch übergebenem Wert - trotzdem den korrekten Datensatz liefert, ist das doch umso besser.

Jein.

Wenn der Parameter aus einem URL stammt - dann führt das zu mehreren URLs, die die gleichen Inhalte liefern.
/article/1 sollte eindeutig sein - und nicht /article/1xyz und /article/1blah die gleichen Inhalte liefern.
Dagegen, den Fall zu erkennen, und auf /article/1 umzuleiten, spricht nichts - aber einfach kommentarlos den Inhalt anzuzeigen, ohne auf den Fehler in der Adresse zu reagieren, halte ich für falsch.