为什么mysql的表字段的collation会自动变

MySQL 表字段的 collation（排序规则）看起来"自动变了"或者"没按预期生效"，通常是因为 MySQL 拥有一套严格的四级继承机制 ，以及在进行表结构变更时触发了隐式转换。

具体原因和背后的逻辑如下：

1. MySQL 的四级继承机制

MySQL 在确定一个字段最终使用什么 collation 时，遵循"自上而下"的继承原则。如果你没有在最底层（字段层）显式指定，它就会自动向上寻找默认值：

• 服务器级 (Server) ：全局默认值（如 utf8mb4_0900_ai_ci）。
• 数据库级 (Database)：创建库时指定的默认值，若未指定则继承服务器。
• 表级 (Table)：创建表时指定的默认值，若未指定则继承数据库。
• 列级 (Column) ：定义字段时指定的值，若未指定则自动继承表的默认值。

2. 为什么会出现"自动变"的情况？

• 情况一：新建字段时未指定
  如果你修改了数据库或表的默认 collation，但在新建字段时没有显式写出 COLLATE xxx，MySQL 就会自动把当前表的默认 collation 赋予该字段。这看起来就像是字段"自动"变了。
• 情况二：执行了 CONVERT TO 操作
  当你执行类似 ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8mb4; 的命令时，MySQL 不仅会修改表的默认字符集，还会自动把表中所有已有字段的字符集和排序规则也一并转换成新的规则。
• 情况三：隐式转换与连接查询
  如果两个字段在 JOIN 或 WHERE 比较时 collation 不一致，MySQL 可能会在查询过程中进行隐式转换，甚至抛出"非法混合排序规则 (Illegal mix of collations)"的错误。

3. 如何精准控制字段的 collation？

如果你希望某个字段（比如存密码、激活码等对大小写敏感的字段）保持特定的排序规则，不被表或库的默认设置影响，必须在定义字段时显式指定。

例如，强制指定某个字段为区分大小写的二进制排序规则：

1ALTER TABLE your_table 
2MODIFY your_column VARCHAR(100) COLLATE utf8mb4_bin NOT NULL;

💡 避坑建议：

• 保持统一 ：在开发初期，尽量让服务器、数据库、表和字段的 collation 保持统一（推荐 MySQL 8.0+ 使用 utf8mb4_0900_ai_ci 或 utf8mb4_bin），避免隐式转换带来的性能损耗和潜在 Bug。
• 敏感字段特殊对待 ：对于验证码、Token、Base64 字符串等强依赖大小写的字段，务必显式设置为 _bin 结尾的排序规则。
• 谨慎使用 CONVERT TO：在已有大量数据的表上执行该命令会重写全表数据，不仅耗时长，还可能导致字段的排序规则发生意料之外的变更。