Navicat 16 表设计器中字段级 COLLATION 不可编辑，因其被设计为派生属性，自动继承自表、数据库或服务器默认校对规则；如需修改，必须手写 ALTER TABLE MODIFY COLUMN 语句显式指定。
navicat 16 无法直接在表设计界面为单个字段设置 collation —— 它只允许修改字段的 character set，而 collation 会自动继承自字符集或表级默认值。
为什么字段级 Collation 设置被隐藏了？
MySQL 的 ALTER TABLE ... MODIFY COLUMN 语法确实支持显式指定 COLLATE，但 Navicat 16 的「表设计器」（即右键表 → “设计表”）在字段属性面板中，Collation 下拉框是灰色不可编辑状态。这不是 Bug，而是设计限制：Navicat 把字段校对规则视为“派生属性”，交由表或服务器层级统一管控。
常见误操作是反复点击字段属性里的 Collation 行，试图下拉选择 —— 实际上它只是只读显示，值来源于：
– 字段定义时未显式指定，则取自表的 DEFAULT COLLATE；
– 表未指定，则取自数据库的 DEFAULT COLLATE；
– 数据库未指定，则取自 MySQL 服务器的 collation_server。
绕过 GUI：用 SQL 直接修改字段 Collation
要真正改变某个字段的校对规则，必须手写 ALTER TABLE 语句。Navicat 16 支持在「查询」窗口执行，且能正确解析含 COLLATE 的 DDL：
- 确保目标字段类型支持该
COLLATION（例如utf8mb4_0900_as_cs只适用于utf8mb4字符集） - 字段不能是主键/索引的一部分且当前正在被外键引用（否则 ALTER 可能失败）
- 执行前建议先备份：用「转储 SQL」导出表结构 + 数据
示例（将 users.name 字段改为大小写敏感、重音敏感排序）：
ALTER TABLE users MODIFY COLUMN name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs;
注意：MODIFY COLUMN 会重建字段，若表很大，操作期间可能锁表；CHANGE COLUMN 效果相同，但需重复写字段名。
同步场景下 Collation 不一致引发报错怎么办？
使用 Navicat 的「结构同步」功能时，如果源库字段用的是 utf8mb4_0900_ai_ci，目标库对应字段却是 utf8mb4_general_ci，勾选了 Compare collation 就会生成 ALTER 语句 —— 但该语句在目标库执行可能失败，因为 MySQL 拒绝在某些引擎（如 MyISAM）或旧版本中变更已存在字段的 COLLATION。
安全做法是：
- 在「结构同步 Options」中取消勾选
Compare collation（尤其跨 MySQL 版本或混合引擎时） - 手动确认两边表的
DEFAULT COLLATE是否一致：SHOW CREATE TABLE table_name - 若必须统一字段级
COLLATION，宁可分两步：先改表默认值（ALTER TABLE ... CONVERT TO CHARACTER SET ... COLLATE ...），再单独跑一次字段级MODIFY
容易忽略的兼容性陷阱
MySQL 8.0.1+ 默认 COLLATION 是 utf8mb4_0900_ai_ci，但它和老版本的 utf8mb4_general_ci 不完全兼容：
- 前者区分重音（à ≠ a），后者不区分；前者对表情符号排序更准，但性能略低
-
utf8mb4_0900_as_cs（大小写+重音敏感）不能用于索引前缀长度 > 3072 字节的字段（InnoDB 限制） - Navicat 自动补全或语法检查不会报
COLLATE错误，但执行时报Illegal mix of collations才暴露问题
真正要稳住字段级 COLLATION，靠的不是点几下鼠标，而是控制好表定义源头、关掉同步里那些“看似合理实则危险”的比较开关，并接受——必要时就得写 SQL。
