缺的是对报错中明确指出的对象（如mydb.users）的SELECT权限，需用SHOW GRANTS FOR 'u1'@'localhost'定位缺失项，并按“命令+对象”组合精准授予GRANT SELECT ON mydb.users或mydb.*。
报错里写的“SELECT command denied”到底缺哪个权限
ERROR 1142 (42000) 不是笼统的“没权限”，而是 MySQL 明确告诉你：当前用户在执行 SELECT 这个命令时，对报错中指出的具体对象（比如 mydb.users）没有对应权限。它不关心你有没有 INSERT 或 UPDATE，只校验这一条语句实际用到的权限项。
实操建议：
- 立刻用高权限账号（如 root）运行
SHOW GRANTS FOR 'u1'@'localhost';，注意主机名必须完全一致——'u1'@'127.0.0.1'和'u1'@'localhost'是两个不同用户 - 把报错信息拆开：
SELECT是动词，mydb.users是对象。在SHOW GRANTS输出里找有没有匹配GRANT SELECT ON mydb.users或更宽泛的GRANT SELECT ON mydb.* - 如果输出里只有
USAGE，说明这个用户连登录后最基本的数据库操作权都没有；如果只有GRANT SELECT ON mydb.orders，但你查的是mydb.users，那就纯属对象不匹配
CREATE VIEW 报错却找不到 CREATE VIEW 权限
视图操作权限是独立的，SELECT 或 ALL PRIVILEGES ON mydb.* 都不能替代 CREATE VIEW。MySQL 要求这个权限必须显式授予，且作用域是数据库级（mydb.*），不是表级或全局级。
实操建议：
- 运行
SHOW GRANTS FOR 'u1'@'localhost';，确认输出中是否含CREATE VIEW字样；如果没有，就直接缺授权 - 授予权限时写法必须是
GRANT CREATE VIEW ON mydb.* TO 'u1'@'localhost';，不能写成GRANT CREATE VIEW ON mydb.users（表级无效）或漏掉.* - 如果源视图用了
DEFINER=`admin`@`localhost` SQL SECURITY DEFINER，你还得确保自己或该定义者对底层表有SELECT权限，否则CREATE VIEW AS SELECT * FROM v1也会失败
FLUSH PRIVILEGES 执行了还是不生效
FLUSH PRIVILEGES; 并非万能刷新开关。很多“刚授完权就报错”的情况，其实卡在连接复用或 host 解析上，而不是权限没加载。
实操建议：
- 检查客户端是否复用了旧连接：PHP 的
mysql_connect()（已废弃）、某些连接池（如 HikariCP）或 CLI 的历史会话不会自动重载权限，必须断开重连 - 确认连接时解析出的 host 是否和授权时一致：从本地 socket 连，MySQL 默认识别为
localhost，不是127.0.0.1；用SELECT USER(), CURRENT_USER();对比，前者是你声明的连接身份，后者是 MySQL 实际匹配到的账号 - 检查 MySQL 是否启用了
skip-grant-tables（见配置文件my.cnf中[mysqld]段），启用后所有权限校验失效，FLUSH PRIVILEGES也无意义
MySQL 8.0 授权后仍报 1142 的隐藏坑
8.0 默认认证插件是 caching_sha2_password，但它不影响权限判断逻辑；真正容易被忽略的是 host 匹配精度、大小写敏感性，以及权限层级的嵌套关系。
实操建议：
- 创建用户时必须显式指定插件：例如
CREATE USER 'u1'@'10.0.2.%' IDENTIFIED WITH caching_sha2_password BY 'pwd';，否则旧客户端可能连不上，导致你以为是权限问题 -
mysql.user表里的Host值区分大小写，'u1'@'LOCALHOST'≠'u1'@'localhost'；授权时写的 host 必须和CURRENT_USER()返回的一模一样 - 跨库查询（如
SELECT a.id, b.name FROM db1.t1 a JOIN db2.t2 b）需要分别对db1.t1和db2.t2授予SELECT，不能只给其中一个库
权限体系本身不复杂，但 Host 字符串匹配、CURRENT_USER() 与 USER() 的差异、DEFINER 引发的权限链、以及连接复用带来的缓存延迟——这几个点一旦忽略，就会反复陷入“明明授了权却还报 1142”的循环。
