MySQL账号权限须遵循最小权限原则，禁用root或ALL PRIVILEGES，精确控制至列级/行级；新建账号需单独CREATE USER并限定库表操作；禁用DROP/ALTER等敏感权限；强制密码策略；通过SHOW GRANTS、mysql.user、mysql.db核查越权；启用审计插件并独立存储日志；定期清理90天未登录账号。
MySQL账号权限必须遵循最小权限原则
直接给 root 或 ALL PRIVILEGES 权限，等于把锁孔钥匙焊死在门把手上。合规审计（如等保2.0、金融行业规范）第一条就卡这里：谁用什么库、什么表、什么操作，必须精确到列级或行级控制。
- 新建业务账号时，用
CREATE USER单独建用户，不复用已有高权限账号 - 授权只写具体库名，例如
GRANT SELECT, INSERT ON myapp.* TO 'app_user'@'10.20.%'，禁止用GRANT ... ON *.* - 敏感操作（
DROP、ALTER、CREATE USER、PROCESS、SUPER）一律禁用，除非 DBA 本地登录且走审批流程 - 密码策略强制启用：
validate_password插件 +password_history=5+password_reuse_interval=365
如何检查当前账号是否越权
别信“我记得没开”，得查日志和元数据。MySQL 自身不记录权限变更历史，但能实时抓快照。
- 查账号拥有的全部权限：
SHOW GRANTS FOR 'app_user'@'10.20.%';—— 注意输出里有没有WITH GRANT OPTION，有就是权限传染源 - 查全局权限残留：
SELECT * FROM mysql.user WHERE User='app_user' AND Host='10.20.%'\G，重点看Super_priv、Shutdown_priv、File_priv是否为N - 查库/表级权限是否冗余：
SELECT * FROM mysql.db WHERE User='app_user' AND Db='information_schema';—— 业务账号绝不该有information_schema或mysql库权限
审计日志必须开启并落盘到独立存储
合规不是“开了就行”，而是“能回溯、不可删、防篡改”。MySQL 自带的 general_log 和 slow_query_log 不满足审计要求，必须用企业版审计插件或社区替代方案。
- 推荐用
audit_log插件（MySQL 5.7+ 企业版），配置项：audit_log_policy=ALL、audit_log_format=NEWJSON、audit_log_file=/data/audit/mysql-audit.log - 社区版可用
Percona Server的audit_log或MariaDB的server_audit，但注意日志路径不能在 MySQL 数据目录下，否则重启可能被清空 - 关键陷阱：
audit_log默认只记录连接/断开和查询语句，不记录参数值；敏感字段（如PASSWORD、SSN）需配合应用层脱敏，数据库层无法自动掩码 - 日志文件权限设为
640，属主为mysql:auditlog，避免 DBA 账号直接读取
定期清理过期账号和闲置权限
没人管的账号是最大风险点。合规检查常发现 3 年前测试用的 test_dev 账号还开着 SELECT 权限，连着生产库。
- 查 90 天未登录账号：
SELECT user, host, password_last_changed FROM mysql.user WHERE password_last_changed - 查无任何权限的僵尸账号：
SELECT u.User, u.Host FROM mysql.user u LEFT JOIN mysql.db d ON u.User=d.User AND u.Host=d.Host WHERE d.User IS NULL; - 禁用而非删除：用
REVOKE ALL PRIVILEGES ON *.* FROM 'old_user'@'%';+ALTER USER 'old_user'@'%' ACCOUNT LOCK; - 自动化建议：用脚本每周扫描，结果发邮件给 DBA 和安全负责人，锁定超 180 天未登录且无权限的账号
最常被忽略的是权限继承关系——比如 app_user 属于 app_group 角色，而角色又继承了 backup_admin 权限，这种间接授权在 SHOW GRANTS 里不显示，必须查 mysql.role_edges 表。别只盯着自己写的那条 GRANT 语句。
