怎样在不锁表的情况下给搭建不久的MySQL 5.7海量数据表修改字符集？

MySQL 5.7 的 ALTER TABLE ... CONVERT TO CHARACTER SET 默认可能锁表：若列含 TEXT/BLOB、前缀索引或 varchar 长度超限，会降级为 ALGORITHM=COPY 全表复制并锁表；否则在兼容编码宽度时可走 ALGORITHM=INPLACE 实现轻量变更。

MySQL 5.7 的 ALTER TABLE ... CONVERT TO CHARACTER SET 会锁表吗？

不会全程锁表，但有风险——CONVERT TO CHARACTER SET 在 MySQL 5.7 中默认使用 ALGORITHM=INPLACE（只要目标字符集兼容源字符集且列类型不变），但前提是：源字符集和目标字符集的编码宽度一致（例如 latin1 → utf8 是安全的；utf8 → utf8mb4 也是安全的），且没有触发全表重建条件。

如果列定义含 TEXT/BLOB、或存在前缀索引、或目标字符集导致最大长度超限（如 varchar(255) 在 utf8mb4 下实际字节数可能突破 65535），MySQL 会自动降级为 ALGORITHM=COPY，这时就会锁表并阻塞写入。

1. 执行前先查表结构：SHOW CREATE TABLE your_table;，确认是否有 TEXT、前缀索引、或 varchar 长度接近上限
2. 用 SELECT COUNT(*) 粗估数据量，千万级以上建议在低峰期操作
3. 别直接写 CONVERT TO CHARACTER SET utf8mb4，先显式指定算法：ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci, ALGORITHM=INPLACE, LOCK=NONE;

为什么 show variables like 'character%' 全是 utf8，但插入中文仍报 Incorrect string value？

因为客户端连接层没对齐。MySQL 字符集是分层的：character_set_server（服务端默认）、collation_server、character_set_client、character_set_connection、character_set_results。哪怕服务端设成 utf8mb4，只要连接时没发 SET NAMES utf8mb4 或没在连接字符串里指定 charset=utf8mb4，客户端传过来的字节仍按 latin1 解析，导致四字节 emoji 或某些生僻中文被截断。

1. 检查当前会话字符集：SHOW VARIABLES LIKE 'character_set%'; 和 SHOW VARIABLES LIKE 'collation%';
2. 临时修复：连接后立即执行 SET NAMES utf8mb4;
3. 永久修复：在 my.ini 的 [client] 和 [mysql] 段加 default-character-set=utf8mb4，[mysqld] 段加 init_connect='SET NAMES utf8mb4'

已上线的表想改字符集，但不能停写，怎么最小化影响？

靠单条 ALTER TABLE 不够稳。真正适合“不锁表”的路径是分三步走：先改表定义（元数据），再逐批更新数据（应用层控制节奏），最后校验+清理。

1. 第一步：只改列定义（不触碰数据），用 MODIFY COLUMN 指定新字符集，例如：ALTER TABLE your_table MODIFY COLUMN content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci, ALGORITHM=INPLACE, LOCK=NONE;
2. 第二步：用应用代码分页更新内容（比如每批 1000 行），执行 UPDATE your_table SET content = content WHERE id BETWEEN ? AND ?; —— 这个看似无意义的赋值会强制 MySQL 按新字符集重新编码存储
3. 第三步：检查 information_schema.COLUMNS 确认 character_set_name 已更新，并用 SELECT HEX(content) 抽样验证中文/emoji 是否变成合法 UTF-8 编码字节序列

utf8 和 utf8mb4 到底该选哪个？

必须选 utf8mb4。MySQL 的 utf8 是阉割版，最多存 3 字节字符，不支持 emoji、部分中文古籍字、数学符号等。而 utf8mb4 才是真正的 UTF-8 实现。

1. utf8 在 MySQL 5.7 中已被标记为 legacy，最新文档明确建议迁移到 utf8mb4
2. 改之前确认 innodb_large_prefix 为 ON，innodb_file_format 为 BARRACUDA，否则 utf8mb4 下长索引可能失败
3. 建新表时直接用：CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;，别再用 utf8

真正麻烦的不是改配置，而是确保从连接、传输、存储到展示，每一层都对齐 utf8mb4 —— 少一个环节，中文就可能变问号或报错。