视图无法真正加密，仅支持条件脱敏；核心是case when结合current_user或current_setting实现行级访问控制与字段脱敏，而非密码学加密。
视图里不能真加密，只能做条件脱敏
SQL 视图本身不执行加密运算，CASE WHEN 也不是加密函数——它只是根据行数据动态决定返回明文还是占位符（比如 '***' 或 NULL）。真正加密得靠数据库函数（如 AES_ENCRYPT()、pgp_sym_encrypt()），但这类函数通常不支持在视图中直接使用（尤其涉及会话密钥或随机盐值时），且结果不可逆、无法索引、查询性能差。所以实际场景中，“行级加密视图”本质是行级**访问控制+字段脱敏**。
常见错误现象：CREATE VIEW v_user AS SELECT id, CASE WHEN current_user = 'admin' THEN phone ELSE AES_ENCRYPT(phone, 'key') END FROM users; —— 这在 MySQL 会报错，因为 AES_ENCRYPT() 在视图定义中不被允许（非确定性/含会话依赖）；PostgreSQL 同样拒绝在视图中调用需密钥参数的加密函数。
- 适用场景：后台管理看全量数据，前端 API 或普通账号只查脱敏字段
- 核心逻辑靠
CASE WHEN+ 当前用户/角色/租户 ID 判断，不是靠密码学 - 脱敏粒度可到列（如仅手机号）、到行（如
WHERE dept_id = current_dept()）、或组合（列+行）
MySQL / PostgreSQL 中用 CASE WHEN 做字段级动态脱敏
关键不是“怎么写 CASE”，而是怎么拿到判断依据——数据库没内置 current_user_role() 这种函数，得靠 CURRENT_USER、SESSION_USER、或提前注入的上下文变量（如 @current_tenant_id）。
MySQL 示例（依赖用户前缀区分权限）：
CREATE VIEW v_customer AS
SELECT id,
name,
CASE
WHEN CURRENT_USER LIKE '%admin@%' THEN phone
WHEN CURRENT_USER LIKE '%hr@%' THEN CONCAT(LEFT(phone,3), '****', RIGHT(phone,4))
ELSE '***'
END AS phone,
email
FROM customers;
PostgreSQL 示例（依赖 current_setting() 读取会话变量）：
CREATE VIEW v_order AS
SELECT id, amount,
CASE
WHEN current_setting('app.role', true) = 'finance' THEN account_no
WHEN current_setting('app.role', true) = 'ops' THEN LEFT(account_no, 4) || '****'
ELSE NULL
END AS account_no
FROM orders;
- MySQL 的
CURRENT_USER返回'user@host'格式，适合简单角色推断；USER()不可靠（可能含代理信息） - PostgreSQL 必须先
SET app.role = 'finance';才能生效，否则current_setting(..., true)返回NULL - 所有分支返回类型必须一致（如都为
TEXT），否则建视图失败
为什么不能在视图里用 ENCRYPT/DECRYPT 函数？
不是语法不让，是语义冲突。加密函数要求密钥稳定、输入确定、输出可复现；而视图是预编译的查询模板，不绑定具体执行上下文。当你在视图里写 AES_ENCRYPT(phone, 's3cr3t')，数据库无法保证每次查询都用同一密钥（尤其密钥存在配置表里时），更无法处理密钥轮换——解密时根本不知道该用哪一把密钥。
典型报错：
- MySQL：
ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled（开启 binlog 时强制要求函数声明确定性） - PostgreSQL：
ERROR: function pgp_sym_encrypt(unknown, unknown) is not immutable（视图只接受IMMUTABLE或STABLE函数） - 即使绕过报错（如 MySQL 关闭 binlog），结果也无法被业务系统安全消费——没有标准解密路径，应用层拿不到密文对应原始值
真正的行级加密该放在哪一层？
如果业务真需要加密存储（比如 PCI-DSS 要求信用卡号落库加密），加密动作必须发生在应用层或触发器里，而不是视图。视图只负责“按规则展示”，不负责“按规则转换”。
- 推荐做法：应用写入前调用
AES_ENCRYPT()或使用数据库透明加密（TDE）；视图里只做CASE WHEN脱敏 - 若坚持用数据库函数加密，改用存储过程封装加解密逻辑，并由应用显式调用，而非藏在视图里
- 注意：MySQL 8.0+ 的
VALIDATE_PASSWORD插件、PostgreSQL 的pgcrypto模块虽提供加密函数，但它们设计初衷是单次加解密，不是视图友好型
最常被忽略的一点：脱敏后的字段如果参与 JOIN 或 WHERE 条件，CASE WHEN 会导致索引失效——别指望对脱敏列建索引还能加速查询。
