MySQL权限系统分5层：全局层（.）、数据库层（db_name.*）、表层（db_name.table_name）、列层（(col1,col2)）、存储过程层（PROCEDURE db_name.sp_name），需精准对应GRANT语句位置与生效范围。
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 按字符顺序逐条匹配权限行，最长匹配优先——这个细节线上排障时经常被忽略。
