需定位“命令+对象”组合缺失权限，用SHOW GRANTS精确排查，按最小权限原则授SELECT/INSERT等特定权限，注意host匹配、连接重载及视图/存储过程等特殊对象权限。
查清到底是哪个权限丢了
错误 ERROR 1142 (42000): SELECT command denied to user 'xxx'@'localhost' for table 'yyy' 不是笼统的“没权限”，而是 MySQL 明确告诉你：用户在执行某条具体命令（SELECT、INSERT、UPDATE、DELETE、CREATE 等）时，对某个对象（库、表、列、视图）缺少对应权限。必须定位到「命令+对象」组合才不会乱授。
实操建议：
- 用高权限账号（如
root）登录，运行SHOW GRANTS FOR 'xxx'@'localhost';—— 注意主机名要完全匹配，'xxx'@'127.0.0.1'和'xxx'@'localhost'是两个不同用户 - 如果报错涉及某张表（比如
user表），别急着GRANT ALL，先确认是不是只缺SELECT：运行SHOW GRANTS FOR 'xxx'@'localhost' ON mysql.user;（MySQL 8.0+ 支持该语法；旧版本不支持，跳过即可） - 想快速比对权限缺口？把报错里的动词（如
SELECT）和对象（如database.table）代入已有授权列表，看有没有匹配项
按需补权，避免过度授权
给所有权限（GRANT ALL PRIVILEGES ON *.*）看似省事，但会埋下安全风险和后续排查障碍。真实生产环境里，最小权限原则不是口号，是止损底线。
实操建议：
- 只读场景（如报表查询）→
GRANT SELECT ON myapp.users TO 'reporter'@'localhost'; - 写入+更新（如 API 写库）→
GRANT INSERT, UPDATE, DELETE ON myapp.orders TO 'api_user'@'localhost'; - 跨库关联查询 → 权限必须分别授予每个库的对应表，
GRANT SELECT ON db1.table_a, db2.table_b TO 'joiner'@'localhost';（MySQL 8.0.16+ 支持逗号分隔，旧版需分多条） - 千万别直接改
mysql.user表字段（如把Select_priv改成Y）—— 这种操作绕过权限系统校验，MySQL 可能不识别，且重启后可能被覆盖
刷新权限后仍不生效？检查三个隐性卡点
FLUSH PRIVILEGES; 不是万能钥匙。很多“授完权还是报 1142”的情况，其实卡在连接层或缓存层。
实操建议：
- 客户端是否复用旧连接？PHP 的
mysql_connect()（已废弃）或某些长连接池（如 HikariCP）不会自动重载权限，必须断开重连才能加载新权限 - 用户 host 匹配是否精确？
'user'@'%'不等于'user'@'localhost'；若应用从本地 socket 连，MySQL 默认解析为localhost，而非127.0.0.1，授权时必须写对 - 是否启用了
skip-grant-tables？该模式下权限系统完全失效，所有GRANT操作都不起作用，需关闭并重启 mysqld
特殊对象权限容易漏掉：视图、存储过程、列级控制
1142 错误也可能出现在非普通表操作上，比如调用视图时报 EXECUTE command denied，或查某列时报 SELECT command denied for column xxx —— 这些权限默认不随表权限继承，必须显式授予。
实操建议：
- 访问视图 → 需要
SELECT视图本身权限，**且** 对视图底层所依赖的所有表都有相应权限（哪怕只是SELECT） - 执行存储过程 → 必须有
EXECUTE权限：GRANT EXECUTE ON PROCEDURE mydb.calc_total TO 'proc_caller'@'localhost'; - 列级权限（极少见但存在）→
GRANT SELECT(col1, col2) ON mydb.t1 TO 'limited'@'localhost';，此时查整表或其它列仍会触发 1142
权限系统不是开关，是细粒度的门禁网络。漏掉一个 ON database.table、写错一个 @'host'、忘了让应用重连，都足以让 GRANT 形同虚设。
