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 执行系统命令。
- 业务账号通常只需
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 启动配置里。
理想商城 LxShop
下载
套采用php+mysql的多用户网上商城系统，安全、负载量高，访问迅捷，能与论坛、博客、CMS等系统整合并支持一站登陆。功能包括用户管理、商品管理、订单管理、销售统计、广告/公告管理、附件管理等，这些管理权限与用户等级挂钩。内置多套模板，支持界面个性化设计和人性化的采购方式。系统内置贝宝、支付宝、快钱在线等支付网关以及QQ、旺旺、雅虎通即时网络通讯工具。
-
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'@'%' 账户，能让所有精细授权形同虚设。 
