I have a problem with BINARY(16) type (ULID under the hood) and specific ULID 01HRS49374C1EAGTPKTJ0JVT1P (hex 018e32448ce4605ca86ad3d4812de836) when queried using LIKE. LIKE query works with other ULIDs but not with this specific one.
Because its a ULID the length is always 16bytes so its not an issue with size of the field.
Last SELECT statement from the code bellow returns empty result! Why?
CREATE TABLE IF NOT EXISTS new_table (
id BINARY(16) PRIMARY KEY NOT NULL,
name VARCHAR(255)
);
INSERT INTO new_table SET id = UNHEX("018e321f579997e1f2a907a72b98f965"), name = "this works fine";
INSERT INTO new_table SET id = UNHEX("018e32448ce4605ca86ad3d4812de836"), name = "try find this using LIKE";
SELECT HEX(id), name FROM new_table WHERE id LIKE UNHEX("018e321f579997e1f2a907a72b98f965");
SELECT HEX(id), name FROM new_table WHERE id LIKE UNHEX("018e32448ce4605ca86ad3d4812de836");
It works if we change the ESCAPE character:
It also works if we disable backslash as a metacharacter:
So I tried to view the binary string in the client:
There's the backslash.
The point being that
LIKEapplies some special meaning to certain characters in the string, like backslash and_and%.If you UNHEX a random hex string, you don't know if the bytes will by coincidence become one of those characters that are special to
LIKE.Conclusion: It's not a bug.
LIKEis not the appropriate comparison operator for your search.In your example, it would be fine to use
=, because you are checking for strings being equal, not using pattern-matching withLIKE.This works: