MySQL安全管理需分层持续维护：身份认证须明确'用户'@'主机'，禁用'%'；权限控制遵循最小化原则，慎用ALL PRIVILEGES；运行时加固依赖bind-address、secure-file-priv等配置。
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 执行系统命令。
word报告自动生成神器
下载
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
- 业务账号通常只需
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'@'%' 账户，能让所有精细授权形同虚设。 
