MySQL权限是分层模型，含全局至列级粒度，需避免GRANT ALL ON .、慎用WITH GRANT OPTION和'%'通配host，应用账号应最小化授权并限定库表，审计依赖audit_log插件或受限的general_log，权限回收须显式REVOKE或DROP USER。
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_schema - ORM 框架如 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 替代方案）。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
若用社区版硬上通用日志，务必注意：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 语句是否覆盖全部层级
权限越精细，维护成本越高；审计越全，性能和存储压力越大。没有银弹，只有根据业务敏感度做取舍：核心账务库必须列级权限 + 插件审计，内部报表库可适度放宽，但绝不能共用同一套账号凭证。
