必须指定数据库名，如GRANT SELECT ON myapp.orders TO 'user1'@'%'；漏写库名会导致授权到默认库；系统库不支持表级授权；需FLUSH PRIVILEGES生效；权限叠加时粗粒度覆盖细粒度；验证须用新连接执行实际查询。
如何用 GRANT 语句精确限制用户对单张表的访问
MySQL 支持直接对 database.table 粒度授予权限，但必须明确指定数据库名，不能只写表名。漏掉库名是新手最常踩的坑——你以为给了 user1 对 orders 表的权限，实际执行的是 GRANT SELECT ON orders TO 'user1'@'%'，这在语法上合法，但 MySQL 会把它当成对当前默认库（通常是 mysql）下的 orders 表授权，而非你目标库里的表。
- 正确写法必须带库前缀：
GRANT SELECT, INSERT ON myapp.orders TO 'user1'@'%' - 如果目标表在
information_schema或performance_schema，权限无效——这些系统库不支持表级授权 - 执行后记得
FLUSH PRIVILEGES，否则权限不会立即生效（尤其在非 root 用户修改后） - 权限生效依赖于连接时使用的数据库上下文：即使有
myapp.orders的 SELECT 权，若连接时没USE myapp，又用全限定名SELECT * FROM myapp.orders，仍可执行；但用SELECT * FROM orders就会报ERROR 1142 (42000): SELECT command denied
REVOKE 后权限没消失？检查权限层级叠加问题
MySQL 权限是叠加的，表级权限可能被库级或全局权限覆盖。比如你给用户 'user1'@'%' 授了 SELECT ON myapp.*，再单独 REVOKE SELECT ON myapp.orders，这个 REVOKE 实际无效——因为库级权限依然存在，且优先级高于表级拒绝（MySQL 不支持“拒绝”语义，只有“授予”和“未授予”）。
- 真正要禁用某张表，必须先
REVOKE所有更粗粒度的权限（如库级），再显式授予其余表 - 查当前用户实际生效权限用：
SHOW GRANTS FOR 'user1'@'%'，注意输出里是否还残留ON myapp.*这类宽泛条目 -
mysql.user、mysql.db、mysql.tables_priv这三张权限表是分层存储的，tables_priv只管表级，但只要db表里对应库的权限位为 Y，它就盖过tables_priv的细粒度设置
使用 mysql_native_password 认证时，权限变更延迟的真相
如果你用的是较新 MySQL（8.0+）且用户认证插件是 mysql_native_password，改完权限后立刻用客户端重连却仍报错，不是权限没生效，而是客户端缓存了旧的身份验证信息。特别是某些连接池（如 Python 的 pymysql 或 Java 的 mysql-connector-java）在复用连接时，不会重新校验权限。
- 测试权限是否真生效，务必用新连接：断开后重新
mysql -u user1 -p -D myapp - 避免在生产环境用
FLUSH PRIVILEGES频繁操作，它会清空整个权限缓存，对高并发实例有短暂性能抖动 - 如果应用使用连接池，重启池或设短
maxLifetime值，强制重建连接
为什么 SHOW CREATE TABLE 能执行，但 SELECT 却被拒绝
这是权限设计的隐性逻辑：SHOW CREATE TABLE 只需要 SELECT 权限或 SHOW VIEW 权限（对视图），但它不校验你是否有权读该表的数据。换句话说，你能看到建表语句，不代表你能查数据——表结构元信息和行数据访问是两套权限控制路径。
- 确认是否误授了
SHOW VIEW或SELECT在mysql库（比如SELECT ON mysql.columns_priv），导致能看结构但不能查业务数据 - 检查用户是否被授予了
PROCESS权限：它允许查看其他线程信息，但跟表访问无关，别混淆 - 最稳妥的验证方式是用该用户身份直连后执行
SELECT COUNT(*) FROM myapp.orders LIMIT 1，而不是依赖任何元数据命令
表级权限看似简单，但实际生效依赖库名完整、权限无叠加、连接无缓存、验证方式不取巧——四个条件缺一不可。最容易被忽略的是：你写的那条 GRANT 语句，到底作用在哪个库上。
