error 1142并非当前用户缺select权限，而是mysql校验路径被绕过：视图查询时按sql security definer检查definer账号对基表的权限，若definer不存在、无基表select权或角色未激活，即使当前用户已授视图权限仍失败。
SELECT报ERROR 1142但SHOW GRANTS显示有权限
这不是权限没给，而是MySQL根本没走你想象的那条校验路径。报错时真正被检查的，往往不是当前用户，而是视图或存储过程定义里的DEFINER账号——它可能已删、过期、或对某张基表没了SELECT权。
先执行：SELECT USER(), CURRENT_USER();。前者是客户端声明的身份，后者才是MySQL实际认证并用于权限校验的账号。如果返回'u'@'localhost'，但你只给'u'@'%'授过权，那就完全不生效。
- 查视图定义：
SHOW CREATE VIEW your_view\G，重点看DEFINER和SQL SECURITY字段 - 确认DEFINER是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'definer_user' AND Host = 'host'; - 查DEFINER真实权限：
SHOW GRANTS FOR 'definer_user'@'host';
GRANT后SELECT仍失败，是否漏了FLUSH PRIVILEGES
MySQL把权限缓存在内存里，GRANT执行完不刷新，新权限可能延迟生效，尤其在容器或旧版本中更常见。别跳过这步。
执行完授权后，立刻跟一句：FLUSH PRIVILEGES;。再用SHOW GRANTS FOR CURRENT_USER();验证输出里真有对应SELECT ON db.table或SELECT ON db.*。
- 如果用户被设为过期：
ALTER USER 'u'@'h' ACCOUNT UNLOCK;（PASSWORD EXPIRE会直接禁用权限） -
GRANT SELECT ON db.*≠GRANT SELECT ON db.table：跨库视图引用billing.invoices，必须单独授SELECT ON billing.invoices - 嵌套视图还需
SHOW VIEW权限，否则连SHOW CREATE VIEW都执行不了
SELECT * FROM table; 报“table doesn’t exist”但表明明存在
这不是权限问题，而是schema上下文错位。PostgreSQL里叫search_path，MySQL虽无同名机制，但类似陷阱出现在默认数据库未指定或连接时没USE db;。
执行SELECT DATABASE();确认当前默认库。如果返回NULL，说明没选库，所有表名都会被当作当前库下对象解析——而你可能在test库建表，却连着mysql库执行SELECT * FROM t;。
- 连接时加
-D db_name参数，或登录后立即USE db_name; - 写全限定名：
SELECT * FROM db_name.table_name;，绕过默认库依赖 - 检查是否用了错误的连接host：
localhost走socket，127.0.0.1走TCP，权限记录是分开的
SELECT返回空结果，但你知道数据应该存在
这时ERROR 1142不会出现，但行为一样令人困惑。先排除语法和连接问题，再聚焦隐式约束。
运行SELECT COUNT(*) FROM table_name;。如果返回0，说明真没数据；如果返回非0但SELECT *没结果，大概率是WHERE条件写错，比如WHERE status = ''误写成WHERE status = NULL（应写IS NULL）。
- 检查字符集和collation：
SHOW CREATE TABLE table_name;，对比字段collation与查询值编码是否兼容 - InnoDB字典损坏也可能导致表“存在但不可见”，查
information_schema.tables里有没有该表记录 - 某些监控或审计插件会静默拦截SELECT，需检查
SHOW PLUGINS;中是否有active的query rewrite类插件
复杂点在于：权限校验链可能横跨DEFINER、CURRENT_USER、角色激活状态、host匹配、schema上下文五层。任何一个断点都会让SELECT失败，且错误提示未必指向真实原因。
