データベース内の16進値を扱うとき、実際にはMySQL UNHEXとXの違いは何ですか？UNHEXとXの違い（MySQL）
例：
SELECT * FROM test WHERE guidCol IN (UNHEX('hexadecimalstring'));
SELECT * FROM test WHERE guidCol IN (X'hexadecimalstring');
どちらも正確な結果セットです。違いはありますか？パフォーマンスの影響？
編集： guidColの基になる型が
UNHEX()もちろんのバイナリであるため、あなたが
SET @var = '41';
SELECT UNHEX(@var);
SELECT UNHEX(hex_column) FROM my_table;
Xような何かを行うことができ、一方、シンタックスで、a functionですhexadecimal litteral。あなたはこれを行うことはできません：あなたは言語構造の代わりに、関数呼び出しを使用している：あなたは常にXとのより良いパフォーマンスを得る理由
SET @var = '41';
SELECT [email protected]; -- 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
これは説明します。 Xは、変数を評価する必要はありません。これは、リテラル文字列を期待するためです。
MySQL 5.6でも、X ''表記は参照mysqlクライアントに長さ制限があり、UNHEX（）は（現れない）ことに注意してください。私は、制限がX ''のものであるかどうかは分かっていません。正式には文書化されていませんが、BLOBを挿入しようとしたときに遭遇しました。 X "リテラルでは、mysqlクライアントは十分に長い16進シーケンスで構文エラーを投げ、同じシーケンスのUNHEX（）はそうしなかった。明らかに、長さは実際のGUIDに関しては問題ではありませんが、一般的なケースでバイナリデータのmysqlへの応答にこの質問を使用する他の誰にとっても便利だと思いました。
正解！ありがとう.. – nawfal