MySQL中text字段存不下emoji，因默认utf8仅支持3字节，而emoji需4字节；必须将表、字段、服务端（my.cnf中character-set-server=utf8mb4）、连接层全升级为utf8mb4并配对应collation，缺一不可。
MySQL 中 text 字段存不下表情符号？先确认字符集
默认的 utf8 字符集在 MySQL 5.5.3 之前只支持最多 3 字节的 Unicode 字符，而大多数 emoji（如 ?、❤️、??）需要 4 字节，会导致插入截断或报错 Incorrect string value。
必须把字段和表都升级到 utf8mb4，且配套设置 collation 为 utf8mb4_unicode_ci 或 utf8mb4_0900_as_cs（MySQL 8.0+ 推荐）：
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：仅改表字符集不够，my.cnf 还需确保 collation-server=utf8mb4_unicode_ci 和 character-set-server=utf8mb4，否则客户端连接可能仍按旧规则解析。
UPDATE 语句里安全替换 emoji 或特殊符号
直接用 REPLACE() 处理 emoji 很容易出错——因为部分 emoji 是组合序列（如 ?? = ? + U+200D + ?），单个 REPLACE() 无法匹配；而且 MySQL 的字符串函数对多字节处理不一致，LENGTH() 返回字节数而非字符数，容易误判。
更稳妥的做法是用正则替换（MySQL 8.0+ 支持 REGEXP_REPLACE()）或分步清洗：
- 用
REGEXP_REPLACE(content, '[???]', '*')替换常见 emoji（注意：正则模式需用 Unicode 码点或实际字符，不能写 u1F60A 这类 JS 风格） - 若需删除所有非 ASCII 字符（保留英文、数字、基础标点），可用：
REGEXP_REPLACE(content, '[^\x00-\x7F]', '') - 批量替换前先加
WHERE content REGEXP '[??]'限定范围，避免全表扫描和无谓更新
PostgreSQL 怎么处理含 emoji 的文本更新？
PostgreSQL 默认就支持完整的 UTF-8（即等价于 MySQL 的 utf8mb4），无需额外切换字符集。但要注意 text 类型本身没问题，问题常出在客户端连接参数或应用层编码没对齐。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
使用 regexp_replace() 更灵活，支持 Unicode 属性类：
UPDATE posts SET title = regexp_replace(title, 'p{Emoji}', '[EMOJI]', 'g');
这个 p{Emoji} 能准确匹配标准 emoji 区块（包括修饰符、ZWJ 序列），比手动列字符可靠得多。不过要确保数据库初始化时用了 LC_COLLATE='en_US.utf8' 类似 locale，否则某些正则行为异常。
另外，PostgreSQL 的 length() 返回的是字符数，不是字节数，这点比 MySQL 更直观，但也意味着用 substring() 截取时得小心 emoji 占多个 code point。
批量更新时性能和事务边界怎么控？
一次更新几万行含 emoji 的字段，很容易锁表或触发 long query timeout，尤其在没索引的 WHERE 条件下。
建议拆成小批次执行，并显式控制事务：
- 用
LIMIT分页（MySQL）：UPDATE logs SET msg = REPLACE(msg, '❌', '[ERROR]') WHERE id BETWEEN 10000 AND 19999; - PostgreSQL 可结合
ctid或自增 ID 分片，避免OFFSET越往后越慢 - 每批更新后加
COMMIT，防止事务日志暴涨；如果业务允许，临时关掉 binlog（MySQL）或 WAL 归档（PG）可提速，但务必评估主从同步风险 - 更新前用
SELECT COUNT(*)预估量级，若超 10 万行，优先考虑应用层分批读-改-写，而不是纯 SQL 批量 UPDATE
emoji 本身不增加计算开销，但多字节字符串让比较、替换、正则匹配的 CPU 成本明显上升，尤其是 REGEXP_REPLACE 在大数据集上可能比普通 REPLACE 慢一个数量级。
