应直接用 SHOW GRANTS FOR 'user'@'host' 查真实权限，而非 SELECT * FROM mysql.user；关键字段为 Host、User、plugin 及 Select_priv 至 Grant_priv 等 Y/N 权限位，MySQL 8.0 起 authentication_string 替代 password，且 account_locked、password_expired 参与认证。
mysql.user 表结构怎么看才不踩坑
直接查 DESCRIBE mysql.user 会看到一堆字段，但真正影响登录和全局权限的只有几个关键列，而且 MySQL 8.0 和 5.7 字段差异很大——比如 plugin、account_locked、password_expired 在 8.0 才强制参与认证流程。
常见错误是用 SELECT * FROM mysql.user 看权限，结果被密文 authentication_string 和一堆 NULL 值搞晕；其实应该聚焦在：Host、User、Select_priv 到 Grant_priv 这组 Y/N 字段，以及 plugin 是否为 mysql_native_password（尤其连老客户端时）。
- MySQL 5.7 默认用
password字段存哈希，8.0 起只认authentication_string，改密码必须用ALTER USER，直接 UPDATE 表无效 -
Host匹配是严格字符串比较，'%'不匹配 localhost（Unix socket 登录走的是'localhost'，不是'127.0.0.1'） -
Super_priv关闭后，连SHOW PROCESSLIST都会被拒绝，别只盯着 DML 权限
mysql.db 和 mysql.tables_priv 的权限叠加逻辑
这两张表不是“或”关系，而是按粒度逐级覆盖：用户连接进来后，先查 mysql.user 得到全局权限，再按 db 和 table_name 查 mysql.db 和 mysql.tables_priv，最终权限是“所有匹配行的权限位 OR 合并”。容易出错的是 Db 字段大小写敏感（取决于 lower_case_table_names 设置），且 mysql.db 中 Host 和 User 必须同时匹配当前连接值。
-
mysql.db控制库级操作（如CREATE TABLE、DROP DATABASE），但不控制 SELECT —— 那得看tables_priv或列权限 -
mysql.tables_priv的Table_name是精确匹配，不支持通配符；想限制某张表，必须显式 INSERT 一行，不能靠% - 如果
mysql.db里某库设了Select_priv='N'，但mysql.tables_priv又给其中一张表开了'Y'，那这张表仍可查——因为更细粒度的权限优先
查权限别只用 SELECT，用 SHOW GRANTS 更可靠
SELECT 直接读系统表看似直观，但权限实际生效依赖多层缓存和运行时判断。比如刚用 GRANT 加的权限，可能还没刷进内存；或者 FLUSH PRIVILEGES 没执行，表数据已改但服务没 reload。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 查某个用户真实生效权限，用
SHOW GRANTS FOR 'user'@'host'，它走的是运行时权限树，不是快照 -
SHOW GRANTS FOR CURRENT_USER()能暴露你当前连接实际拿到哪些权限，比猜mysql.user字段靠谱得多 - 如果
SHOW GRANTS输出里没看到预期权限，八成是GRANT语句没带WITH GRANT OPTION，或者目标用户根本不存在（MySQL 不报错，静默忽略）
mysql.columns_priv 和 performance_schema 的干扰项
mysql.columns_priv 确实存在，但极少手动维护——它只在显式用 GRANT ... ON db.tbl(col1,col2) 时写入，且优先级高于表级权限。不过现在基本没人这么干，因为 ORM 和查询生成器很难适配列级权限，一开就容易报 Column 'xxx' in field list is ambiguous。
另外别被 performance_schema 里的 users 表误导，它只记录当前活跃连接的账号信息，不反映权限，字段也少得多。
-
mysql.columns_priv的Column_name是 BINARY 类型，大小写完全敏感，'id'和'ID'是两回事 - MySQL 8.0+ 默认关闭列权限检查（
check_proxy_users=OFF），除非明确SET PERSIST check_proxy_users = ON，否则改了columns_priv也没用 - 权限校验路径很长：连接阶段看
user→ 库操作看db→ 表操作看tables_priv→ 列操作才落到columns_priv，中间任意一层 deny 就终止
权限系统最麻烦的不是字段多，而是匹配顺序和缓存机制——GRANT 之后记得 FLUSH PRIVILEGES，查权限优先用 SHOW GRANTS，别信自己手写的 SELECT 语句。表结构只是快照，运行时权限树才是真相。
