<p>CREATE USER 必须显式指定 host（如 'app_user'@'10.20.30.40'），禁用 '%'；GRANT 应限定库表范围（如 ON app_db.），禁用 .* 和 mysql 库；注意 'localhost' 与 '127.0.0.1' 协议差异；FLUSH PRIVILEGES 仅在特定场景必需。</p>
CREATE USER 时必须显式指定 host，不能依赖 '%' 通配
应用连接数据库时用的 IP 是固定的（比如容器内网 IP、K8s Service IP 或宿主机固定出口 IP），创建用户就得把 host 字段写死。例如应用跑在 10.20.30.40，就该执行：CREATE USER 'app_user'@'10.20.30.40' IDENTIFIED BY 'p@ssw0rd';
而不是 'app_user'@'%'——后者等于对全网开放，哪怕后面 GRANT 再严也拦不住连接本身。
常见疏漏：
• 忘记区分 'localhost' 和 '127.0.0.1'：前者走 socket，后者走 TCP，应用若用 127.0.0.1 连却只建了 localhost 账号，会连不上
• Docker 环境中误用 '%'，其实应该用服务名如 'app_user'@'web-app'（需确保 DNS 可解析）
GRANT 必须限定到 db_name.*，禁用 *.* 和 mysql 库授权
权限隔离的核心不是“给了什么”，而是“没给什么”。只运行这一条：GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO 'app_user'@'10.20.30.40';
绝对不要：
• GRANT ALL ON *.*（全局权限，绕过所有库级限制）
• GRANT ALL ON `mysql`.*（直接暴露用户表、权限表）
• GRANT USAGE ON app_db.*（这等于没给任何操作权，应用会报错）
MySQL 8.0+ 默认允许查 information_schema，不用额外授权；但 performance_schema 和 sys 无法隐藏，也不建议授予权限。
FLUSH PRIVILEGES 不是万能的，但漏掉会导致权限不生效
GRANT 语句本身会自动重载权限缓存，多数情况下 FLUSH PRIVILEGES 不是必须的。但以下情况必须加：
• 你用 UPDATE mysql.user 直接改过表（不推荐，风险高）
• 在 MySQL 5.7 或更早版本中执行了 GRANT 后遇到权限延迟生效
• 应用反复报 Access denied，而 SHOW GRANTS FOR 'app_user'@'10.20.30.40' 显示权限已存在
此时执行：FLUSH PRIVILEGES;
注意：这条命令不会报错，但也不会告诉你是否真刷新成功——最可靠验证方式是退出 MySQL 客户端重连，或用应用实际发起一次查询。
应用连接字符串里 host 和 user 必须与账号完全匹配
应用配置里的数据库地址（host）、端口、用户名、密码，必须和 CREATE USER 语句中的 'user'@'host' 一模一样。例如：
• MySQL 账号是 'app_user'@'10.20.30.40'，但应用连的是 10.20.30.41 → 报错 Access denied for user 'app_user'@'10.20.30.41'
• 账号是 'app_user'@'10.20.30.%'，但应用连的是 10.20.30.40:3307（非默认端口）→ 仍匹配，因为 host 不含端口
• 云环境用域名（如 rds-xxx.cn-north-1.rds.aliyuncs.com），DNS 解析出的 IP 必须落在你授权的 host 范围内，否则连接被拒
最容易被忽略的是：应用重启后未加载新配置，或配置中心缓存了旧连接串，导致看似改了权限，实则连的根本不是那个账号。
