SQL中0x前缀仅SQL Server和SQLite支持，MySQL需CONV()或UNHEX()，PostgreSQL用x'FF'或类型转换；HEX()函数用于字符串转换，不可用于索引优化查询。
SQL里用0x前缀查十六进制数值，只在部分数据库生效
直接写 WHERE id = 0xFF 这种写法，不是所有数据库都认。SQL Server 和 SQLite 支持 0x 前缀表示十六进制整数，MySQL 和 PostgreSQL 则不支持——它们会报语法错误或当成字符串字面量处理。
常见错误现象：ERROR: syntax error at or near "0x"（PostgreSQL）、You have an error in your SQL syntax（MySQL 8.0+）。这是因为 MySQL 要求十六进制字面量必须带引号且用 X' 或 0x + 引号组合，但仅限于表达式上下文，不能直接当数值字面量用于比较。
- SQL Server：支持
WHERE val = 0xFF，等价于255 - SQLite：同样支持
0xA1B2，自动转为整型 - MySQL：必须写成
WHERE val = 0xFF仅在严格模式关闭时可能隐式转换，更稳妥的是WHERE val = UNHEX('FF')（注意：UNHEX 返回二进制，需类型匹配）或WHERE val = CONV('FF', 16, 10) - PostgreSQL：不识别
0x，得用WHERE val = x'FF'（注意单引号和小写 x），或WHERE val = ('FF')::bit(8)::integer
用HEX()函数查数据，本质是查字符串，不是数值比对
HEX() 是把字段值转成十六进制字符串表示，比如 HEX(255) 返回 'FF'。所以 WHERE HEX(id) = 'FF' 看似直观，实则绕路：它强制对每行 id 做函数计算，无法走索引，大数据量下性能明显下降。
使用场景受限：仅适合调试、导出或临时核对；生产查询中应避免在 WHERE 子句中对被查字段使用 HEX()。
- MySQL / MariaDB：支持
HEX(col)，返回大写字符串 - PostgreSQL：没有内置
HEX()，得用TO_HEX(col::bigint)（要求输入为整型） - SQL Server：用
CONVERT(VARCHAR, col, 2)，2表示十六进制风格 - 别把
HEX(id)和id混用：前者是字符串，后者是数字，WHERE HEX(id) = 'FF'≠WHERE id = 255的执行计划
跨数据库安全查十六进制值的推荐写法
最稳的方式是统一转成十进制再比较，靠应用层或数据库兼容函数完成转换，不依赖字面量解析规则。
例如查十六进制 ABCD 对应的记录：
- MySQL：用
WHERE id = CONV('ABCD', 16, 10)（返回43981） - PostgreSQL：用
WHERE id = ('x' || 'ABCD')::bit(16)::integer，或更清晰的WHERE id = ('ABCD')::varbit::integer（需先SET bytea_output = 'hex'） - SQL Server：用
WHERE id = CONVERT(INT, 0xABCD)（直接支持0x前缀，但作为函数参数更可控） - 通用兜底：在应用代码里算好
int('ABCD', 16)，拼成纯数字条件，如WHERE id = 43981
容易忽略的细节：大小写、前导零和长度限制
十六进制字符串对大小写不敏感（'ff' 和 'FF' 等价），但某些函数或类型转换有隐含长度假设。比如 PostgreSQL 的 x'FF' 默认是 bytea，若字段是 INTEGER，需显式类型转换；SQL Server 的 0xFF 是 tinyint，超出范围会溢出。
- MySQL 的
CONV()不接受带0x前缀的字符串，必须传'ABCD'，不能传'0xABCD' - PostgreSQL 的
x'FF'最多支持 4 字节（x'FFFFFFFF'），超长要用decode()配合 base64 或分段处理 - 前导零不影响值，但某些旧版驱动或 ORM 可能截断，建议统一去掉或补全到固定长度再比较
- 二进制字段（如
BLOB、BYTEA）查十六进制内容，要用HEX()或ENCODE()，但务必确认字段实际存储的是原始字节而非编码后字符串
