MySQL 用户权限模型怎么理解才不踩坑
MySQL 的权限不是“开/关”二元开关，而是分层控制：全局、数据库、表、列、存储过程等粒度。直接
GRANT ALL PRIVILEGES ON *.*是最常见误操作，它绕过后续所有精细化限制，且
WITH GRANT OPTION会把授予权力下放，一旦子账号泄露，风险指数级放大。
实际权限生效依赖两个关键点：一是
mysql.user表中
host和
user的精确匹配（注意
'user'@'192.168.1.%'和
'user'@'%'不等价）；二是权限变更后必须执行
FLUSH PRIVILEGES（仅在直接改表时需要，
GRANT语句自动刷新）。 生产环境禁止使用
'%'通配 host，优先用具体 IP 段或 DNS 名称
USAGE权限表示“仅登录”，不赋予任何操作能力，适合审计账号或连接池健康检查账号 删除用户要同时用
DROP USER 'u'@'h'和
FLUSH PRIVILEGES，否则残留记录可能干扰新同名用户创建
如何最小化授予应用账号的权限
应用账号不该有
DROP、
CREATE、
ALTER、
INDEX、
GRANT OPTION等 DDL 权限。典型 Web 应用只需
SELECT、
INSERT、
UPDATE、
DELETE，且应限定到具体数据库和表。
GRANT SELECT, INSERT, UPDATE, DELETE ON `app_db`.`orders` TO 'app_user'@'10.20.30.40'; GRANT SELECT ON `app_db`.`products` TO 'app_user'@'10.20.30.40';
如果应用用到了存储过程，需单独授权：
EXECUTE ON PROCEDURE app_db.calc_discount，而不是给整个库
EXECUTE权限。 避免跨库查询需求，就别给
SELECT权限到
mysql或
information_schemaORM 框架如 Django/SQLAlchemy 默认不建索引，
INDEX权限对应用账号基本无用，反而增加被滥用风险 用
SHOW GRANTS FOR 'u'@'h'验证最终生效权限，注意输出里可能包含多条 GRANT 记录，权限是合并效果
开启 MySQL 审计日志的关键配置项
MySQL 社区版不自带企业级审计插件，但可通过
general_log+
log_output组合实现基础行为记录；更可靠的是启用
audit_log插件（需 MySQL 5.7.28+ 或 8.0，且仅限企业版或 Percona Server / MariaDB 替代方案）。
若用社区版硬上通用日志，务必注意：
general_log = ON会记录所有语句（含密码明文），性能损耗大，只能临时开启，且日志路径需设为非系统盘、有独立配额的目录：
SET GLOBAL general_log = 'ON'; SET GLOBAL log_output = 'TABLE'; -- 写入 mysql.general_log 表，比文件更易过滤 SET GLOBAL general_log_file = '/data/mysql/logs/general.log';
slow_query_log不是审计日志，它只捕获超时 SQL，无法替代行为追踪 Percona Server 提供开源
audit_log插件，配置项为
audit_log_policy = ALL、
audit_log_format = JSON，日志可直连 SIEM 工具 审计日志本身需设置严格文件权限：
chown mysql:mysql /var/lib/mysql/audit/且禁止其他用户读取
权限回收与账号生命周期管理容易忽略的点
权限回收不是“撤销就完事”。MySQL 不支持按时间自动过期权限，
CREATE USER ... PASSWORD EXPIRE只控制密码有效期，不控制权限存续。账号停用必须显式
DROP USER或
REVOKE ALL PRIVILEGES并
FLUSH PRIVILEGES。
更隐蔽的风险在于：MySQL 8.0 引入角色（
ROLE），但角色权限不会自动继承到已存在的用户——必须显式
GRANT role_name TO user，且用户登录后需
SET ROLE role_name才能激活（除非设为默认角色）。 定期用
SELECT user, host, account_locked FROM mysql.user WHERE account_locked = 'Y'检查锁定账号 用
SELECT * FROM mysql.role_edges查看角色继承关系，避免权限“幽灵残留” 备份
mysql.user、
mysql.db、
mysql.tables_priv表结构及数据，权限恢复不能只靠 SQL dump，得验证 GRANT 语句是否覆盖全部层级
权限越精细，维护成本越高；审计越全，性能和存储压力越大。没有银弹，只有根据业务敏感度做取舍：核心账务库必须列级权限 + 插件审计，内部报表库可适度放宽，但绝不能共用同一套账号凭证。
