列级权限必须显式指定字段，不能继承库级授权；需用GRANT SELECT(col1,col2)语法精确授权，不支持通配符；敏感字段应先授表级权限再用REVOKE剔除；推荐结合角色管理实现团队权限统一控制。
列级权限必须显式指定字段，不能靠库级授权“继承”
MySQL 的权限检查是逐层收敛的，但列级权限（COLUMN）不会从数据库或表级自动获得。哪怕你已经执行了 GRANT SELECT ON mydb.users TO 'dev'@'%'，该用户依然无法查 users 表里的任何字段——除非你额外声明列名。
常见错误现象：执行 SELECT * FROM users 报错 ERROR 1142 (42000): SELECT command denied to user 'dev'@'%' for table 'users'，但 SELECT id FROM users 却能成功，说明列权限已部分生效，只是没覆盖全部字段。
- 语法必须带括号和具体列名：
GRANT SELECT (name, email) ON mydb.users TO 'dev'@'%' - 不支持通配符：
SELECT (*)或SELECT (id, *)是非法写法 - 多个列用英文逗号分隔，**不能有空格**：
SELECT (name,email)合法，SELECT (name, email)在某些客户端会解析失败 - 若需更新某几列，
UPDATE权限也得单独授：GRANT UPDATE (phone, address) ON mydb.users TO 'dev'@'%'
敏感字段必须用 REVOKE 剥离，不能只靠“不授予”
新建用户后，即使你只授了 SELECT (name, email)，也不能认为其他字段就绝对安全——因为 MySQL 默认对未显式授权的列返回拒绝，但一旦后续有人误加了 GRANT SELECT ON mydb.users TO 'dev'@'%'（表级全读），所有列立刻可查。
更稳妥的做法是先给宽泛权限，再用 REVOKE 精确剔除：
- 先授表级读：
GRANT SELECT ON mydb.users TO 'dev'@'%' - 再剔除敏感列：
REVOKE SELECT (password_hash, last_login_ip) ON mydb.users FROM 'dev'@'%' - 注意：
REVOKE只能撤销之前GRANT过的列权限；如果从未授过，REVOKE无效且不报错 - 执行完务必验证：
SHOW GRANTS FOR 'dev'@'%'会列出所有有效权限，包括列级项
列级权限 + 角色组合才能落地到团队场景
直接对每个开发人员执行一堆 GRANT SELECT (col1,col2) ON ... 很难维护。MySQL 8.0 的角色机制是解耦列权限与人的关键。
- 创建角色并授列权限：
CREATE ROLE 'user_ro_basic'; GRANT SELECT (id, name, email) ON mydb.users TO 'user_ro_basic'; - 把角色赋予用户：
GRANT 'user_ro_basic' TO 'zhangsan'@'192.168.1.%'; - 必须激活：
SET DEFAULT ROLE 'user_ro_basic' TO 'zhangsan'@'192.168.1.%';，否则登录后权限为空 - 如需扩展权限（比如加查
created_at），只需更新角色：GRANT SELECT (created_at) ON mydb.users TO 'user_ro_basic';，所有绑定该角色的用户立即生效
列级权限在应用连接时容易被 ORM 绕过
很多 ORM（如 Django、Laravel Eloquent）默认生成 SELECT *，而列级权限会直接拦截这类语句——不是报错，而是返回空结果集或字段缺失，导致业务逻辑异常却难以定位。
- 测试阶段务必用真实 SQL 模拟 ORM 行为：
SELECT * FROM users和SELECT id,name FROM users分别验证 - 避免在生产环境依赖列级权限做“字段脱敏”，它本质是访问控制，不是数据掩码；真要隐藏字段，应在应用层或视图中处理
- 使用视图封装列权限更可控：
CREATE VIEW users_public AS SELECT id, name, email FROM users;，然后只授SELECT视图权限，比直接管原表列更清晰 -
INFORMATION_SCHEMA.COLUMNS不受列级权限限制，用户仍能看到所有列名——这不是漏洞，是设计使然
列级权限真正起效的前提，是你已经放弃“用一个账号跑所有服务”的念头；它天然属于精细化治理场景，一旦混用表级和列级授权、跳过角色抽象、或忽略 ORM 的实际 SQL 行为，就很容易变成“以为锁住了，其实开着缝”。
