mysql报错illegal mix of collations不直接影响权限判断，仅发生在字符串运算场景，权限检查走独立系统表路径；但可能间接干扰存储过程校验、动态sql执行和跨库视图查询等权限相关逻辑。
MySQL报错Illegal mix of collations本身不直接影响权限判断
这个错误和权限系统完全无关——它只发生在字符串比较、JOIN、ORDER BY、WHERE条件等涉及字符值运算的场景里，而权限检查走的是另一套独立路径（查mysql.user、mysql.db等系统表，比对CURRENT_USER()）。你看到报错时权限早已通过或拒绝，不会因为collation冲突导致“本该有权限却报错”或“本不该有权限却放行”。
但collation冲突可能间接干扰权限相关逻辑的执行
常见于以下三类实际场景：
- 存储过程或函数中做用户身份校验时用了字符串比较（比如
IF input_user = stored_user_name THEN ...），而stored_user_name字段是utf8mb4_0900_ai_ci，传入参数却是utf8mb4_general_ci，直接卡在=操作上，后续权限分支根本没机会执行 - 动态SQL拼接权限查询语句（如
CONCAT('SELECT * FROM ', db_name, '.users WHERE role = ''', role_val, '''')），如果role_val字面量和role字段collation不一致，整个EXECUTE失败，权限判断逻辑中断 - 视图定义里包含跨库JOIN，其中一库用
latin1_swedish_ci，另一库用utf8mb4_unicode_ci，视图创建成功但查询时报Illegal mix of collations——这时你误以为是“SELECT权限不足”，其实根本没走到权限校验那步，SQL解析阶段就崩了
为什么有人觉得“改collation_server能解决权限问题”
这是典型混淆因果：
-
collation_server只影响新连接的collation_connection初始值，对已存在的表字段collation无效 - 如果某应用连上后不做
SET NAMES，又恰好用latin1客户端发UTF-8中文参数，MySQL尝试隐式转换失败，报Illegal mix of collations；此时调高collation_server可能让连接默认用utf8mb4，看似“修复了”，实则只是掩盖了连接层未显式声明字符集的问题 - 真正该做的是：在应用连接串里加
?charset=utf8mb4，或登录后立刻执行SET NAMES utf8mb4 COLLATE utf8mb4_0900_ai_ci（注意必须带COLLATE）
排查时最易被忽略的点
不是看SHOW CREATE TABLE，而是查information_schema.COLUMNS里每个字段真实的COLLATION_NAME——因为字段级collation可以覆盖表级定义，且存储过程里的变量、临时表字段、函数返回值都继承连接collation，和字段未必一致。一旦混用，=、IN、LIKE全会挂，而你还在查GRANT语句有没有写错。
