数据库表改成utf8mb4表情还是乱码，问题出在连接层

表已经从utf8改成utf8mb4，字段注释反复确认过，可用户在评论里打一个表情，存进去变成问号，或者直接报Incorrect string value。这类报错最容易查错方向，库是对的，表也是对的，出问题的是每一次连接进来时用的那套字符集。同一个库上命令行插入正常、PHP程序插入失败，基本就是这个信号：表里存的是声明，真正生效的是连接握手时商定的那一套。两个入口的默认值从来就不一样，先按入口分开测，能省掉一大半无用功。

连接上的字符集有三个变量，character_set_client决定客户端发来的字节按什么编码解读，character_set_connection是服务器处理时用的，character_set_results决定返回给客户端时用什么编码。这三个值对不齐，乱码就是必然的，而表上的字符集只在建表和转换那一刻起作用，运行期根本不看它。

PHP的mysqli建连之后调一次set_charset('utf8mb4')，这是最容易漏的一步。PDO在DSN里带charset=utf8mb4，命令行客户端每连一次先执行SET NAMES utf8mb4。框架一般留了配置位，Laravel在database.php的charset字段，ThinkPHP在params里。配置文件改的是新建连接的默认值，已经建立的长连接不会重新握手，改完得清一次连接池。

建索引的时候会撞上另一个坑。utf8mb4每个字符最多占4个字节，InnoDB在COMPACT、REDUNDANT这两种老行格式下索引键前缀上限是767字节。varchar(255)在utf8下要765字节，勉强塞得进去；换成utf8mb4就是1020字节，直接报Specified key was too long。老教程把索引列改成varchar(191)就是这个来由，191乘4等于764，刚好压在限下。这不是规范，是绕路，代价是索引列短了近三成，区分度跟着下降。报错里提到的字节上限是硬限制，不是建议值，看到它先算一遍字节数，别急着改字段类型。索引列的长度按字节算，不按字数算，这一点最容易被忽略。

MySQL8.0默认用DYNAMIC行格式，前缀上限是3072字节，同一个varchar(255)建索引不会再报错，新装的环境往往碰不到这个问题。从老版本升上来的库如果还是COMPACT，要么改成DYNAMIC，要么按191设计索引列。行格式一改整张表会重建，大表得挑低峰期做，先在一张从库上试出耗时再加到主库。

改完插一条带表情的记录，再原样查出来，两个方向都对才算通。连接池里的老连接不会自己更新。要重启进程或者让连接池重建，否则只对新连接生效。测的时候别用命令行，它本身就是对的，测不出问题。

mysqldump默认可能按latin1导出，文件本身就是坏的，导回去又是一轮乱码。加一条--default-character-set=utf8mb4才稳妥，导入前先看文件头的编码声明，这一步漏了前面改的等于白做。