I don't have this kind of ID in my table, still MySQL is giving me a result. This same result is giving when i place in my php code.
I am always majorly impressed by MySQL. It seems that in order to do the the type comparison, MySQL implicitly converts the string literal you are passing to the where clause to an unsigned integer. Through the mechanics of the implementation of the MySQL
CONVERT function, the datatype switch simply cannot fail, in this case, giving you the 182 value. The links show a few examples of the CONVERT function behaving, well, badly, imo.
Some DBMS are omnipotent and merciless. They give numerous warnings and errors in all kinds of situations when a user is attempting the slightest deviation from the correct behaviour - defined by the standards and the DBMS documentation.
MySQL is merciful and all-loving. She is trying to help everyone. Even if someone is comparing a string to an integer, she's thinking that the user may know better what he is doing and that maybe he is right. Not wanting to let him go in despair, she is trying - against all consistency and integrity laws - to compare the 2 incomparable things.
And - oh, the miracle - sometimes the 2 things are the same after all! What if one is the number
182 (which comes from an
id column, stored in 4 bytes) and the other is the string
182^%^&$$%$%$sjfhjs ^%^&%&*^$^%$^$ which needs 28. They look the same anyway, when the second is truncated from those silly characters!