MySQL 中 GRANT
权限层级怎么选：全局、数据库、表还是列？
权限不是越宽越好，也不是越细越安全——关键看操作场景。比如备份脚本需要
SELECT全库，但 Web 应用连接的账号只应能查
users表的几个字段。
MySQL 权限按层级生效，高优先级覆盖低优先级：
columntable database global（即
ON *.*）。但注意：
CREATE USER、
RELOAD、
SHUTDOWN这类管理型权限只能在全局层级授予，哪怕你写成
ON mydb.*也会被忽略。
GRANT SELECT ON mydb.users TO 'app'@'%'—— 只允许查
mydb库的
users表
GRANT UPDATE (email, phone) ON mydb.users TO 'app'@'%'—— 只允许改这两列，其他字段即使有
SELECT也不可写
GRANT PROCESS ON *.* TO 'monitor'@'localhost'—— 监控账号查
SHOW PROCESSLIST，必须全局层级
DROP
和 DELETE
权限混淆导致误删的常见原因
很多运维以为给了
DROP就能删数据，其实不是：
DROP是 DDL 权限，控制的是删表、删库；删行要用
DELETE（DML），删字段要用
ALTER。
普通用户账号如果意外获得
DROP权限，执行
DROP TABLE users会直接清空整张表结构和数据，且无法靠 binlog 回滚（除非开了
binlog_format = ROW并保留足够日志）。 给应用账号时，禁用
DROP、
CREATE、
ALTER，只留
SELECT/
INSERT/
UPDATE/
DELETE想限制删除范围？用视图 +
WITH CHECK OPTION，例如：
CREATE VIEW active_users AS SELECT * FROM users WHERE status = 'active' WITH CHECK OPTION;然后只给这个视图的
DELETE权限
DELETE权限不等于能删任意行——配合 WHERE 的条件过滤仍由应用逻辑控制，MySQL 不校验语义
管理员账号为什么不能用 root@'%'
远程直连？
默认
root@localhost是 Unix socket 认证，比 TCP 更安全；而
root@'%'允许任意 IP 连接，一旦密码泄露或弱口令，等于把数据库大门钥匙挂网上。
真正需要远程管理时，应该分角色：用专用管理账号（如
dba@192.168.10.%），并限制来源网段；同时关闭
skip-networking以外的宽松配置。 检查当前 root 登录方式：
SELECT User, Host, plugin FROM mysql.user WHERE User = 'root';删掉危险账号：
DROP USER 'root'@'%';新建受限管理员：
CREATE USER 'dba'@'192.168.10.%' IDENTIFIED BY 'strong-pass-2024'; GRANT ALL PRIVILEGES ON *.* TO 'dba'@'192.168.10.%' WITH GRANT OPTION;确保
my.cnf中没有
bind-address = 0.0.0.0（应为
127.0.0.1或内网 IP）
权限变更后为什么 SELECT USER();
没变，但查询报错？
MySQL 权限缓存是连接粒度的：用户登录后，权限快照就固定了，后续
GRANT/
REVOKE对已存在的连接无效。所以你改完权限，老连接仍按旧规则校验，新连接才生效。
这也是为什么运维常遇到“明明刚授了权，应用还是连不上”——因为应用连接池没重建，还在用旧连接。
强制刷新权限缓存（影响所有连接）：FLUSH PRIVILEGES;，但仅在修改
mysql.user表直改时需要；用
GRANT命令则自动更新 让应用重连：重启服务，或调用连接池的
closeIdleConnections()类方法 验证当前连接权限：
SHOW GRANTS FOR CURRENT_USER();，不是
USER()—— 后者只显示登录名，前者才是实际生效权限
权限体系里最易被忽略的一点：存储过程和函数的执行权限，取决于定义者（
DEFINER）而非调用者。哪怕你只给了
EXECUTE权限，只要
DEFINER = 'root'@'%'，过程内部就能以 root 权限操作数据。
