grant select on db_name.table_name 是唯一正确写法，漏库名会导致授权到 mysql 系统库或报错；必须显式指定库表、用反引号防关键字冲突、匹配 host、执行 flush privileges 生效，并查 mysql.tables_priv 确认落库。
GRANT SELECT ON db_name.table_name 是唯一正确写法
漏掉数据库名就等于授权失败——MySQL 不会默认用你当前连接的库，而是落到 mysql 系统库或报错。比如执行 GRANT SELECT ON orders TO 'u'@'%'，实际是给 mysql.orders 授权，而非你业务库里的表。
必须显式写出库名和表名，格式严格为 GRANT SELECT ON `mydb`.`mytable` TO 'u'@'%'：
- 库名和表名建议用反引号包裹，避免关键字冲突（如
`order`） - 主机名部分必须匹配用户实际连接来源，
'u'@'10.0.1.%'无法登录来自10.0.2.5的请求 - 权限语句不区分大小写，但推荐统一小写保持可读性
FLUSH PRIVILEGES 不是可选项，是生效前提
即使 GRANT 执行成功，新权限也不会立刻对已有连接生效，更不会自动加载进内存权限缓存。尤其在非 root 用户修改后，或使用 mysql_native_password 插件时（MySQL 8.0+ 默认），客户端可能复用旧认证上下文，导致重连后仍报 ERROR 1142。
执行完 GRANT 后必须立即运行：
FLUSH PRIVILEGES;
注意：FLUSH PRIVILEGES 是全局操作，不需要指定数据库；它刷新的是内存中的权限缓存，不是磁盘表数据。
SHOW GRANTS 可能不显示你刚授的权限
执行 SHOW GRANTS FOR 'u'@'%' 时，如果只看到 USAGE ON *.* 或库级条目，不代表授权失败——MySQL 只在用户拥有该库下「任意一张表的显式权限」时，才把整个库作为上下文展示。否则，它只会逐条列出你真正 GRANT 过的单表权限。
要确认权限是否落库，直接查底层表：
SELECT * FROM mysql.tables_priv WHERE User='u' AND Host='%' AND Db='mydb' AND Table_name='mytable';
如果这一行存在且 Table_priv 字段包含 Select，说明权限已写入磁盘。
视图、依赖表、SQL SECURITY 都会影响最终可查性
哪怕 GRANT SELECT ON mydb.v_summary 成功，查询时仍报 SELECT command denied for table 'v_summary'，大概率是因为：
- 视图定义中引用的基表（如
t_user、t_order）没给该用户SELECT权限 - 视图设置了
SQL SECURITY DEFINER，但DEFINER账户已失效或无权访问依赖对象 - 用户连接时未
USE mydb，又用了非全限定名查询（如SELECT * FROM v_summary而非SELECT * FROM mydb.v_summary）
最稳妥的做法：先用 SHOW CREATE VIEW v_summary 拆出所有依赖对象，再逐一确认权限；若用 DEFINER，务必确保其长期可用。
