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，这时就会锁表并阻塞写入。
- 执行前先查表结构：
SHOW CREATE TABLE your_table;，确认是否有TEXT、前缀索引、或varchar长度接近上限 - 用
SELECT COUNT(*)粗估数据量，千万级以上建议在低峰期操作 - 别直接写
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 或某些生僻中文被截断。
- 检查当前会话字符集：
SHOW VARIABLES LIKE 'character_set%';和SHOW VARIABLES LIKE 'collation%'; - 临时修复：连接后立即执行
SET NAMES utf8mb4; - 永久修复：在
my.ini的[client]和[mysql]段加default-character-set=utf8mb4，[mysqld]段加init_connect='SET NAMES utf8mb4'
已上线的表想改字符集，但不能停写，怎么最小化影响？
靠单条 ALTER TABLE 不够稳。真正适合“不锁表”的路径是分三步走：先改表定义（元数据），再逐批更新数据（应用层控制节奏），最后校验+清理。
- 第一步：只改列定义（不触碰数据），用
MODIFY COLUMN指定新字符集，例如：ALTER TABLE your_table MODIFY COLUMN content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci, ALGORITHM=INPLACE, LOCK=NONE; - 第二步：用应用代码分页更新内容（比如每批 1000 行），执行
UPDATE your_table SET content = content WHERE id BETWEEN ? AND ?;—— 这个看似无意义的赋值会强制 MySQL 按新字符集重新编码存储 - 第三步：检查
information_schema.COLUMNS确认character_set_name已更新，并用SELECT HEX(content)抽样验证中文/emoji 是否变成合法 UTF-8 编码字节序列
utf8 和 utf8mb4 到底该选哪个？
必须选 utf8mb4。MySQL 的 utf8 是阉割版，最多存 3 字节字符，不支持 emoji、部分中文古籍字、数学符号等。而 utf8mb4 才是真正的 UTF-8 实现。
-
utf8在 MySQL 5.7 中已被标记为 legacy，官方文档明确建议迁移到utf8mb4 - 改之前确认
innodb_large_prefix为ON，innodb_file_format为BARRACUDA，否则utf8mb4下长索引可能失败 - 建新表时直接用：
CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;，别再用utf8
真正麻烦的不是改配置，而是确保从连接、传输、存储到展示，每一层都对齐 utf8mb4 —— 少一个环节，中文就可能变问号或报错。
