为什么直接给 GRANT ALL PRIVILEGES
是危险的
生产环境里，用
GRANT ALL PRIVILEGES ON *.* TO 'user'@'%'看似省事，实则埋下严重隐患：一旦该账号凭证泄露或应用被注入，攻击者可直接
DROP DATABASE、读取
mysql.user表、甚至写入恶意 UDF。最小化访问控制不是“多一事不如少一事”，而是明确“这个账号只做这一件事”。
按业务动作精确授权，而不是按表名粗粒度放行
比如一个订单查询服务，它不需要
INSERT或
DELETE权限，也不该能访问用户密码字段。实际操作中应分层控制： 只授予具体数据库（如
orders_db），避免用
*.*只授予必要语句类型：
SELECT通常足够，慎开
UPDATE，禁用
FILE、
PROCESS、
SUPER等高危权限 敏感字段用视图隔离：创建只暴露
order_id、
status、
created_at的视图
v_order_summary，再对应用账号授予该视图的
SELECT连接来源限制：用
'app_user'@'10.20.30.%'替代
'app_user'@'%'
REVOKE
后权限没立即失效？注意 FLUSH PRIVILEGES
的误区
MySQL 8.0+ 中，
REVOKE和
GRANT操作会立即生效，无需手动
FLUSH PRIVILEGES；但如果你是直接修改
mysql.user或
mysql.tables_priv系统表（不推荐），才需要刷新。常见错误是误以为“改了就得刷”，结果在脚本里冗余执行，反而引发锁表风险。
验证权限是否生效，用目标账号登录后执行：
SHOW GRANTS FOR CURRENT_USER;
注意：
CURRENT_USER()返回的是认证用户（即
'user'@'host'），而
USER()返回客户端声明的用户，二者可能不同。
用角色（ROLE）管理批量权限时，别跳过 SET DEFAULT ROLE
MySQL 8.0 支持角色，但角色默认不激活。即使你执行了：
CREATE ROLE 'report_reader';<br>GRANT SELECT ON sales_db.* TO 'report_reader';<br>GRANT 'report_reader' TO 'analyst'@'192.168.1.%';
该账号登录后仍无权限，除非显式执行：
SET DEFAULT ROLE 'report_reader' TO 'analyst'@'192.168.1.%';
否则每次连接都要手动
SET ROLE 'report_reader'，应用几乎无法稳定使用。角色不是“赋予权限就完事”，默认角色绑定这一步不可省。
最小化控制最难的不是语法，而是持续厘清“这个服务此刻真正需要哪几条 SQL”——权限策略必须随业务逻辑演进同步更新，而不是部署一次就遗忘。
