MySQL多用户权限分配须遵循最小权限原则，严禁直接GRANT ALL；应显式创建账号、精确授权到库表列级，敏感权限单独审批，定期清理闲置账号；社区版无原生audit_log插件，可用general_log或Percona审计插件替代；GRANT/REVOKE后无需FLUSH PRIVILEGES；跨库查询需同时授予对应库的USAGE权限。
MySQL 多用户权限分配必须基于最小权限原则
直接给 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 审计需避开插件兼容性陷阱
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; - 若用 Percona 版本，加载前确认插件路径：
INSTALL PLUGIN audit_log SONAME 'audit_log.so';，路径错误会提示Can't open shared library - 审计日志量极大，务必限制保留周期，避免填满磁盘——通用日志表不能自动轮转，需定时
TRUNCATE TABLE mysql.general_log;
权限变更后必须执行 FLUSH PRIVILEGES 吗？
绝大多数情况下——不需要。只有直接修改 mysql.user、mysql.db 等系统表后才需要手动刷新；所有通过 GRANT、REVOKE、CREATE USER、DROP USER 发出的语句，MySQL 会自动重载权限缓存。
1.) 将所有文件解压到php环境中，本程序才用smarty+php+mysql设计。如果运行不了，请修改hhy文件夹下的smarty.php文件改法请看说明2.) 修改configs下的config.inc.php下的连接数据库的密码和用户名3.) 本程序没有做安全页面，人工导入sql.inc到mysql数据库。管理员初始化帐号为admin，密码为hhy。后台地址：http://你的网站地址/h
常见误操作与后果：
- 执行完
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'; - 注意：MySQL 8.0+ 中
USAGE不再等价于“无权限”，而是表示“可连接但无显式权限”，它是授权体系的基础占位符
权限模型本身不复杂，但真实环境里权限失效往往不是语法错，而是主机名匹配、库级 USAGE 缺失、插件版本错配这些细节卡住。审计不是开了日志就完事，得想清楚谁看、怎么看、看多久——日志存三天和存三个月，对存储、归档、合规都是完全不同的约束。
