能，GRANT语句可直接授权到列，仅限SELECT、UPDATE、INSERT且须显式列出列名；MySQL 8.0+支持，5.7及更早不支持；列权限与表权限叠加生效，不自动撤销已有权限。
GRANT 语句能直接授权到列吗？
能，但仅限于 SELECT、UPDATE、INSERT 这三类操作，且必须显式列出列名。例如：GRANT SELECT (id, name) ON users TO 'reporter'@'%'; —— 这会允许该用户查 id 和 name，但查不到 salary 或 phone。
常见错误是写成 GRANT SELECT ON users(id, name)（语法错），或漏掉括号里的列名直接 GRANT SELECT ON users（变成整表授权）。
- MySQL 8.0+ 支持列级
GRANT；5.7 及更早版本不支持，强行执行会报错ERROR 1064 (42000) -
UPDATE列授权后，用户仍可对未授权列执行SET col = col（空更新），但不能设新值——这点常被忽略 - 列权限和表权限叠加生效：如果用户已有整表
SELECT权限，再授部分列权限不会自动撤销其他列访问权
视图脱敏比 GRANT 更可靠吗？
是的，尤其当需要动态隐藏、变形或条件过滤时。视图把脱敏逻辑固化在定义里，权限只需给视图本身，不依赖底层列权限控制。
比如用 CONCAT('***', SUBSTRING(phone, -4)) 生成脱敏手机号，或用 CASE WHEN dept = 'HR' THEN salary ELSE NULL END 控制薪资可见性。
- 创建视图需
CREATE VIEW权限，且定义中引用的表/列用户必须有对应访问权（否则CREATE VIEW会失败） - MySQL 中视图默认以
DEFINER身份执行，若DEFINER是高权限账号（如root@localhost），即使当前用户没底层表权限，也能查视图——这是脱敏安全的关键机制 - 注意
ALGORITHM = TEMPTABLE视图无法被下推谓词优化，大数据量时性能可能明显下降
WHERE 条件里字段不可见，还能走索引吗？
取决于脱敏方式。如果是视图里用函数包裹列（如 MD5(email) 或 LEFT(name, 2)），那这个列在视图中就不再是原始索引字段，WHERE 用它基本等于全表扫描。
真正能保留索引能力的做法，是用视图 + 基础列投影 + 外层查询过滤。例如视图只选 id, name, dept，不加工；敏感字段如 salary 根本不投出；这样外层 WHERE dept = 'tech' 仍可命中 dept 索引。
- 避免在视图定义里对用于查询过滤的字段做任何计算、类型转换或
CASE表达式 - MySQL 8.0 的函数索引（
CREATE INDEX idx_email_md5 ON users ((MD5(email)))）可缓解部分场景，但应用层需同步改写查询条件，兼容成本高 - 列权限本身不影响索引使用——只要用户能访问该列，查询计划就和普通查询一致
权限变更后，连接池里的旧连接还生效吗？
生效，而且不会自动失效。MySQL 的权限检查发生在语句执行时，不是连接建立时。也就是说，一个已存在的连接，在你 REVOKE 或 FLUSH PRIVILEGES 后，仍能继续执行它原本有权限的操作，直到该连接断开或显式 RELOAD（极少见）。
这意味着线上服务如果用了长连接池（如 HikariCP、Druid），改完权限后必须滚动重启或清空连接池，否则脱敏策略形同虚设。
-
FLUSH PRIVILEGES不是万能的，它只刷新内存权限缓存；某些权限（如列权限）在 MySQL 中实际由mysql.columns_priv表驱动，修改后需确保该表持久化且服务已加载 - 用
SHOW GRANTS FOR 'user'@'host'查看到的是当前生效权限，但无法反映连接池中活跃连接的实际能力 - 最稳妥的做法：权限调整后，主动 kill 对应用户的连接（
KILL [connection_id]），或设置wait_timeout缩短闲置时间，让旧连接自然退出
