用户创建必须带 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的事实。
