MariaDB 10.0 与 MySQL 在用户角色权限管理上的核心区别在于底层权限表结构、认证插件默认配置及角色实现机制不同。MariaDB 10.0 基于 MySQL 5.5 架构开发并融合了部分 5.6 特性，但自 10.4 版本起 mysql.host 表失效，且默认认证插件与 MySQL 8.0 的 caching_sha2_password 不兼容，直接迁移用户权限可能导致静默降权或登录失败。

命令速用版

以下命令用于快速检查当前数据库的用户权限结构与认证方式，适用于 MariaDB 10.0+ 与 MySQL 5.6/8.0 环境对比。

-- 查看当前用户及认证插件
SELECT user, host, plugin FROM mysql.user;

-- 查看特定用户权限
SHOW GRANTS FOR 'username'@'localhost';

-- 检查 host 表是否生效 (MariaDB 10.4+ 返回空或不读取)
SELECT * FROM mysql.host;

-- 修改认证插件以兼容客户端 (若遇到 Access denied)
ALTER USER 'username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';

为什么会这样

MariaDB 与 MySQL 权限体系差异源于代码库分叉后的独立演进路径。MariaDB 10.0 并未直接基于 MySQL 5.6 代码库开发，而是以 MySQL 5.5 为基础整合了新特性，导致底层文件结构与权限表定义出现分歧。

MySQL 5.6 起移除了 mysql.host 表，而 MariaDB 保留该表定义但在 10.4+ 版本中不再读取其内容，权限判定仅依赖 mysql.user、mysql.db 和 mysql.tables_priv。此外，MySQL 8.0 默认启用 caching_sha2_password 认证插件，而 MariaDB 10.4+ 仍默认使用 mysql_native_password，这种协议不匹配是导致迁移后连接报错的主要原因。角色管理方面，MySQL 8.0 引入 role_edges 和 default_roles 表实现原生角色继承，而 MariaDB 在相同版本区间内采用不同的系统表结构实现角色功能，两者无法直接互通。

分步处理

在迁移或对比权限体系时，按以下步骤操作可避免权限丢失或连接失败。

步骤 1：导出前检查认证插件
在源 MySQL 实例执行 SELECT user, host, plugin FROM mysql.user;。若发现 plugin 列为 caching_sha2_password，迁移至 MariaDB 前需显式指定插件类型，否则目标库可能无法识别密码哈希。

步骤 2：验证 host 表依赖
若现有权限体系依赖 mysql.host 表进行细粒度控制，需知悉 MariaDB 10.4+ 不再读取该表。所有权限应收敛至 mysql.db 或 mysql.user 表，避免迁移后权限失效。

步骤 3：角色权限重构
若使用 MySQL 8.0 的角色功能，迁移至 MariaDB 后需重新创建角色并授权。不要直接导入 mysql.role_edges 表数据，因为 MariaDB 无对应原生表结构，需通过 GRANT 语句重新分配权限。

步骤 4：客户端兼容性测试
使用旧版 PDO 或 MySQL Connector/J 8.0 以下版本连接时，若服务端启用了 caching_sha2_password，需确保客户端支持或服务端降级为 mysql_native_password。

怎么验证是否生效

执行权限变更后，通过以下方法确认配置已生效且无副作用。

1. 登录验证
使用新密码或迁移后的账号尝试登录，若报 ERROR 1045 (28000): Access denied，检查认证插件是否匹配。

2. 权限粒度检查
执行 SHOW GRANTS FOR 'username'@'host';，对比迁移前后输出结果。重点关注 SUPER 权限及库级权限是否一致，MariaDB 对 SUPER 权限的实际约束范围可能与 MySQL 存在偏差。

3. 日志审计
查看数据库错误日志，确认无 Authentication plugin 相关报错。若客户端报 Client does not support authentication protocol requested by server，说明插件协商失败。

常见坑

• 静默降权风险：直接导入 mysql.user 表数据可能导致权限字段不兼容，建议使用 mysqldump 导出权限语句而非直接拷贝表文件。
• Host 表失效：在 MariaDB 10.4+ 中手动 INSERT INTO mysql.host 不会生效，权限判定仅依赖 user 表和 db 表。
• 角色继承断裂：MySQL 8.0 的角色边表（role_edges）无法在 MariaDB 中使用，迁移后角色继承关系需应用层重新模拟或通过 GRANT 重建。
• 密码过期字段：MariaDB 的 user 表多出 password_expired 等字段，MySQL 5.7+ 才逐步补全，跨版本迁移时需注意字段映射。

常见问题

MariaDB 10.0 能直接替代 MySQL 5.6 吗？

基本可以，但需注意权限表结构差异。MariaDB 10.0 旨在兼容 MySQL 5.6 的 API 和命令行，但底层代码文件结构已改动，权限体系存在细微差别，迁移前需测试权限生效情况。

为什么迁移后出现 Access denied 错误？

通常是认证插件不匹配导致。MySQL 8.0 默认使用 caching_sha2_password，而 MariaDB 默认使用 mysql_native_password，需显式指定插件或升级客户端驱动。

MariaDB 支持 MySQL 8.0 的角色功能吗？

支持角色管理，但底层实现不同。MariaDB 无 mysql.role_edges 表，角色继承机制不兼容 MySQL 8.0 的原生表结构，需重新配置权限。

如何确认 host 表是否在生效？

在 MariaDB 10.4+ 中 host 表已失效。可通过修改 host 表内容后尝试登录验证，若权限未变化则说明系统不再读取该表，应改用 db 表控制库级权限。

参考来源

• 如何对比 MariaDB 与 MySQL 在用户权限体系上的核心区别？
• MariaDB 10.0 和 MySQL 5.6 有何不同 - 读书 - 博客园
• mariadb 与 mysql 的区别有哪些
• MariaDB 与 MySQL 有什么区别？
• 云数据库 mariadb 和 MySQL 的区别