mysql用户创建必须指定host，否则默认@'%'导致任意ip可连接；应按最小权限原则限定ip、库表、列级权限，并用role统一管理。
用户创建必须带 host，否则等于放行所有 IP
MySQL 的 user@host 是一个完整身份标识，'app_user'@'localhost' 和 'app_user'@'%' 完全是两个账号。很多人执行 CREATE USER 'app_user' IDENTIFIED BY 'pwd';，没写 @'host'，结果 MySQL 默认补成 @'%' —— 这意味着该账号可从任意网络地址连接，是高危配置。
- 生产环境严禁用
@'%'，应明确限定 IP 段，如@'192.168.50.%'或具体应用服务器 IP - 本地调试用
@'localhost'，注意它和@'127.0.0.1'不等价：前者走 Unix socket，后者走 TCP，权限不互通 - 若需多来源访问，宁可建多个账号（
'app_user'@'192.168.50.10'+'app_user'@'192.168.50.11'），也不用宽泛的通配符
授予权限别直接 ON *.*，先锁死数据库范围
全局权限（ON *.*）意味着能执行 DROP DATABASE、SHUTDOWN、CREATE USER 等管理操作，普通业务账号完全不需要。错误示例：GRANT ALL PRIVILEGES ON *.* TO 'app_user'@'%'; —— 这等于把数据库当裸机交出去。
- 开发/应用账号只给库级最小集：
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO 'app_user'@'192.168.50.%'; - 绝对禁止授予
DROP、ALTER、CREATE（除非 DBA 明确授权迁移任务） - 监控类账号（如 Prometheus exporter）只需
SELECT ON performance_schema.*和PROCESS全局权限，其他一概不要
列级权限不是“炫技”，而是敏感字段隔离刚需
当 HR 系统要给 BI 账号查员工表，但不能暴露 salary、id_card 字段时，靠应用层过滤或视图封装都不如原生列权限可靠——因为它是服务端强制拦截，连 SQL 解析阶段就拒绝非法列访问。
- 语法很直白：
GRANT SELECT(id, name, dept) ON hr.employees TO 'bi_reader'@'%'; - 注意：列权限只对
SELECT和UPDATE有效，且必须配合表级SELECT权限才能生效（即先有表权限，再细化列） - 一旦开了列权限，该用户执行
SELECT * FROM hr.employees;会报错ERROR 1142 (42000): SELECT command denied to user ... for column 'salary'，而不是静默过滤
MySQL 8.0+ 推荐用 Role 统一权限组，别硬写一堆 GRANT
当团队有 5 个开发、3 个测试、2 个运维都要访问同一套业务库时，逐个 GRANT 不仅易漏，更难回收。Role 就是为这种场景设计的“权限模板”。
- 先建角色：
CREATE ROLE 'dev_team';，再批量授权：GRANT SELECT, INSERT, UPDATE ON myapp_db.* TO 'dev_team'; - 把人加进角色：
GRANT 'dev_team' TO 'dev1'@'192.168.50.%', 'dev2'@'192.168.50.%'; - 新成员入职？只需
GRANT 'dev_team' TO 'dev3'@'...';；离职？REVOKE 'dev_team' FROM 'dev2'@'...';，干净利落 - 别忘了启用角色：
SET DEFAULT ROLE 'dev_team' TO 'dev1'@'192.168.50.%';，否则登录后权限不自动生效
最常被忽略的一点：权限变更后无需 FLUSH PRIVILEGES —— 只要不用 INSERT/UPDATE 直接改 mysql.user 表，所有 CREATE USER、GRANT、ALTER USER 都实时生效。手抖敲了 FLUSH PRIVILEGES 不会报错，但纯属多余，还可能掩盖你其实没成功执行 GRANT 的事实。
