show grants for 'user'@'host'最直接查表权限，需带完整主机名；查底层表用mysql.tables_priv或columns_priv；修改权限后必须执行flush privileges生效。
直接用 SHOW GRANTS 查表权限最靠谱
想确认某个用户对某张表有没有 SELECT、UPDATE 权限，别急着翻系统表——先跑一句 SHOW GRANTS FOR 'user'@'host';。它会把所有已授予的权限（包括表级）原样输出成可执行的 GRANT 语句，比如：GRANT SELECT, INSERT ON `appdb`.`orders` TO 'app_user'@'192.168.1.%';
这种格式一眼就能看出权限范围、对象和主体，比解析字段直观得多。
查不到表权限？大概率是没写对 @'host'
常见错误：执行 SHOW GRANTS FOR 'app_user'; 报错 ERROR 1141 (42000): There is no such grant defined for user 'app_user' on host '%'。
根本原因：MySQL 要求必须带完整主机名，不能省略 @'host'。哪怕你记得用户是从 % 登录的，也得写全：SHOW GRANTS FOR 'app_user'@'%';
如果不确定 host 是什么，先查：SELECT User, Host FROM mysql.user WHERE User = 'app_user';
需要批量分析或验证字段级控制？查 mysql.tables_priv 表
当你要写自动化脚本判断“哪些用户对敏感表有 DELETE 权限”，或者排查列级权限（如只允许改 status 字段），SHOW GRANTS 输出难解析，这时就得查底层表：SELECT * FROM mysql.tables_priv WHERE Table_name = 'audit_log' AND Db = 'syslog';
注意：
• Table_priv 字段值是逗号分隔的权限字符串（如 'Select,Insert'），不是 Y/N；
• 列级权限存在 mysql.columns_priv，需单独查；
• 直接查这些表需要 SELECT 权限在 mysql 库，普通应用账号通常没有。
权限生效有缓存，改完不刷 FLUSH PRIVILEGES 就白干
无论是通过 GRANT 新增表权限，还是手动更新 mysql.tables_priv，MySQL 都不会实时重载——它把权限缓存在内存里。所以操作后必须执行：FLUSH PRIVILEGES;
否则新权限对新连接无效，旧连接也不刷新。这点特别容易被忽略，尤其在调试阶段看到权限没生效，第一反应不该是怀疑语法，而是先检查有没有刷缓存。
