MySQL权限和安全管理不是“配完
GRANT就完事”的一次性操作，而是一套分层、联动、需持续维护的体系。核心就三点：**谁可以连（身份认证）→ 连上后能做什么（权限控制）→ 连接和操作本身是否被约束（运行时加固）**。
用户创建与主机限制必须写全 'user'@'host'
很多人只写
CREATE USER 'alice'，结果 MySQL 默认补成
'alice'@'%'—— 意味着该用户能从任意 IP 远程登录，哪怕你本意只是本地开发。这直接绕过防火墙白名单，是高频安全缺口。
host不是可选项，而是权限作用域的关键部分：
'alice'@'localhost'和
'alice'@'192.168.1.%'是两个完全独立的账户，权限互不影响 生产环境禁用
'%'，优先用具体内网段（如
'10.0.2.%'）或域名（如
'app-server.internal'） 本地管理账号应严格限定为
'root'@'localhost'，并确认
mysql.user表中没有残留的
'root'@'%'记录
权限分配必须遵循最小化原则，慎用 ALL PRIVILEGES
给应用账号授
GRANT ALL PRIVILEGES ON appdb.*看似省事，实则埋雷：一旦应用代码存在 SQL 注入漏洞，攻击者可直接
DROP TABLE或
CREATE FUNCTION执行系统命令。 业务账号通常只需
SELECT, INSERT, UPDATE, DELETE；只读报表账号只给
SELECT；运维脚本账号按需加
SHOW VIEW或
EXECUTE全局权限（如
PROCESS、
SUPER、
REPLICATION CLIENT）绝不能下放给普通应用用户 执行
GRANT后，MySQL 不自动刷新权限缓存，但 8.0+ 已无需手动
FLUSH PRIVILEGES；5.7 及更早版本仍需执行（否则新权限不生效）
运行时加固比权限语句更重要：bind-address
、skip-networking
、secure-file-priv
权限再细，也防不住一个监听在
0.0.0.0:3306且密码弱的 root 账号被爆破。真正的防线在 MySQL 启动配置里。
bind-address = 127.0.0.1（仅本地）或
bind-address = 192.168.5.10（指定内网 IP），禁止暴露公网 —— 这比防火墙规则更底层可靠
skip-networking = 1彻底关闭 TCP 连接，强制走 socket 文件，适合单机部署的后台服务
secure-file-priv = /var/lib/mysql-files限制
LOAD DATA INFILE和
SELECT ... INTO OUTFILE的路径，防止通过文件操作读取服务器敏感文件（如
/etc/passwd）
密码与账户生命周期管理常被忽略
很多团队花大力气配好权限，却让空密码账号、过期测试账号、长期未登录账号一直躺在
mysql.user表里 —— 它们就是静默的后门。 定期检查空密码：
SELECT user, host FROM mysql.user WHERE authentication_string = '' OR authentication_string IS NULL;删除无用账号用
DROP USER 'test'@'localhost';，不要只删
mysql.user行（会残留权限表脏数据） MySQL 8.0+ 支持密码过期策略：
ALTER USER 'appuser'@'%' PASSWORD EXPIRE INTERVAL 90 DAY;，配合应用层告警更有效 真正卡住安全命门的，往往不是不会写
GRANT，而是没意识到
my.cnf里的
bind-address比任何 SQL 权限都先起作用，也没想到一个没删干净的
'root'@'%'账户，能让所有精细授权形同虚设。
