MySQL列级权限不能精确控制。它仅限制显式指定列名的SELECT语句，对SELECT *、视图、存储过程等完全失效，且不支持动态过滤或真正脱敏，无法满足GDPR等合规要求。
MySQL 列级权限到底能不能精确控制？
不能。MySQL 原生不支持真正的列级 SELECT、UPDATE 或 INSERT 权限隔离——所谓“列级权限”，只是对 SELECT 语句中显式指定列名时的访问限制，且仅作用于整个表的列集合，不支持按用户/角色动态过滤。它不是行级或列级视图那种逻辑隔离，而是一道非常脆弱的语法门禁。
GRANT 语句里写列名真的有用吗？
有用，但范围极窄：只对直接执行 SELECT col1, col2 FROM t 这类明确列出列名的查询生效；一旦用 SELECT *、触发器、存储过程、或通过视图/中间件访问，该限制即失效。而且它只控制 SELECT，对 UPDATE (col1)、INSERT 的列白名单也仅检查语句是否越权，不阻止通过其他列间接推导敏感值。
常见错误现象：GRANT SELECT (name, email) ON db.user TO 'report'@'%' 后，用户仍能通过 SELECT * FROM user 报错（被拒绝），但只要换条路——比如创建临时视图 CREATE VIEW v AS SELECT * FROM user（若已有 CREATE VIEW 权限），再查 SELECT * FROM v，就绕过了列限制。
实操建议：
- 列级
GRANT仅适合审计要求低、且所有客户端严格禁止用*的封闭内网环境 - 永远不要把它当作脱敏或合规手段，比如 GDPR 或等保三级都不认这个
- 若真需列级控制，必须配合应用层过滤或数据库代理（如 ProxySQL + 自定义规则）
替代列级权限的三种实际可行方案
真正落地的安全控制，得绕过 MySQL 权限系统的先天缺陷：
1. 视图 + 权限隔离
为不同角色建专用视图，只暴露必要列，并授 SELECT 权限给视图而非基表：
CREATE VIEW user_public AS SELECT id, name, avatar FROM user; GRANT SELECT ON db.user_public TO 'app_read'@'%';
注意：视图本身不加密、不防 SQL 注入，且管理员仍可查基表——所以要回收基表所有权限。
2. 应用层字段裁剪
在 ORM 或 DAO 层硬编码白名单，例如 Python 中用 SQLAlchemy 显式指定 query(User.id, User.name)，绝不拼接 *；Node.js 中用 Knex 指定 .select('id', 'name')。这是目前最可控的方式。
3. 使用 MySQL 8.0+ 的数据脱敏函数（有限场景）
DBMS_REDACT 不是权限机制，而是运行时掩码，只对 SELECT 结果生效，且需企业版。社区版只能靠 CASE WHEN 手动脱敏，例如：
SELECT id, name, CASE WHEN CURRENT_USER() = 'admin'@'%' THEN phone ELSE '***-****-****' END AS phone FROM user;
最容易被忽略的权限陷阱
很多人以为关掉 FILE、PROCESS、SUPER 就安全了，其实更危险的是：
-
SHOW VIEW权限：一旦开启，用户可SHOW CREATE VIEW看到视图定义，从而反推出基表结构和隐藏列 -
SELECT权限配INFORMATION_SCHEMA.COLUMNS：能直接查出所有表的列名、类型、是否允许 NULL，为暴力探测打下基础 - 未撤销的
USAGE：新用户建连后默认有USAGE，虽无操作权，但会干扰权限排查（表现为“没报错却查不到数据”）
真正需要列级控制的场景，几乎都意味着你已经处在高合规要求环境里——这时候别省那点代理或中间件的钱，MySQL 的权限模型从设计上就不承担这个责任。
