在MySQL中，权限管理并不是简单地给某个账号开个远程连接就行。它本质上是一套以用户、客户端主机、目标数据库对象以及具体操作类型为核心的访问控制体系。当多个业务系统、多名开发人员或运维人员同时连接同一个MySQL实例时，如果账号权限划分模糊，轻则造成误删数据，重则导致整个实例被拖库。因此，理解MySQL的权限层级并落实多用户环境的最佳实践，是每一个后端团队都必须掌握的功课。
一、MySQL权限体系的基础结构
MySQL的权限控制分为全局层级、数据库层级、表层级、列层级以及例程层级。全局权限存储在mysql.user表中，影响整个实例；数据库权限在mysql.db里定义，只对指定库生效；表和列权限则进一步细化到某张表或某些字段。这种设计允许我们根据实际需要，把权限精确到“某个用户从某台机器连接进来，只能查某张表的某几列”。
当用户发起连接时，MySQL首先校验user表的Host和Password，确认身份合法后，再按照“范围最小优先”的原则合并各层级权限。也就是说，如果在全局给了SELECT，又在数据库层收回了它，实际生效的是数据库层的限制。理解这一合并逻辑，才能避免“明明回收了权限却还能访问”的困惑。
1.1 用户与主机的关系
MySQL中的用户并非孤立存在，而是由用户名和主机名共同组成，例如 'dev'@'192.168.0.1' 与 'dev'@'%' 是两个完全不同的账号。很多初学者误以为创建一个dev用户就能从任何地方登录，结果在授权时只写了CREATE USER dev IDENTIFIED BY 'pwd'，系统默认主机为%，带来极大暴露面。
在多用户环境中，建议明确限定来源主机。比如内部后台服务部署在192.168.0.1，那就只建'api'@'192.168.0.1'，而不是开放'%'。这样即便密码泄露，攻击者也必须在指定网络位置才能利用。
二、最小权限原则落地
最小权限原则要求每个账号仅拥有完成自身任务所必须的权限，不多也不少。在多用户场景下，常见的角色包括：只读分析人员、业务写入服务、运维管理员以及临时调试人员。他们对应的权限集合差异很大，绝不能统一使用root。
举例来说，报表系统只需要查数据，那就只给SELECT；订单服务需要写入和更新，给INSERT、UPDATE、DELETE，但绝不需要DROP。通过这种拆分，即使某个业务账号被攻破，损失也被限制在单一业务域内。
2.1 使用GRANT语句精确授权
下面是一段典型的授权代码，为报表账号限定在192.168.0.1主机，只开放test库下所有表的查询权：
-- 创建只读账号，限定来源IP CREATE USER 'report'@'192.168.0.1' IDENTIFIED BY 'StrongPass_2023'; -- 仅授予test库下所有表的SELECT GRANT SELECT ON test.* TO 'report'@'192.168.0.1'; -- 刷新权限使变更生效 FLUSH PRIVILEGES;
上述代码中，test.*表示test库的全部表，若只想开放某表，可写成test.orders。注意GRANT执行后，在部分版本需FLUSH PRIVILEGES，但在使用CREATE USER和GRANT标准语法时，MySQL通常会自动落地，不过显式刷新仍是稳妥习惯。
与之相对，下面这种写法应当杜绝：
-- 危险示范：任意主机、全部权限 CREATE USER 'app'@'%' IDENTIFIED BY '123456'; GRANT ALL PRIVILEGES ON *.* TO 'app'@'%';
该账号可从任意地址用弱密码连接，并掌控所有库表，一旦泄漏，整个实例毫无防备。
三、利用角色简化多用户管理
MySQL 8.0引入了角色（Role）机制，可以把一组权限打包，再赋给多个用户。当团队规模扩大，手动逐个GRANT极易混乱，角色能显著降低运维复杂度。
比如定义一个只读角色和读写角色，新来的分析人员直接授予只读角色即可，无需关心底层具体库表。如果后期调整权限，只需修改角色，所有关联用户自动继承变更。
3.1 角色创建与绑定示例
以下示例展示如何建立role_readonly并指派给两个用户：
-- 创建角色 CREATE ROLE 'role_readonly'; -- 给角色授权 GRANT SELECT ON test.* TO 'role_readonly'; -- 创建两个用户 CREATE USER 'analyst1'@'192.168.0.1' IDENTIFIED BY 'Pwd1'; CREATE USER 'analyst2'@'192.168.0.1' IDENTIFIED BY 'Pwd2'; -- 将角色授予用户 GRANT 'role_readonly' TO 'analyst1'@'192.168.0.1'; GRANT 'role_readonly' TO 'analyst2'@'192.168.0.1'; -- 设置默认角色，登录即生效 SET DEFAULT ROLE 'role_readonly' TO 'analyst1'@'192.168.0.1', 'analyst2'@'192.168.0.1';
使用角色后，权限审计也变得更清晰：只需检查角色定义，就能知道一类人拥有什么能力，而不必翻查每个用户条目。
需要提醒的是，角色在5.7及更早版本中不存在，老版本只能通过视图或脚本模拟，迁移到8.0是更优选择。
四、密码策略与连接安全
权限控得再细，如果密码是弱口令或连接明文传输，依然形同虚设。MySQL提供validate_password组件，可强制密码长度、复杂度和过期时间。
同时，多用户环境应要求非本地连接使用SSL。通过在创建用户时指定REQUIRE SSL，可避免账号密码在公网或内网被嗅探。
4.1 强制SSL连接示例
下面代码创建一个必须使用SSL的服务账号：
CREATE USER 'service'@'192.168.0.1' IDENTIFIED BY 'Complex_Str_99' REQUIRE SSL; GRANT INSERT, UPDATE ON test.orders TO 'service'@'192.168.0.1';
如果该用户尝试用未加密连接登录，服务器会直接拒绝。结合内部的CA证书分发，能够在不改造业务代码太多的情况下提升链路安全。
此外，定期用ALTER USER修改密码、设置PASSWORD EXPIRE INTERVAL，能减少长期不动账号带来的隐患。
五、日常审计与权限回收
多用户环境运行一段时间后，难免出现人员离职、业务下线的情况。若不及时回收权限，账号就成了僵尸入口。MySQL的mysql.user、mysql.db等系统表记录了全部授权，可周期性导出比对。
也可以直接查询information_schema.USER_PRIVILEGES来查看全局权限分布。发现可疑账号，用DROP USER或REVOKE清理。
5.1 查看与回收权限
查看某用户权限的命令如下：
-- 显示用户权限 SHOW GRANTS FOR 'report'@'192.168.0.1'; -- 回收某库的写权限 REVOKE INSERT, UPDATE, DELETE ON test.* FROM 'report'@'192.168.0.1';
REVOKE只会去掉指定权限，不影响其他授权。对于彻底离线的账号，更推荐DROP USER，连用户记录一起清除，防止被再次启用。
建议把权限审计写入运维巡检脚本，每月输出一份账号清单，由安全负责人复核，形成闭环。
六、常见误区与总结
一个典型误区是“开发环境随便给权，上线再收”。实际上，开发期使用的_dump工具、ORM框架常依赖特定权限，临上线才改容易引发故障。正确做法是环境间采用同样的最小权限标准，仅IP和白名单不同。
另一个误区是忽视host维度。很多团队只允许root本地登录，却给业务账号开了%，却没限制业务部署网段，等于变相扩大攻击面。通过结合网络隔离与MySQL自身host限定，才能构建纵深防御。
总体而言，MySQL多用户环境的最佳实践可以归纳为：按业务分账号、按主机限来源、按角色管权限、按SSL保传输、按周期做审计。把这五点融入日常流程，即便团队扩张、系统增多，数据库依然能维持在可控的安全水位。