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 的权限模型从设计上就不承担这个责任。
