根本原因是数据库、连接、字段三者编码不一致，尤其子查询字段为utf8mb4而外层用utf8时，Emoji会被截断成???或报错；需统一设为utf8mb4字符集与对应collation，并显式转换类型。
子查询返回Emoji时出现乱码或问号
根本原因是数据库、连接、字段三者编码不一致，尤其当外层查询对子查询结果做字符串拼接或排序时，MySQL 会按字段定义的字符集隐式转换，若子查询字段是 utf8mb4 而外层临时表或连接默认用 utf8（即 utf8mb3），Emoji 就会被截断成 ??? 或报错 Incorrect string value。
实操建议：
- 确认子查询涉及的所有字段都显式声明为
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，不要依赖表级默认值 - 在执行嵌套查询前，强制设置会话级编码：
SET NAMES utf8mb4；若用 JDBC，需在连接 URL 加?characterEncoding=utf8mb4&useUnicode=true - 避免在子查询中用
CONCAT()拼接 Emoji 和普通字符串，除非所有操作数都是utf8mb4类型；否则先用CONVERT(... USING utf8mb4)显式转码
WHERE子句中用Emoji做子查询条件匹配失败
常见于类似 WHERE name IN (SELECT nickname FROM users WHERE status = 'active')，而 nickname 含 Emoji —— 若子查询结果被当作 utf8 字符串参与比较，Emoji 会被视为非法字节而跳过匹配，甚至导致空结果。
实操建议：
- 检查子查询字段的
COLUMN_TYPE和COLLATION_NAME：用SHOW FULL COLUMNS FROM users LIKE 'nickname'验证是否为utf8mb4_unicode_ci - 在子查询外层加
CAST强制统一类型：WHERE name IN (SELECT CAST(nickname AS CHAR CHARACTER SET utf8mb4) FROM users ...) - 若使用
IN匹配大量 Emoji 值，注意 MySQL 对utf8mb4字段的索引长度限制（最大 191 字符），必要时缩小字段长度或改用前缀索引
GROUP BY 或 ORDER BY 子查询结果时Emoji排序异常
Emoji 在不同 collation 下排序规则不同：utf8mb4_unicode_ci 按 Unicode 码位粗略分组，utf8mb4_0900_as_cs（MySQL 8.0+）才支持大小写敏感和 Emoji 精确比较。嵌套查询中若子查询未指定 collation，外层 GROUP BY 可能降级为 utf8mb3_general_ci 规则，导致 ? 和 ? 被归为同一组。
实操建议：
- 子查询中对 Emoji 字段显式加 collation：例如
SELECT emoji_col COLLATE utf8mb4_0900_as_cs FROM ... - 避免在
GROUP BY中直接引用子查询别名（如SELECT e FROM (...) AS t GROUP BY e），改为重复带 collation 的表达式 - 测试排序行为：用
SELECT emoji_col, HEX(emoji_col) FROM ... ORDER BY emoji_col COLLATE utf8mb4_0900_as_cs对比不同 collation 输出
JSON函数嵌套处理Emoji时丢失或转义错误
MySQL 的 JSON_OBJECT()、JSON_ARRAY() 默认将非 ASCII 字符转义为 \uXXXX 形式，但若连接或字段编码不是 utf8mb4，Emoji 可能被双重转义或解码失败；更隐蔽的是，JSON_EXTRACT() 返回的字符串可能继承 session 的默认字符集，导致后续子查询无法正确识别 Emoji。
实操建议：
- 构造 JSON 前先确保源数据是
utf8mb4：例如JSON_OBJECT('name', CONVERT(name USING utf8mb4)) - 从 JSON 提取 Emoji 后，立即用
CAST(... AS CHAR CHARACTER SET utf8mb4)转回可比较字符串，不要直接用于WHERE或JOIN - 避免在
JSON_CONTAINS()中直接传 Emoji 字面量，改用变量或预处理语句参数，防止客户端驱动自动转义
CHARACTER_SET_NAME）由**第一个被选中的行决定**，如果子查询有 UNION 或 NULL 值混入，可能让整个结果集降级为 utf8。 
