utf8mb4本身不增加锁开销，但字段长度膨胀会触发隐式锁升级：因单字符占4字节导致索引键变长、页分裂增多、锁竞争升高；CONVERT TO utf8mb4若退化为COPY算法则全表重建并持SX元数据锁；客户端未设charset=utf8mb4还会引发隐式转换致索引失效、全表扫描及行锁扩大。
utf8mb4 本身不增加锁开销，但字段长度膨胀会触发隐式锁升级
MySQL 的行级锁（如 SELECT ... FOR UPDATE）锁定的是索引记录或间隙，而索引记录大小直接受字段字符集影响。utf8mb4 下单字符最多占 4 字节，相比 latin1（1 字节）或 utf8mb3（3 字节），相同定义的 VARCHAR 字段在存储层和索引层实际占用字节数可能翻倍。InnoDB 在构建二级索引时，若索引键长度超过限制（如默认 767 字节），会自动降级为前缀索引或拒绝建索引——但更隐蔽的问题是：当索引页内能容纳的记录数减少，页分裂频率上升，B+ 树层级变深，锁粒度虽未变，但锁竞争概率显著升高。
ALTER TABLE CONVERT TO CHARACTER SET utf8mb4 可能导致全表重建与元数据锁阻塞
执行 ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 时，MySQL 8.0 默认使用 ALGORITHM=INPLACE，但前提是满足所有前提条件：表必须是 ROW_FORMAT=DYNAMIC 或 COMPRESSED，且 innodb_large_prefix = ON。一旦任一条件不满足，MySQL 会静默退回到 COPY 算法——这意味着：
- 全表数据读出、逐行重编码、写入新临时表
- 整个过程持有
SX（共享排他）元数据锁，阻塞所有 DML - 若表大、IO 慢或存在长事务，
ALTER可能卡住数分钟甚至更久，下游应用出现大量锁等待超时
连接层 charset 不匹配引发隐式字符转换，拖慢 WHERE 条件索引查找
即使表字段是 utf8mb4，若客户端连接未声明 charset=utf8mb4（例如 JDBC URL 漏了 &characterEncoding=utf8mb4），MySQL 会按连接字符集（如 latin1）解码传入的字符串值。此时执行 WHERE name = '?'，服务端发现传入字节序列无法在当前连接字符集下合法解析，就会触发隐式转换：把 name 字段值从 utf8mb4 转成连接字符集再比对——这直接导致索引失效，走全表扫描，锁住更多行。
现象表现为：EXPLAIN 显示 type: ALL，rows 值远高于预期，SHOW ENGINE INNODB STATUS 中看到大量 LOCK WAIT 状态的事务在等同一张表。
真正要盯住的不是字符集，而是索引键长度与连接一致性
utf8mb4 引发的锁问题，90% 都不是字符集本身惹的祸，而是没同步处理好三件事：字段定义是否显式声明 CHARACTER SET utf8mb4（别依赖 CONVERT TO 自动推断）、索引列是否因长度超限被截断（检查 SHOW CREATE TABLE 输出里有没有 KEY `idx_name` (`name`(191)) 这类前缀索引）、连接串是否带齐 charset=utf8mb4。漏掉其中任意一项，都可能让原本毫秒级的更新变成秒级锁等待。
