Navicat修改表字符集本质是执行ALTER TABLE语句，无独立图形化设置入口；修改Collation仅影响比较行为，改CHARACTER SET会重写全表数据且可能截断字符；默认勾选“转换数据”易引发误操作，推荐手动执行SQL并用SHOW CREATE TABLE核验。
Navicat里改表字符集，本质是执行ALTER TABLE语句
Navicat本身不提供独立的“表级别字符集排序”图形化设置入口。你看到的「表属性」或「设计表」界面中修改的Collation，最终都会转换为ALTER TABLE ... CONVERT TO CHARACTER SET或ALTER TABLE ... COLLATE语句执行。直接在界面上点选看似简单，但背后行为取决于你改的是哪一项、是否勾选了“转换数据”——这点极易误操作。
改字符集 vs 改排序规则（Collation），必须分清
MySQL中CHARACTER SET（如utf8mb4）和COLLATION（如utf8mb4_0900_as_cs）是两个独立属性。Navicat的下拉框常把它们混在一起显示，但实际影响不同：
- 只改
Collation（比如从utf8mb4_general_ci换成utf8mb4_0900_as_cs）：仅影响ORDER BY、GROUP BY、WHERE比较行为，不改变字段存储编码，速度较快，一般安全 - 同时改
CHARACTER SET（比如从utf8mb4换成utf8mb3）：会触发字段重定义，可能截断超长字符（如emoji）、丢失索引统计信息，且CONVERT TO会锁表并重写全表数据 - Navicat默认勾选「Convert data to the new character set」——这个选项一旦启用，哪怕你只改Collation，它也可能悄悄加
CONVERT TO，导致不必要重写
安全修改Collation的推荐做法
别依赖Navicat的「表属性」面板一键提交。用「查询」窗口手动发SQL更可控：
- 查当前表字符集和排序规则：
SHOW CREATE TABLE `your_table_name`;
- 仅改排序规则（不转字符集）：
ALTER TABLE `your_table_name` COLLATE = utf8mb4_0900_as_cs;
- 如果字段级Collation不一致（比如某些VARCHAR列自己指定了
COLLATE utf8mb4_bin），上面语句不会覆盖它们；需显式指定列：ALTER TABLE `your_table_name` MODIFY `column_name` VARCHAR(255) COLLATE utf8mb4_0900_as_cs;
- 执行前务必在测试库验证排序效果，例如：
SELECT 'a' = 'A' COLLATE utf8mb4_0900_as_cs; -- 返回0（区分大小写）
Navicat操作时最容易踩的三个坑
很多人点完「保存」就以为改完了，结果线上出问题：
- 没注意右下角弹窗提示「This operation will convert all data...」却点了「Yes」——这是Navicat在偷偷加
CONVERT TO，尤其对大表可能卡住或OOM - 在「设计表」界面改了某列的
Collation下拉值，但没点该列右侧的铅笔图标确认编辑，导致修改未真正提交到字段定义 - 用「表属性」改完后，忘记检查
SHOW CREATE TABLE输出里是否出现了CONVERT TO字样，误以为只是元数据变更
真正要改的是存储层行为，不是界面下拉框选中了就算数。每次操作后，拿SHOW CREATE TABLE核对生成的DDL，比盯着Navicat的UI更可靠。
