查tables_priv表需先确认有mysql库SELECT权限，否则报错；无权限时应改用SHOW GRANTS逐个检查用户授权语句并筛选目标表；查表时Db和Table_name须精确匹配，且修改后必须执行FLUSH PRIVILEGES生效。
查 tables_priv 表前先确认你有权限读 mysql 库
直接 SELECT * FROM mysql.tables_priv 会报错 ERROR 1142 (42000): SELECT command denied to user，除非你是 root 或被显式授予了 SELECT 权限在 mysql 数据库上。普通应用账号几乎不可能有这个权限——这不是配置问题，是安全设计。别浪费时间去改账号权限，换更可行的路径。
用 SHOW GRANTS 反向推导谁有表权限
SHOW GRANTS 不直接告诉你“哪张表被谁授权”，但它能列出所有显式授予的语句，从中人工筛选出目标表即可。比如查 audit_log 表：
- 运行
SELECT User, Host FROM mysql.user;获取所有用户列表 - 对每个
User@Host组合执行SHOW GRANTS FOR 'user'@'host'; - grep 或肉眼找包含
ON `syslog`.`audit_log`的行（注意反引号和库名/表名大小写）
这个方法不依赖 mysql 库权限，只要你是管理员且能连上 MySQL 就能跑通。但注意：CURRENT_USER() 和 USER() 可能不同，SHOW GRANTS 查的是前者，务必先确认身份。
直接查 tables_priv 的正确姿势和坑点
如果你确实有 mysql 库的 SELECT 权限，查 tables_priv 要注意三件事：
-
Db和Table_name是精确匹配，Db = 'syslog'和Table_name = 'audit_log'必须同时成立，%在这里无效 -
Table_priv字段值是逗号分隔字符串（如'Select,Insert'），不是Y/N，需用FIND_IN_SET('Select', Table_priv)判断 - 查出来结果里的
User和Host必须和实际连接时完全一致（比如'app_user'@'192.168.1.%'不匹配'app_user'@'192.168.1.100'如果 DNS 解析失败）
典型命令：SELECT User, Host, Table_priv FROM mysql.tables_priv WHERE Db = 'syslog' AND Table_name = 'audit_log';
权限没生效？大概率忘了 FLUSH PRIVILEGES
无论是用 GRANT 添加权限，还是手动 INSERT INTO mysql.tables_priv，MySQL 都不会自动重载。新权限只对后续新建连接生效，旧连接缓存不变，且系统表修改后必须显式执行 FLUSH PRIVILEGES; 才进内存。调试时看到权限“不生效”，第一反应不该是怀疑 SQL 写错，而是检查这句有没有执行——尤其在脚本批量操作后容易漏掉。
