视图创建时报“Illegal mix of collations”错误的直接原因是SELECT中多个字段隐式携带不一致排序规则，需在CREATE VIEW时用CONVERT(... USING charset) COLLATE collation显式统一。
视图创建时报 ILLEGAL MIX OF COLLATIONS 错误
直接原因很明确：视图定义中 SELECT 的多个字段（尤其是来自不同表或含常量/表达式的字段）隐式携带了不一致的 collation，MySQL 在解析视图结构时就拒绝保存。这不是运行时报错，而是 CREATE VIEW 阶段失败。
常见诱因包括：
- 字段来自不同字符集的表（如一张表用
utf8mb4_unicode_ci，另一张用utf8mb4_0900_ai_ci） - SELECT 中混用了字符串常量（如
'admin'）和表字段，而常量默认继承连接层 collation - 子查询或函数返回值未显式指定排序规则，导致与外层字段 collation 不匹配
在 CREATE VIEW 中用 CONVERT 统一字段 collation
CONVERT(... USING ...) 本身不解决 collation 冲突，真正起效的是后续的 COLLATE 子句。必须组合使用，且目标 collation 必须基于对应字符集。
正确写法示例：
CREATE VIEW user_summary AS
SELECT
id,
CONVERT(name USING utf8mb4) COLLATE utf8mb4_unicode_ci AS name,
CONVERT('active' USING utf8mb4) COLLATE utf8mb4_unicode_ci AS status
FROM users;
关键点：
-
CONVERT(col USING utf8mb4)确保字节层面编码一致；COLLATE utf8mb4_unicode_ci才真正指定比较行为 - 不能只写
CONVERT(col, CHAR)—— 这是旧语法，不控制 collation，且 MySQL 8.0+ 已弃用 - 若字段本身是
TEXT或长字符串，CONVERT可能触发隐式截断，需确认目标字符集能容纳原内容
为什么不用 CAST + COLLATE？
CAST(col AS CHAR) 默认生成 CHAR 类型但不带 collation，结果仍是 “coercible”，无法消除冲突。而 CAST(col AS CHAR CHARACTER SET utf8mb4) 虽可指定字符集，但仍需额外加 COLLATE 才生效，不如 CONVERT ... COLLATE 一步到位。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
更稳妥的做法是显式声明类型长度和 collation：
CONVERT(name AS CHAR(255) CHARACTER SET utf8mb4) COLLATE utf8mb4_unicode_ci
注意：AS CHAR(255) 中的长度要覆盖字段实际最大长度，否则可能被截断 —— 这是容易被忽略的静默风险点。
视图里用 CONVERT 的真实代价
每次查询该视图时，CONVERT 操作都会重新执行，对 VARCHAR 字段影响不大，但对 TEXT 或大字段会带来额外 CPU 和临时内存开销。如果视图被高频调用，建议优先考虑修改底层表字段的 collation，而非长期依赖视图层转换。
真正省事的长期解法，是让所有参与字段在源头就统一为同一 collation —— CONVERT 只是绕过创建限制的“胶带”，不是结构设计的终点。
