join前必须确认字段字符集为utf8mb4，否则隐式转换会截断emoji导致匹配失败；需检查并显式修改字段字符集与校对规则，避免隐式类型转换、跨库collation不一致及比较失效问题。
JOIN前必须确认字段字符集是否为utf8mb4
如果参与JOIN的字段（比如 user_name 或 comment_text）仍是 utf8 或 latin1，MySQL 会在隐式转换时把 emoji 截成 ???，导致匹配失败——哪怕肉眼看值一样，底层字节已损坏。
检查方式：执行 SHOW FULL COLUMNS FROM your_table LIKE 'column_name'，确认 Collation 列是 utf8mb4_unicode_ci 或 utf8mb4_0900_as_cs；不是就立刻改：ALTER TABLE your_table MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。
- 不要只改表级默认字符集，字段级定义必须显式指定
- 如果字段是
TEXT类型，也要用MODIFY而非CHANGE，避免意外丢数据 - 索引长度限制仍存在：utf8mb4 字段索引最大长度为 191 字符，若原字段长度超限，需同步调整索引或改用前缀索引
ON 条件里避免隐式类型转换
当一边是 utf8mb4 字段、另一边是函数结果（如 CONCAT()、UPPER()）或子查询结果时，MySQL 可能按会话默认字符集做隐式转换，emoji 就被“消毒”了。
安全写法是全部显式转码：ON CONVERT(t1.name USING utf8mb4) = CONVERT(t2.nickname USING utf8mb4)。更推荐在 JOIN 前统一 CAST：CAST(t2.nickname AS CHAR CHARACTER SET utf8mb4)。
- 别依赖
SET NAMES utf8mb4后就万事大吉——它只影响 client/connection/results，不改变字段定义本身的 collation 行为 - 如果 t2 来自子查询，且子查询里用了
GROUP BY或ORDER BY，MySQL 会创建临时表，默认用 server 字符集，极易出错 - JDBC 连接串必须带
?characterEncoding=utf8mb4&useUnicode=true，否则驱动可能把参数当成 latin1 解析
WHERE 中用 emoji 做条件时匹配失效
现象是 WHERE name = '??' 查不到数据，但 SELECT HEX(name) 看值确实是 F09F91A4。根本原因是 MySQL 对等值比较使用的是 collation 规则，而部分 utf8mb4 collation（如 utf8mb4_general_ci）对 emoji 的排序和比较支持极弱，甚至直接忽略修饰符或 ZWJ 序列。
解决办法只有两个：
① 改用二进制比较：WHERE name COLLATE utf8mb4_bin = '??'
② 改用十六进制匹配：WHERE HEX(name) = 'F09F91A4'
-
utf8mb4_unicode_ci比utf8mb4_general_ci更可靠，但仍不保证所有 emoji 精确相等；utf8mb4_0900_as_cs（MySQL 8.0+）支持大小写和重音敏感，推荐优先选用 - 如果条件来自用户输入，务必先验证输入是否为合法 utf8mb4 字节序列，避免传入截断或乱码字符串引发全表扫描
- IN 列表含 emoji 时，每个值都要单独加 collate，不能只在左边加
跨库 JOIN 时 emoji 匹配失败
不同数据库实例即使都设了 utf8mb4，也可能因 server 层 collation 配置不同（比如一个用 utf8mb4_unicode_ci，另一个用 utf8mb4_bin），导致 JOIN 结果为空或重复。
最稳方案是不跨库 JOIN，改用应用层关联；非要跨库，就得强制统一 collation：ON t1.name COLLATE utf8mb4_unicode_ci = t2.name COLLATE utf8mb4_unicode_ci，并且两边连接字段都必须有对应索引。
- 跨库 JOIN 本质是 Federated 或 FEDERATED 引擎行为，实际走的是远程查询 + 本地合并，字符集协商逻辑比单库复杂得多
- PostgreSQL 和 MySQL 混合 JOIN 几乎不可行——PG 的 text 类型默认支持完整 UTF-8，但 MySQL 客户端连接时若没正确声明 charset，PG 返回的数据会被 MySQL 错解
- 真正棘手的不是存储，而是比较：emoji 的 Unicode 标准一直在演进，MySQL 的 collation 实现未必跟上最新版 Emoji 排序规则
