MySQL多用户权限分配须遵循最小权限原则,严禁直接GRANT ALL;应显式创建账号、精确授权到库表列级,敏感权限单独审批,定期清理闲置账号;社区版无原生audit_log插件,可用general_log或Percona审计插件替代;GRANT/REVOKE后无需FLUSH PRIVILEGES;跨库查询需同时授予对应库的USAGE权限。
直接给 GRANT ALL PRIVILEGES 是最常见也最危险的操作。在多用户环境中,每个账号应只拥有完成其职责所必需的数据库、表、甚至列级权限。例如运维人员不需要 FILE 权限,应用账号不应有 DROP 或 CREATE USER 权限。
实操建议:
CREATE USER 'app_rw'@'192.168.%.%' IDENTIFIED BY 'pwd123'; 显式创建账号,避免隐式创建带来的主机匹配模糊问题GRANT SELECT, INSERT, UPDATE ON mydb.orders TO 'app_rw'@'192.168.%.%';,不写 ON *.*
GRANT OPTION、PROCESS、SUPER)必须单独审批,且仅授予 DBA 账号SELECT user, host, account_locked FROM mysql.user; 检查是否存在未锁定的闲置账号MySQL 官方企业版自带 audit_log 插件,但社区版默认不包含;若强行加载会报错 Plugin 'audit_log' is not loaded。社区用户更可行的路径是使用 mysql-sys 视图配合通用查询日志(general_log),或接入外部审计工具(如 Percona Audit Plugin)。
实操建议:
SELECT VERSION();,5.7.20+ 社区版仍无原生审计插件,别浪费时间找 audit_log.so
SET GLOBAL general_log = ON;,之后查
SET GLOBAL log_output = 'table';
SELECT * FROM mysql.general_log ORDER BY event_time DESC LIMIT 100;
INSTALL PLUGIN audit_log SONAME 'audit_log.so';,路径错误会提
示 Can't open shared library
TRUNCATE TABLE mysql.general_log;
绝大多数情况下——不需要。只有直接修改 mysql.user、mysql.db 等系统表后才需要手动刷新;所有通过 GRANT、REVOKE、CREATE USER、DROP USER 发出的语句,MySQL 会自动重载权限缓存。
常见误操作与后果:
GRANT SELECT ON sales.* TO 'analyst'@'%'; 后又跑一遍 FLUSH PRIVILEGES; —— 无害但多余,还可能掩盖真正的问题(比如权限没生效其实是主机名不匹配)UPDATE mysql.user SET authentication_string = PASSWORD('new') WHERE user='root'; 修改密码后不 FLUSH PRIVILEGES; —— 新密码不会生效FLUSH PRIVILEGES; 不会释放已建立的连接权限,旧连接仍沿用旧权限,新连接才生效当用户 A 需要执行 SELECT * FROM db1.t1 JOIN db2.t2 ON ...,不仅要在 db1.t1 和 db2.t2 上分别授权,还必须确保该用户对两个库都有 USAGE 权限(即至少能“看到”这两个库)。否则会报错 ERROR 1142 (42000): SELECT command denied to user ... for table 't2',即使 t2 的权限已正确授予。
验证方式:
SHOW GRANTS FOR 'user'@'host';,确认输出中包含类似 GRANT USAGE ON `db1`.* TO 'user'@'host' 和 GRANT SELECT ON `db2`.`t2` TO 'user'@'host'
USAGE,补上:GRANT USAGE ON `db2`.* TO 'user'@'host';
USAGE 不再等价于“无权限”,而是表示“可连接但无显式权限”,它是授权体系的基础占位符权限模型本身不复杂,但真实环境里权限失效往往不是语法错,而是主机名匹配、库级 USAGE 缺失、插件版本错配这些细节卡住。审计不是开了日志就完事,得想清楚谁看、怎么看、看多久——日志存三天和存三个月,对存储、归档、合规都是完全不同的约束。