应按最小权限原则选择层级：全局用于DBA管理，数据库级适合备份脚本，表级适配Web应用，列级用于敏感字段隔离；权限按层级生效，高优先级覆盖低优先级。
MySQL 中 GRANT 权限层级怎么选：全局、数据库、表还是列？
权限不是越宽越好，也不是越细越安全——关键看操作场景。比如备份脚本需要 SELECT 全库，但 Web 应用连接的账号只应能查 users 表的几个字段。
MySQL 权限按层级生效，高优先级覆盖低优先级：column table 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 权限操作数据。
