MySQL表级权限用GRANT SELECT ON db.table授予，列级权限需括号指定字段如GRANT SELECT(name,phone) ON db.users；权限叠加生效但列级会收窄范围，已存连接不自动更新权限。

MySQL 中如何给用户授予表级权限

直接用 GRANT 指定数据库和表名即可，权限作用范围精确到 db_name.table_name。不加表名（如 db_name.*）是库级；加了就是表级。

常见错误：误以为 GRANT SELECT ON db_name.* TO 'u'@'h' 能限制到某张表——它实际允许访问该库下所有表。

• 只允许查 orders 表：

  GRANT SELECT ON myapp.orders TO 'reporter'@'192.168.1.%';

• 允许多个操作（INSERT/UPDATE）但仅限 logs 表：

  GRANT INSERT, UPDATE ON myapp.logs TO 'logger'@'localhost';

• 执行后必须 FLUSH PRIVILEGES; 才生效（仅在直接操作 mysql 系统表后才强制需要，常规 GRANT 一般不用）

列级权限怎么设：只让看某些字段

MySQL 支持列级 SELECT、INSERT、UPDATE 权限，但不支持 DELETE 或 REFERENCES 的列级控制。语法是在 GRANT 后用括号列出列名。

典型场景：客服只能看到用户表的 name 和 phone，不能查 id_card 或 password_hash。

• 只授权读两列：

  GRANT SELECT (name, phone) ON myapp.users TO 'cs_agent'@'%';

• 插入时只允许填部分字段：

  GRANT INSERT (username, email, created_at) ON myapp.users TO 'app_writer'@'10.0.0.%';

• UPDATE 列权限要求更严格：如果某用户只有 UPDATE (status) 权限，连 UPDATE status = 'done' WHERE id = 123 都会报错——因为 WHERE 里用了未授权的 id 列

权限冲突时谁生效：表级 vs 列级

MySQL 权限检查是“叠加式”的：只要任意一级（列、表、库、全局）授予了某权限，且没有被显式 REVOKE，该权限就有效。但列级权限不会覆盖表级限制，而是进一步收窄可操作范围。

例如：GRANT SELECT ON myapp.users TO 'u'@'h' + GRANT SELECT (email) ON myapp.users TO 'u'@'h'，最终效果等同于只授权 email 列——因为列级 SELECT 会隐式撤销其他列的访问权。

• 不能混用矛盾授权：先给全表 SELECT，再给单列 SELECT，后者会生效；但反过来（先列后全表），全表授权会覆盖列级限制
• REVOKE 必须匹配原授权粒度：用列级 GRANT 授的权，就得用列级 REVOKE 撤，否则撤不掉
• 查看当前用户的列级权限：查 mysql.columns_priv 表，注意 is_active 字段是否为 Y

权限变更后连接不生效？注意连接复用和缓存

MySQL 用户权限在服务端内存中缓存，新连接会立即读取最新权限，但已存在的连接不会自动刷新。这是最常被忽略的“改了权限却没用”的原因。

• 应用使用连接池时，旧连接可能持续数小时，期间权限修改完全无效
• 验证方法：用 SHOW GRANTS FOR 'user'@'host'; 在目标连接中执行，确认看到的是预期权限
• 强制重载权限（极少需手动）：FLUSH PRIVILEGES;，但日常运维中应避免依赖它——优先让应用重建连接
• 列级权限对 INFORMATION_SCHEMA.COLUMNS 无影响，用户仍能看到所有列名，只是查数据时被拦截