MySQL 连接字符集改成 utf8mb4 后索引前缀要不要调整

通常不用因为“连接字符集改成 utf8mb4”就立刻调整索引前缀。连接字符集只影响当前会话发送和接收 SQL、结果的编码；真正可能改变索引字节数的是把列从 utf8mb3 或其他字符集转换成 utf8mb4。迁移前要按列定义、前缀长度、InnoDB 行格式和实例页大小重新核算，而不是只看配置文件。

判断结论：只改客户端连接参数，索引不需要跟着改；改了列字符集后，如果前缀长度乘以每字符最大字节数超过当前 InnoDB 上限，就必须缩短前缀、调整索引设计或先处理表的行格式与页大小约束。

先分清连接字符集和列字符集

MySQL 会话有 character_set_client、character_set_connection 和 character_set_results 等变量。驱动连接串里的 charset=utf8mb4，或者登录后执行 SET NAMES 'utf8mb4'，解决的是客户端与服务端之间如何解释请求和结果。它不会把已有表的列自动改成新字符集。

-- 只查看当前会话的通信字符集，不修改表结构
SHOW SESSION VARIABLES
WHERE Variable_name IN (
  'character_set_client', 'character_set_connection',
  'character_set_results', 'collation_connection'
);

-- 直接确认表和列是否已经完成字符集迁移
SHOW CREATE TABLE customer_profile;

因此，若应用只是统一连接配置，重点是回归中文、Emoji 和排序比较；若还执行了 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4，才需要进入索引前缀核算。

用字节而不是字符数判断前缀是否安全

utf8mb4 支持 BMP 和补充字符，单个多字节字符最多占 4 字节。一个 VARCHAR(255) 的索引前缀若按最坏情况估算，可能需要 255 × 4 = 1020 字节；它是否可用，还要和索引中的其他列一起计算。

对常见的 InnoDB DYNAMIC 或 COMPRESSED 行格式，8.4 文档给出的索引键前缀上限是 3072 字节；COMPACT 或 REDUNDANT 行格式则是 767 字节。实例若使用 8KB 或 4KB 页，最大索引键还会按页大小降低。这个边界针对的是完整索引键和前缀索引，不能把 191 个字符当成所有环境的永久答案。

把受影响的列和索引找出来

不要把所有字符串列都改成短前缀。先锁定参与索引的长字符串列，再对照其字符集和前缀长度。下面的查询只读元数据，结果中的 SUB_PART 是按字符计的前缀长度，最终仍要结合字符集的最大字节数解释。

-- 找出当前库中带前缀的字符列索引
SELECT s.TABLE_NAME, s.INDEX_NAME, s.COLUMN_NAME,
       s.SEQ_IN_INDEX, s.SUB_PART,
       c.CHARACTER_SET_NAME, c.CHARACTER_MAXIMUM_LENGTH
FROM information_schema.STATISTICS AS s
JOIN information_schema.COLUMNS AS c
  ON c.TABLE_SCHEMA = s.TABLE_SCHEMA
 AND c.TABLE_NAME = s.TABLE_NAME
 AND c.COLUMN_NAME = s.COLUMN_NAME
WHERE s.TABLE_SCHEMA = DATABASE()
  AND s.SUB_PART IS NOT NULL
  AND c.DATA_TYPE IN ('char', 'varchar', 'text', 'tinytext', 'mediumtext')
ORDER BY s.TABLE_NAME, s.INDEX_NAME, s.SEQ_IN_INDEX;

如果索引是联合索引，还要把每个键部分放在一起评估；例如 (tenant_id, nickname(180), created_at) 不能只计算 nickname 的 720 字节。字符列的排序规则也要保持业务语义一致，不能为了省字节随意改成二进制排序。

三种调整方式怎么选

如果检查后仍在上限内，保持原索引即可；连接参数变化本身没有理由触发重建。若转换后超过限制，先在测试环境计算一个有余量的前缀，例如把过长的名字索引从 255 缩到 150 或 180，再用真实查询验证选择性。

如果查询需要完整字符串的唯一性，缩短前缀可能不再满足唯一索引语义，可以考虑增加独立的短哈希列并建立唯一约束，但要处理哈希碰撞与写入一致性。若索引根本不承担高选择性的查询，也可以重新评估是否保留，而不是机械保留旧索引。

-- 先在测试库重建为有余量的前缀，名称仅作示例
ALTER TABLE customer_profile
  DROP INDEX uk_nickname,
  ADD UNIQUE KEY uk_nickname (nickname(180));

-- 迁移后确认列字符集与索引定义
SHOW CREATE TABLE customer_profile;
EXPLAIN SELECT id FROM customer_profile
WHERE nickname = '示例用户';

常见问题

只把连接串改成 utf8mb4，会让索引变长吗？

不会。连接串改变的是会话通信编码；只有列定义或索引定义发生迁移时，索引字节边界才需要重新核算。

为什么 255 个字符有时能建索引，有时不行？

因为上限按字节计算，还受字符集、联合索引其他列、InnoDB 行格式和实例页大小影响。不能只按字符数判断。

缩短前缀后，唯一索引还可靠吗？

唯一性只覆盖索引前缀，两个长字符串可能在前缀内相同。需要完整字符串唯一性时，应改用合适的生成列或哈希方案，并设计碰撞处理。

迁移的稳妥顺序是：先确认连接设置，再确认列是否转换，随后按实际 InnoDB 环境核算索引总字节数，最后用真实查询复查选择性和执行计划。这样既不会为会话参数做无谓 DDL，也不会在字符集迁移后漏掉索引上限风险。