MySQL权限隔离需落实账号、IP、操作类型三层防线，禁用通配符主机和ALL PRIVILEGES，严格绑定具体IP、限定库表级DML权限，回收GRANT OPTION与DROP等高危权限，并通过版本化SQL脚本执行权限变更。
权限隔离不是“开了就行”的开关，而是必须拆解到账号、IP、操作类型三层落地的防线。只改密码或禁用root，90%的勒索攻击仍能绕过。
为什么普通账号也能删库？关键在权限继承
黑客一旦拿到任意一个有CREATE、DROP、GRANT OPTION权限的账号，就能新建高权限用户、覆盖mysql.user表、甚至删库后重建勒索库。很多团队误以为“没给root就安全”，但实际只要存在GRANT ALL ON *.*的账号，等于直接送钥匙。
- 检查所有账号是否拥有
GRANT OPTION：SELECT user,host,grant_priv FROM mysql.user WHERE grant_priv='Y'; - 确认
DROP DATABASE权限是否被泛授：SELECT table_schema,privilege_type FROM information_schema.role_table_grants WHERE privilege_type='DROP'; - 删除匿名用户和
'%'@'%'类宽泛主机匹配：DROP USER ''@'localhost'; DROP USER 'root'@'%';
最小权限账号必须绑定具体IP和操作范围
应用账号不能只写'app'@'%'，否则任何公网IP都能连；也不能只授ALL PRIVILEGES，因为DROP和CREATE根本不在日常业务链路里。
- 创建账号时强制限定来源：
CREATE USER 'app_rw'@'192.168.10.5' IDENTIFIED BY 'StrongP@ss_2026'; - 只开放必要DML：
GRANT SELECT,INSERT,UPDATE ON app_db.* TO 'app_rw'@'192.168.10.5'; - 显式拒绝危险操作（MySQL 8.0+）：
REVOKE DROP ON *.* FROM 'app_rw'@'192.168.10.5'; - 禁止跨库访问：
GRANT ... ON app_db.*，绝不用ON *.*
权限变更必须通过SQL脚本固化，禁止交互式授权
运维人员在MySQL客户端里手敲GRANT，极易漏掉FLUSH PRIVILEGES或输错host，更危险的是：这类操作不会进binlog，审计日志也难追溯。线上环境应彻底禁用交互式赋权。
- 所有权限变更走版本化SQL文件，例如
grant-app-rw-v2.sql，含注释说明用途与生效时间 - 执行前校验目标账号是否存在、host是否精确、权限是否超限（可用
mysqldiff比对） - 用
mysql -e "source /path/to/grant-app-rw-v2.sql"批量执行，避免人工输入错误 - 执行后立即验证：
SHOW GRANTS FOR 'app_rw'@'192.168.10.5';
权限隔离失效的典型信号
这些现象说明权限体系已形同虚设，必须当天处理：
-
SELECT COUNT(*) FROM mysql.user WHERE host='%';结果非0 → 存在任意IP可登录账号 -
SHOW VARIABLES LIKE 'sql_mode';返回值不含STRICT_TRANS_TABLES→ 权限变更可能被静默忽略 -
SELECT user,host FROM mysql.user WHERE account_locked='N' AND password_expired='Y';有结果 → 过期密码未重置，可能被撞库利用 - binlog中出现
SET sql_log_bin = 0→ 有人绕过日志直接删库，说明SUPER权限未回收
权限隔离真正起效的标志，不是“没被黑”，而是黑客即使拿到一个应用账号，连SHOW DATABASES都只能看到1个库，且执行DROP TABLE直接报错ERROR 1142 (42000): DROP command denied。这需要每一层配置都咬合到位，缺一不可。
