MySQL表级权限能单独限制，但必须用GRANT显式授予db_name.table_name格式的权限，缺库名、错符号或误用通配符均导致失败，且需FLUSH PRIVILEGES刷新内存权限。
MySQL 表级权限到底能不能单独限制
能，但必须用 GRANT 显式授予，且不能依赖数据库级或全局权限“顺带覆盖”。MySQL 默认不给任何表级权限，哪怕用户有 SELECT 权限在库上，也不自动拥有该库下所有表的访问权——这点常被误判为“权限没生效”，其实是压根没授。
GRANT 语句里怎么写表名和列名
表级权限必须精确到 db_name.table_name 格式；列级更细，得列出来。漏掉库名、用通配符 * 代替表名、或把点号写成下划线，都会让授权失败或授错对象。
-
GRANT SELECT ON mydb.users TO 'appuser'@'%';✅ 仅允许查mydb库的users表 -
GRANT INSERT, UPDATE (email, status) ON mydb.users TO 'appuser'@'%';✅ 只能改这两列，其他字段不可碰 -
GRANT SELECT ON mydb.* TO 'appuser'@'%';❌ 这是库级，不是表级，会绕过你原本想卡死的单表控制 -
GRANT SELECT ON users TO 'appuser'@'%';❌ 缺少库名，MySQL 会报错ERROR 1144 (42000): Illegal GRANT/REVOKE command
执行完 GRANT 为什么还是连不上或报错拒绝
常见三个断点：权限没刷进内存、用户 host 不匹配、旧连接缓存了旧权限。MySQL 的权限检查是实时查内存里的 mysql.tables_priv 等系统表，不是每次读磁盘。
- 执行完
GRANT后必须跟FLUSH PRIVILEGES;（虽然多数情况下自动刷新，但生产环境别赌） - 确认
'appuser'@'%'和你实际连接时用的 host 完全一致——'appuser'@'localhost'和'appuser'@'127.0.0.1'是两个不同用户 - 已存在的连接不会自动更新权限，得让应用重连，或手动
KILL对应线程 - 如果用的是 MySQL 8.0+，还要注意角色（role）是否间接赋予了更高权限，会覆盖表级限制
表级权限和性能、复制有没有隐性影响
几乎没有。表级权限只影响语句解析阶段的权限检查，不改变查询计划、不增加锁开销、也不影响 binlog 内容。但要注意：如果用 mysqldump 或逻辑备份工具导出单表，而用户没有 SHOW VIEW 或 LOCK TABLES 权限，可能在备份时失败，这不是表级权限本身的问题，而是工具链默认需要的额外权限。
真正容易被忽略的是：视图（VIEW）和存储过程（PROCEDURE）的权限是独立管理的。即使你严格限制了基表，但若用户有对某个视图的 SELECT 权限，而该视图又跨表查询，就等于绕过了你的表级围栏。
