Różnica między UNHEX a X (MySQL)

Question

Czym tak naprawdę jest różnica między MySQL UNHEX a X, gdy mamy do czynienia z wartościami heksadecymalnymi w bazie danych?

Np.

SELECT * FROM test WHERE guidCol IN (UNHEX('hexadecimalstring')); 

SELECT * FROM test WHERE guidCol IN (X'hexadecimalstring'); 

Obie dają mi dokładny zestaw wyników. Czy jest jakaś różnica? Implikacje związane z wydajnością?

Edit: bazowy typ guidCol jest binarny oczywiście

Answer 1

UNHEX() jest a function, więc można zrobić coś jak

SET @var = '41'; 
SELECT UNHEX(@var); 
SELECT UNHEX(hex_column) FROM my_table; 

X, z drugiej strony, jest składnia dla hexadecimal litteral. Nie można tego zrobić:

SET @var = '41'; 
SELECT X@var; -- error (string litteral expected) 
SELECT X'@var'; -- error (`@` is not a hexadecimal digit) 
SELECT X(@var); -- returns NULL, not too sure about the reason... [edit: but this is probably why you are inserting NULL values] 
SELECT X(hex_column) FROM my_table; -- returns NULL as well 

To wyjaśnia, dlaczego zawsze uzyskać lepszą wydajność z X: używasz konstrukt język zamiast wywołania funkcji. X nie musi oceniać zmiennej, ponieważ oczekuje ciągów literowych.

Answer 2

Należy zauważyć, że nawet w MySQL 5.6 notacja X 'ma limit długości w referencyjnym kliencie mysql, a UNHEX() nie (wygląda na to). Nie wiem, jaki jest limit dla X '', ponieważ nie jest on oficjalnie udokumentowany, ale napotkałem go przy próbie INSERT BLOB. Z literałem X ', klient mysql rzucił błąd składniowy z wystarczająco długą sekwencją heksadecymalną, podczas gdy UNHEX() tej samej sekwencji nie. Oczywiście, długość nie jest problemem, jeśli chodzi o faktyczny GUID, ale pomyślałem, że jest to użyteczne dla każdego, kto używa tego pytania do odpowiedzi na mysql wstawiania danych binarnych w ogólnym przypadku.