ALTER TABLE … MODIFY COLUMN 会清空字段默认值，必须显式重申DEFAULT及所有约束；CONVERT TO会统一覆盖列级COLLATE且隐式锁表；latin1存中文乱码时直接转utf8mb4无效，需先导出再转码修复。
ALTER TABLE … MODIFY COLUMN 会丢默认值
直接用 MODIFY COLUMN 改字符集，MySQL 5.7 默认会清空字段的 DEFAULT 值。比如原字段是 name VARCHAR(50) DEFAULT 'unknown'，执行 MODIFY name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 后，DEFAULT 就没了——Java 应用读取元数据时可能报错或行为异常。
正确做法是显式带出默认值：ALTER TABLE t1 MODIFY COLUMN name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'unknown';
- 所有约束（
NOT NULL、COMMENT）也得手动补全，否则会被重置 - 如果字段有
GENERATED表达式或ENUM/SET枚举值，必须原样保留定义，只改CHARACTER SET和COLLATE
CONVERT TO 不等于逐列修改
ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 看似方便，但它会对整张表所有字符型列（VARCHAR、TEXT 等）统一应用新字符集和默认排序规则，且忽略列级已有的 COLLATE 设置。
例如某列原本是 title VARCHAR(100) COLLATE utf8mb4_bin，执行 CONVERT TO 后会变成 utf8mb4_unicode_ci，大小写敏感性就变了，WHERE 查询结果可能不一致。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 查列级 collation：用
SHOW CREATE TABLE t1或查information_schema.COLUMNS的COLUMN_COLLATION字段 - 想保留原 collation？只能单列
MODIFY，不能偷懒用CONVERT TO -
CONVERT TO还会隐式重建表，大表要锁表，生产环境慎用
latin1 列转 utf8mb4 可能触发数据截断
如果原列是 latin1 编码，但存了中文（靠客户端“硬塞”进去），实际字节序列已是乱码。此时直接 MODIFY 成 utf8mb4，MySQL 不会解码重编码，只是把原来错误的字节当 utf8mb4 解释——结果仍是乱码，甚至因字节长度超限被截断。
典型现象：SELECT LENGTH(name), CHAR_LENGTH(name) 返回值不等（比如 6 vs 3），说明存储的是多字节乱码。
- 安全做法：先用原始编码导出数据（如用
mysqldump --default-character-set=latin1），再用工具转成 utf8mb4 编码，最后导入 - 小数据量可试
CONVERT(CAST(CONVERT(name USING latin1) AS BINARY) USING utf8mb4)，但需逐行验证结果 - 别依赖
ALTER COLUMN ... CONVERT TO自动修复已损坏数据
连接层 collation 影响 WHERE 和 ORDER BY 结果
即使列本身是 utf8mb4_unicode_ci，如果客户端连接时没设对，比如用 SET NAMES latin1 或 JDBC URL 漏了 characterEncoding=utf8mb4，那 WHERE name = '张' 或 ORDER BY name 仍按 latin1 规则比较——排序错乱、大小写匹配异常都可能发生。
验证方法：SELECT @@character_set_client, @@collation_connection; 必须和列的 COLLATION 兼容。
- 临时修复：连接后立刻执行
SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci - 永久方案：在
my.cnf的[client]和[mysql]段加default-character-set=utf8mb4，并确保应用连接参数同步 - 注意：
collation_connection优先级高于列 collation，用于表达式和临时结果排序
