MySQL 用户权限按全局→数据库→表→列→存储过程层级收敛，推荐从数据库级授权起始，禁用 GRANT ALL ON .；MySQL 8.0+ 角色机制提升权限管理可靠性，支持嵌套与默认启用，需 SET DEFAULT ROLE 生效；权限验证须结合 SHOW GRANTS、information_schema 查询及运行时测试。
MySQL 用户级权限如何精确授予
MySQL 权限不是“开或关”的二元选择，而是按层级（全局 → 数据库 → 表 → 列 → 存储过程）逐级收敛。最常用且安全的做法是从 ** 数据库级 ** 开始授权，避免直接用 GRANT ALL ON *.*——这等于把 root 权限让渡给普通用户。
实操建议：
- 新建用户后，先用
CREATE USER 'app_user'@'192.168.1.%' IDENTIFIED BY 'strong_pass';明确限定可连接的 IP 段 - 再执行
GRANT SELECT, INSERT, UPDATE ON mydb.* TO 'app_user'@'192.168.1.%';，不授DELETE或DROP，除非业务真需要 - 敏感表（如
user_auth）可单独收紧：REVOKE UPDATE ON mydb.user_auth FROM 'app_user'@'192.168.1.%'; - 执行完必须跟
FLUSH PRIVILEGES;，否则权限变更不生效（尤其在直接操作mysql.user表后）
为什么用角色（ROLE）比反复 GRANT 更可靠
MySQL 8.0+ 支持 CREATE ROLE，本质是权限包的抽象。它解决的是“人变权限变、权限多人共用”时的手动同步难题。不用角色时，一个开发离职、一个新 DBA 入职，你得翻 5 张表手动加减权限；用角色，只需 GRANT dev_role TO 'zhangsan'@'%'; 一行搞定。
关键点：
- 角色本身无登录能力，必须
SET DEFAULT ROLE dev_role FOR 'zhangsan'@'%';才能默认启用 - 角色权限可嵌套：
GRANT read_only_role TO audit_role;，适合审计组继承只读权限 - 禁止对角色授
PROXY权限，否则可能绕过认证链 - 查看当前用户有效权限用
SHOW GRANTS FOR CURRENT_USER();，不是CURRENT_USER函数值
常见权限误配导致的错误现象
权限问题往往不报“Access denied”，而是抛出看似无关的错误，比如 ERROR 1449 (HY000): The user specified as a definer ('sys'@'localhost') does not exist——这其实是函数 / 视图定义者账号被删或权限不足，不是当前用户没权限。
高频踩坑场景：
-
SELECT报错但SHOW CREATE TABLE正常？检查是否缺SELECT权限，而非SHOW VIEW - 存储过程执行失败，错误含
EXECUTE command denied：需单独授EXECUTE ON PROCEDURE mydb.my_proc，USAGE不包含它 - 用
mysqldump备份时报Access denied for table mysql.columns_priv：备份用户必须有SELECT权限，且不能被REVOKE掉系统库访问（除非用--skip-lock-tables+--single-transaction） - 主从复制中断，错误为
Replication requires SUPER or REPLICATION CLIENT privilege：从库用户至少要REPLICATION SLAVE，不是SUPER
权限回收与最小化验证怎么做
授出去的权限容易，收回来难。MySQL 不记录“谁在什么时候授了什么”，所以权限治理必须靠外部记录或自动化扫描。线上环境应定期跑脚本验证“最小权限原则”是否被破坏。
快速验证方法：
- 查用户实际使用权限：
SELECT host,user,Select_priv,Insert_priv,Update_priv,Delete_priv FROM mysql.user WHERE user='app_user'; - 查某用户所有显式授权：
SELECT * FROM mysql.db WHERE user='app_user';（注意：db 级权限优先级高于全局） - 模拟用户视角看权限：
SELECT * FROM information_schema.role_table_grants WHERE grantee="'app_user'@'%'; - 真正关键的是运行时验证——用该用户连接后，执行
SELECT COUNT(*) FROM information_schema.tables;，若报错说明SELECT权限未覆盖information_schema（通常不需要，但某些监控工具会读）
权限配置没有银弹，最易被忽略的是「权限继承路径」：比如用户有 SELECT on database A，又通过角色继承了 UPDATE on table A.t1，那他对 t1 实际拥有 SELECT + UPDATE，但 SHOW GRANTS 默认不展开角色内容，得加 USING dev_role 才能看到全貌。
