MySQL 权限管理不是“开个账号、赋个
GRANT ALL”就完事的，面试官真正想看的是你是否理解权限分层逻辑、最小权限原则落地细节，以及在真实运维中踩过哪些坑。
MySQL 权限系统分几层？每层对应哪些关键字？
权限按作用域从大到小分为 5 层，必须能准确对应到
GRANT语句里的位置和生效范围： 全局层（
*或
*.*）：影响所有数据库，如
CREATE USER、
RELOAD、
SHUTDOWN数据库层（
db_name.*）：仅对该库内所有对象生效，不包含库本身操作（如
DROP DATABASE需要全局权限） 表层（
db_name.table_name）：可精确到某张表的
SELECT/
INSERT，但注意
ALTER和
INDEX必须在表层或更高层显式授予 列层（
(col1,col2)列表）：仅对指定列生效，常被忽略——比如
GRANT SELECT (name,age) ON users TO 'app'@'%'存储过程/函数层（
PROCEDURE db_name.sp_name）：需单独授权
EXECUTE，且调用者权限检查发生在执行时，不是定义时
容易错的是：以为给
SELECT就能查视图——其实视图依赖底层表权限，且若视图含
DEFINER，还会触发定义者的权限上下文。
为什么 GRANT ... WITH GRANT OPTION
很危险？
它允许被授权者把**相同权限**再转授他人，但不等于“能授任意权限”。关键点：
只能转授自己**直接获得**的权限，不能叠加（A 有SELECT+
INSERT，不能只转授
SELECT给 B 再让 B 转授
INSERT给 C）
WITH GRANT OPTION不会自动继承到新用户；若 A 被撤销权限，B 的权限**不会级联失效**（MySQL 不做反向追踪） 最常出问题的场景：DBA 给应用管理员开了
GRANT OPTION，结果后者误给测试账号开了
ALL PRIVILEGES，又忘了回收
线上环境应禁用该选项，改用集中化权限申请流程。
FLUSH PRIVILEGES
什么时候必须执行？
绝大多数情况下**不需要手动执行**。只有当直接修改
mysql系统库的权限表（如
INSERT INTO mysql.user）后才需要它来重载内存缓存。而通过
GRANT/
REVOKE操作，MySQL 会自动刷新权限缓存。
常见误解：
改完my.cnf里的
skip-grant-tables后执行
FLUSH PRIVILEGES——无效，那是启动参数，需重启 mysqld 新建用户后立即执行
FLUSH PRIVILEGES——多余，
CREATE USER已完成权限初始化 遇到“Access denied”立刻
FLUSH——大概率是权限没写对（比如主机名匹配失败、大小写敏感、未指定数据库），先查
SHOW GRANTS FOR 'u'@'h'
如何快速定位某个用户到底有没有某条权限？
别靠猜，用三步法验证：
查该用户当前拥有的全部权限：SHOW GRANTS FOR 'user'@'host'确认权限是否覆盖目标操作：比如要执行
TRUNCATE TABLE t，本质是
DROP+
CREATE，需同时有表层
DROP和
CREATE权限（或更高层） 模拟检查（8.0+）：
SELECT * FROM INFORMATION_SCHEMA.ROLE_TABLE_GRANTS WHERE GRANTEE = "'user'@'host'" AND TABLE_SCHEMA = 'db' AND TABLE_NAME = 't';，比
SHOW GRANTS更细粒度
特别注意 host 匹配规则：
'user'@'192.168.%'不等价于
'user'@'192.168.1.100'，MySQL 按字符顺序逐条匹配权限行，最长匹配优先——这个细节线上排障时经常被忽略。
