直接授予 GRANT ALL PRIVILEGES 极其危险，因一旦账号泄露或被注入，攻击者可执行 DROP DATABASE、读取敏感系统表甚至写入恶意 UDF；必须遵循最小权限原则，按业务需求精确授权。
为什么直接给 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() 返回客户端声明的用户，二者可能不同。
ECTouch是上海商创网络科技有限公司推出的一套基于 PHP 和 MySQL 数据库构建的开源且易于使用的移动商城网店系统！应用于各种服务器平台的高效、快速和易于管理的网店解决方案，采用稳定的MVC框架开发，完美对接ecshop系统与模板堂众多模板，为中小企业提供最佳的移动电商解决方案。ECTouch程序源代码完全无加密。安装时只需将已集成的文件夹放进指定位置，通过浏览器访问一键安装，无需对已有
用角色（ROLE）管理批量权限时，别跳过 SET DEFAULT ROLE
MySQL 8.0 支持角色，但角色默认不激活。即使你执行了：
CREATE ROLE 'report_reader';
GRANT SELECT ON sales_db.* TO 'report_reader';
GRANT 'report_reader' TO 'analyst'@'192.168.1.%';
该账号登录后仍无权限，除非显式执行：
SET DEFAULT ROLE 'report_reader' TO 'analyst'@'192.168.1.%';
否则每次连接都要手动 SET ROLE 'report_reader'，应用几乎无法稳定使用。角色不是“赋予权限就完事”，默认角色绑定这一步不可省。
最小化控制最难的不是语法，而是持续厘清“这个服务此刻真正需要哪几条 SQL”——权限策略必须随业务逻辑演进同步更新，而不是部署一次就遗忘。
