MySQL视图禁用CURRENT_USER()等非确定性函数，因其导致创建失败、性能下降及权限失控；安全脱敏需满足确定性表达式、显式SQL SECURITY设置及底层表权限控制。
直接用 VIEW 控制敏感字段可见性是可行的，但必须避开非确定性函数和权限失控陷阱——否则视图一查就报错，或者绕过权限直接暴露原始数据。
为什么不能在视图里用 CURRENT_USER() 做条件判断
MySQL 视图定义中禁止使用会话级函数（如 CURRENT_USER()、NOW()、RAND()），因为这会让视图变成“非确定性”，导致创建失败或查询报错 ERROR 1351 (HY000): View's SELECT contains a subquery in the FROM clause 类似错误。
- 即使语法侥幸通过（比如嵌套在子查询里），MySQL 也会拒绝缓存执行计划，每次查询都重解析，性能陡降
- 更关键的是：视图权限继承自定义者（DEFINER），不是调用者（INVOKER）。哪怕你写了
IF(CURRENT_USER() = 'admin', phone, '****')，普通用户查这个视图时，依然可能因 DEFINER 权限过高而拿到原始值 - 真实风险案例：DBA 用
DEFINER = 'root'@'%'创建视图，结果所有低权限用户都能透过视图看到未脱敏手机号
CREATE VIEW 脱敏必须满足的三个硬约束
只有同时满足这三条，视图才能稳定、安全、可维护：
- 所有字段表达式必须是确定性的：只允许
CONCAT()、LEFT()、RIGHT()、SUBSTRING()、SHA2()等纯函数；禁用IF()套会话变量、禁用子查询引用其他表（除非是单表投影） - 视图必须显式指定
SQL SECURITY DEFINER或SQL SECURITY INVOKER；生产环境强烈建议用INVOKER，避免权限越权 - 底层表的敏感列（如
phone、id_card）本身要设访问控制：对应用账号REVOKE SELECT(phone, id_card) ON users FROM 'app'@'%'，只放行视图权限
手机号/身份证号脱敏的两种安全写法对比
下面两个写法看起来效果一样，但第二个才是生产可用的：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- ❌ 危险写法（依赖隐式类型转换 + 长度不控）：
CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))—— 如果phone是VARCHAR(20)但存了空格或短号（如'138'），RIGHT(phone, 4)会返回空字符串，结果变成'138****'，暴露位数特征 - ✅ 安全写法（显式校验 + 截断兜底）：
CONCAT(LEFT(TRIM(phone), 3), '****', RIGHT(TRIM(phone), 4))，且建表时加CHECK(LENGTH(TRIM(phone)) = 11)约束 - 身份证号同理：用
CONCAT(LEFT(id_card, 6), REPEAT('*', 8), RIGHT(id_card, 4))比硬写'********'更可靠，避免因末位X导致长度计算偏差
视图无法解决的脱敏盲区，必须提前意识到
视图只是投影层改造，它不改变数据物理存储，也不影响索引行为：
- 脱敏字段（如
phone_masked）是计算列，WHERE phone_masked = '138****1234'必然触发全表扫描——别指望它能走索引 - 如果业务需要按脱敏后手机号做关联（比如和日志表匹配），必须在日志表里也存一份脱敏值，或改用
SHA2(phone, 256)做不可逆哈希关联（注意长度固定为 64 字符） - 视图无法实现“同一用户不同角色看不同精度”——比如管理员看前 7 位手机号，客服只看前 3 位。这种需求必须交由中间层拼 SQL 或用存储过程动态生成，视图做不到
真正难的不是写出脱敏 SQL，而是确保它在权限模型、索引策略、数据一致性三者之间不撕裂。一个没加 CHECK 约束的手机号字段，配上看似工整的视图，上线三天后就会在某条脏数据上崩出空值或截断异常。
