能，必须先收回基表select权限再授视图权限，视图中硬编码脱敏逻辑（如concat+ifnull），并设sql security definer配合user()做角色判断，否则用户可直查原表。
做不到“只访问加密后的脱敏数据表”——MySQL 没有字段级加密访问权限机制，AES_DECRYPT() 不是权限开关，视图里的 CONCAT() 也不是自动拦截器。真正能落地的方案只有两个：权限回收 + 视图封装，且必须严格按顺序执行。
必须先 REVOKE SELECT 基表权限，否则视图形同虚设
只要用户对 user_table 有 SELECT 权限，他就能绕过任何视图直接查原始手机号、身份证号。这不是配置遗漏，是 MySQL 权限模型的底层逻辑。
- 先确认当前权限：
SHOW GRANTS FOR 'reporter'@'%'; - 显式收回基表权限：
REVOKE SELECT ON mydb.user_table FROM 'reporter'@'%'; - 再授视图权限：
GRANT SELECT ON mydb.v_user_masked TO 'reporter'@'%'; -
FLUSH PRIVILEGES;不需要——GRANT/REVOKE已写入系统表并即时生效
脱敏逻辑必须硬编码在视图定义中，不能依赖参数或函数传参
MySQL 视图不支持参数，CASE WHEN USER() = 'reporter'@'%' 是唯一可行的角色判断方式，但前提是视图必须用 SQL SECURITY DEFINER 定义，否则 USER() 返回的是调用者身份，无法区分角色。
- 建视图时必须指定定义者：
CREATE DEFINER='admin'@'localhost' SQL SECURITY DEFINER VIEW v_user_masked AS ... - 用
USER()判断，不是CURRENT_USER()（后者返回定义者身份） - 所有字符串操作必须包
IFNULL()：CONCAT(IFNULL(LEFT(phone, 3), ''), '****', IFNULL(RIGHT(phone, 4), ''))，否则任一字段为NULL整列变NULL - 数字类型字段（如
phone BIGINT）必须先CAST(phone AS CHAR)再处理，否则报错Truncated incorrect DOUBLE value
视图无法防御 SELECT * 或跨库 JOIN，权限才是唯一防线
用户执行 SELECT * FROM v_user_masked 看到的是脱敏值，但一旦他在应用里拼出 SELECT u.name, r.email FROM v_user_masked u JOIN otherdb.raw_user r ON u.id = r.id，而他又恰好有 otherdb 的权限，脱敏就彻底失效。
- 视图字段名和原表一致时，ORM 自动生成的
SELECT *可能触发元数据缓存，导致客户端误以为字段仍是明文 - 不能靠视图字段别名“骗过”应用层，真正有效的隔离只有一条：
REVOKE SELECT ON otherdb.raw_user FROM 'reporter'@'%'; - 如果业务真需跨表关联，必须把关联逻辑也写进同一个视图里，且确保关联表同样被权限隔离
最常被忽略的点：字段类型不匹配会静默失败或报错，测试时一定要覆盖 NULL、空字符串、带括号/空格的手机号（如 '(010) 1234-5678'）、邮箱含 @ 符号等边界样本——这些不是异常数据，而是生产环境真实存在的输入。
