MySQL权限检查按mysql.user→mysql.db→mysql.tables_priv→mysql.columns_priv顺序逐层匹配，匹配成功即放行；CREATE USER仅建账号无权限，GRANT可隐式建用户但密码为空风险高；角色是权限包需显式激活；FLUSH PRIVILEGES仅在直改系统表时必需。
MySQL权限检查顺序决定“能不能做”
MySQL不是靠单张表判断权限，而是按固定顺序逐层匹配：先查 mysql.user（全局权限）→ 再查 mysql.db（库级）→ 接着是 mysql.tables_priv（表级）→ 最后到 mysql.columns_priv（列级）。只要某一层匹配成功且权限足够，就放行；否则继续往下查。这意味着：
• 如果你在 user 表里给了 SELECT 全局权限，用户就能查所有库的所有表，哪怕 db 表里没显式授权；
• 反之，如果只在 db 表里授权但 user 表里 Select_priv='N'，且没用 GRANT 显式赋权，那该用户连登录后执行 SHOW DATABASES 都可能被拒绝（因为该命令依赖全局 SHOW DATABASES 权限）；
• host 字段不参与权限叠加，'user'@'localhost' 和 'user'@'%' 是完全独立的两条记录，权限互不影响。
GRANT和CREATE USER的区别不只是“顺手多写一句”
CREATE USER 只建账号、设密码、配资源限制（如 MAX_QUERIES_PER_HOUR），**不赋予任何权限**；而 GRANT 既可授予权限，也能隐式创建用户（MySQL 5.7+ 默认行为，但不推荐依赖）。容易踩的坑：
• 执行 GRANT SELECT ON test.* TO 'dev'@'192.168.%'; 时，若用户不存在，MySQL 会自动创建，但密码为空——这在生产环境等于裸奔；
• 更安全的做法是分两步：CREATE USER 'dev'@'192.168.%' IDENTIFIED BY 'strong_pwd';，再 GRANT SELECT ON test.* TO 'dev'@'192.168.%';；
• MySQL 8.0+ 强制要求密码强度（由 validate_password 插件控制），用弱密码建用户会直接报错 ERROR 1819 (HY000)，别硬扛，改策略或换密码。
角色（Role）不是“高级用户”，而是权限复用的开关
MySQL 8.0 引入的 ROLE 本质是权限包，不是新用户类型。它解决的是“10个开发都要查日志库”的重复授权问题：
• 先 CREATE ROLE 'log_reader';，再 GRANT SELECT ON log_db.* TO 'log_reader';；
• 然后只需 GRANT 'log_reader' TO 'dev1'@'%', 'dev2'@'%';，后续加人/删人不用重刷表权限；
• 注意：用户默认不会激活角色，需显式执行 SET DEFAULT ROLE 'log_reader' TO 'dev1'@'%';，否则登录后权限不生效；
• 角色不能嵌套（MySQL 8.0.16+ 支持 CREATE ROLE ... WITH 'role_name'，但仍是扁平结构），也**不能直接登录**——它只是权限容器。
FLUSH PRIVILEGES 什么时候必须，什么时候多余
绝大多数情况下，FLUSH PRIVILEGES 是多余的。只有当你**绕过 GRANT/CREATE USER，直接用 INSERT/UPDATE 修改 mysql.user 等系统表**时，才需要它来重载内存缓存。而所有正规授权操作（GRANT、REVOKE、DROP USER）都会自动刷新权限缓存。
• 多跑一次 FLUSH PRIVILEGES 不报错，但会触发全量权限重载，对高并发实例有短暂性能抖动；
• 常见误用场景：看到权限没立刻生效，就下意识补一句 FLUSH——其实更可能是连接用了旧账号缓存（比如 phpMyAdmin 没登出重进）、或者权限层级没覆盖到（比如只授了 db.table 却想查 db.view）；
• 真正要验证权限是否落地，用 SHOW GRANTS FOR 'user'@'host'; 比反复 FLUSH 有用得多。
权限体系看着分层清晰，但实际中真正卡住人的，往往是 host 匹配失败、角色未激活、或者误以为 GRANT 自动设了密码——这些细节不写进 SQL 日志，也不报明确错误，只能靠 SHOW GRANTS 和连接来源比对来揪。
