MySQL中GRANT需加WITH GRANT OPTION才允许转授权限，且该选项须随其他权限一并回收；localhost与127.0.0.1权限互不兼容；直接改表需FLUSH PRIVILEGES，而DCL语句自动生效；误删root@localhost将导致无法本地登录。
GRANT 语句没加 WITH GRANT OPTION 却想授权给别人
很多人执行 GRANT SELECT ON db.* TO 'user'@'%' 后，发现这个 user 自己能连上，但无法把权限再转授给其他人——这很正常，因为 MySQL 默认不开启代理授权能力。只有显式加上 WITH GRANT OPTION，该用户才拥有“授予权限的权限”。但要注意：WITH GRANT OPTION 本身不是独立权限，不能单独回收，只能随同其他权限一起用 REVOKE 撤销。
- 错误写法：
GRANT SELECT ON db.* TO 'a'@'%' ;→ a 无法再GRANT给 b - 正确写法：
GRANT SELECT ON db.* TO 'a'@'%' WITH GRANT OPTION; - 隐患：一旦授予，a 就可能绕过 DBA 控制链，尤其在多租户场景下容易失控
localhost 和 127.0.0.1 被当成两个不同 host 导致权限不生效
MySQL 的权限系统严格区分 'user'@'localhost' 和 'user'@'127.0.0.1'，哪怕你本地用 mysql 客户端连 127.0.0.1，匹配的也是后者，前者只响应 Unix socket 连接（即不走 TCP）。很多同学配完 'user'@'localhost' 权限后，在命令行用 mysql -h 127.0.0.1 -u user 死活连不上，就是卡在这儿。
- 验证方式：
SELECT USER(), CURRENT_USER();—— 前者是客户端声明的身份，后者才是实际匹配的权限账户 - 安全建议：如无特殊需求，统一用
'user'@'127.0.0.1'或更严格的内网 IP 段，避免'user'@'%' - 注意：
localhost是个特殊标记，不会被 DNS 解析，也不走网络栈；而127.0.0.1是标准 IPv4 地址，强制走 TCP
FLUSH PRIVILEGES 忘了执行或执行了也没用
直接改 mysql.user 表（比如用 UPDATE）后，必须执行 FLUSH PRIVILEGES; 才能让内存中的权限缓存刷新；但如果你是用 GRANT/CREATE USER 等 DCL 语句操作的，MySQL 会自动重载，此时再执行 FLUSH PRIVILEGES; 不仅多余，还可能掩盖误操作——比如你本想删用户却手抖写了 GRANT，又立刻 FLUSH，反而让错误权限立即生效。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 需要手动 FLUSH 的场景：直连 mysql 库、UPDATE/INSERT/DELETE 权限表
- 不需要 FLUSH 的场景：
GRANT、REVOKE、DROP USER、ALTER USER - 典型误操作：
UPDATE mysql.user SET authentication_string=... WHERE User='x'; FLUSH PRIVILEGES;→ 密码字段名在 5.7+ 是authentication_string，8.0+ 又改回password？错，8.0 已移除 password 字段，必须用ALTER USER
root@localhost 被禁用远程登录后，误删本地登录入口
有些运维为了“加固”，执行 DROP USER 'root'@'localhost'; 或 DELETE FROM mysql.user WHERE User='root' AND Host='localhost';，结果本地 sudo mysql 也登不进去了。MySQL 启动时如果找不到任何 root@localhost（且未启用 --skip-grant-tables），就真进不去了。
- 恢复手段极麻烦：需停库、加
--skip-grant-tables启动、手工 INSERT 回 root 用户、再重启 - 安全替代方案：保留
'root'@'localhost'，仅限制其只能从本地 socket 登录；对远程管理，新建专用账号并限定 IP 段，如'admin'@'192.168.10.%' - 关键点：MySQL 5.7+ 默认 root 只有
'root'@'localhost'，没有'root'@'%'，别一上来就 DROP
权限模型看着简单，但 host 匹配顺序、大小写敏感性、密码插件差异（caching_sha2_password vs mysql_native_password）、甚至 SQL_MODE 都会影响最终行为。最稳妥的做法是：所有权限变更走 GRANT/REVOKE，不用直接改表；所有用户 host 尽量写具体值，别贪图方便用 %；每次改完用 SHOW GRANTS FOR ... 确认实际生效内容。
