mysql中where直接匹配emoji失败的根本原因是默认校对规则（如utf8mb4_unicode_ci）对zjw序列、肤色修饰符等支持极弱，安全做法只有：①强制二进制比较where name collate utf8mb4_bin = '??'；②比字节where hex(name) = 'f09f91a8f09f8fb4f09f928d'。
WHERE条件里用COLLATE utf8mb4_bin或HEX()匹配emoji
直接写WHERE name = '??'在MySQL里大概率查不到，哪怕字段存的就是这个emoji。根本原因是默认校对规则（如utf8mb4_unicode_ci）对ZJW序列、肤色修饰符等支持极弱，比较时可能忽略差异甚至静默失败。安全做法只有两个：
① 强制二进制比较：WHERE name COLLATE utf8mb4_bin = '??'
② 跳过字符逻辑，比字节：WHERE HEX(name) = 'F09F91A8F09F8FB4F09F928D'（需先用SELECT HEX(name)确认实际存储值）
注意：utf8mb4_0900_as_cs比_unicode_ci强，但仍不保底；_bin是唯一能保证字节级精确相等的选项。
SQL Server中LIKE查询生僻汉字必须加COLLATE Chinese_PRC_BIN
遇到WHERE col LIKE N'%䱗%'返回多条或零条结果，不是数据问题，是默认排序规则把生僻字映射到相近常见字（比如“䱗”被当成“鲤”处理）。解决方案非常明确：
• 必须显式指定二进制校对：WHERE col COLLATE Chinese_PRC_BIN LIKE N'%䱗%'
• 不能只写N'%䱗%'——前缀N只解决字符串字面量编码，不影响字段本身的比较行为
• Chinese_PRC_CS_AS仍可能模糊匹配，只有_BIN后缀才强制按Unicode码点逐字节比对
如果表字段本身是varchar而非nvarchar，先ALTER COLUMN ... NVARCHAR(MAX)，否则N''前缀无效。
PostgreSQL中查控制字符得用get_byte()和正则组合
用户提交的文本里混入了不可见字符（如U+200B零宽空格、U+0000空字符），WHERE text = 'abc'永远不成立，因为肉眼“一样”但底层字节不同。PostgreSQL没有HEX()函数，得换思路：
• 定位异常位置：SELECT get_byte('au200bc'::bytea, 1)返回8203（即U+200B的UTF-8编码）
• 批量识别：WHERE text ~ E'[\u200b\u00a0\u3000]'（E''启用Unicode转义）
• 清理时别只靠TRIM()——它对零宽空格、全角空格完全无效
关键点：PostgreSQL的~操作符默认使用POSIX正则，[s]不包含U+3000等Unicode空格，必须显式列出。
所有数据库都绕不开的字符集声明陷阱
即使SQL语句写对了，连接层一错全盘皆输：
• MySQL JDBC连接串必须带?characterEncoding=utf8mb4&useUnicode=true，否则驱动把参数当latin1解码，emoji变???
• SQL Server用bcp导出Unicode数据时，文件开头的BOM（0xFFFE）可能被误读，导致导入报错Invalid character value for cast specification，此时应改用-w开关并配合格式化文件
• PostgreSQL客户端执行SET client_encoding TO 'UTF8'仅影响当前会话，建表时字段仍需明确定义CHARACTER SET utf8（实际是UTF8编码）
最易忽略的是：字段定义、连接配置、客户端编码三者必须全部对齐，差一个就出现“存进去正常，查出来乱码，WHERE又查不到”的链式故障。
