视图脱敏必须三要素齐备：视图封装+基表权限回收+字段重命名。缺一环则敏感数据裸奔；直接用CONCAT脱敏无效，因用户可绕过视图直查基表；须显式回收基表SELECT权限并仅授予视图权限，且脱敏字段需加_masked后缀、声明SQL SECURITY DEFINER。
视图本身不脱敏，也不控制权限——它只是个查询封装。真正起效的是“视图 + 显式权限回收 + 字段重命名”三者缺一不可。漏掉任意一环，敏感数据就等于裸奔。
为什么直接用 CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) 写视图会失效
这个表达式能跑通，但完全不安全。问题不在函数，而在权限链路没切断：
- 用户只要还有
SELECT权限在基表（如users）上，就能绕开视图，直接执行SELECT phone FROM users拿到明文 -
CONCAT、LEFT等函数不触发任何权限检查，MySQL/PostgreSQL 也没有列级动态脱敏机制 - 视图里若定义了
phone列，而基表也有同名phone（明文），BI 工具或 ORM 可能按元数据自动映射，导致下游代码误把脱敏值当原始字段用
必须显式回收基表权限并只授视图权限
建完视图后这一步不能跳过，否则前面所有脱敏逻辑都白做：
- 执行
REVOKE SELECT ON users FROM 'app_user'@'%'—— 彻底切断直查通路 - 再执行
GRANT SELECT ON v_users TO 'app_user'@'%'—— 只允许走视图出口 - MySQL 8.0+ 推荐用角色：先
CREATE ROLE role_read_masked，再GRANT SELECT ON v_users TO role_read_masked，最后把角色授给用户，避免漏授或误授 - 检查是否残留权限：
SHOW GRANTS FOR 'app_user'@'%'，确认结果里没有ON users字样
CASE WHEN 脱敏必须三层兜底处理 NULL、空值和长度异常
直接写 LEFT(phone, 3) 很危险，实际运行中极易崩：
- 当
phone是NULL时，LEFT(NULL, 3)返回NULL，脱敏结果变成空，不是*** - 当
phone = ''或只有 2 位（比如录入错误），LEFT可能截断失败或返回意外结果 - 正确做法是显式覆盖所有边界：
CASE WHEN phone IS NULL THEN '***' WHEN TRIM(phone) = '' THEN '***' WHEN LENGTH(TRIM(phone)) = 11 THEN CONCAT(LEFT(TRIM(phone), 3), '****', RIGHT(TRIM(phone), 4)) ELSE '****' END AS phone_masked - 别用
CURRENT_USER()做身份判断——它返回的是视图DEFINER身份；要用USER()才能拿到真实调用者
脱敏字段名必须加 _masked 后缀，且视图要声明 SQL SECURITY DEFINER
这是防止下游误用和权限错位的关键细节：
- 视图字段必须用
phone_masked、id_card_masked、email_masked这类明确后缀，杜绝与基表同名字段混淆 - MySQL 创建视图时必须显式写
SQL SECURITY DEFINER，否则默认行为不可控；DEFINER应设为高权限账号（如'admin'@'localhost'），确保视图以该身份执行，绕过调用者权限限制 - PostgreSQL 创建含表达式的视图时，还必须显式声明列名：
CREATE VIEW v AS SELECT ... AS phone_masked，否则报错 - 脱敏列不可用于
WHERE或JOIN——它是计算列，查询计划阶段还没执行，数据库根本无法识别该字段
最常被忽略的点是：视图定义里没写 DEFINER 和 SQL SECURITY DEFINER，或者忘了查 SHOW GRANTS 确认基表权限是否真被收回。这两处一漏，整个脱敏方案就形同虚设。
