MySQL 8.0+动态脱敏视图必须显式指定DEFINER并设SQL SECURITY DEFINER，用USER()判断调用者身份，严格隔离基表权限，手动适配各字段类型脱敏逻辑，且需FLUSH TABLES刷新元数据。
MySQL 8.0+ 动态脱敏视图必须用 DEFINER 权限才能生效
动态脱敏的核心不是加密数据，而是控制「谁查到什么」。MySQL 原生不支持字段级行级脱敏，得靠视图 + SQL SECURITY DEFINER 拦截查询路径。如果创建视图时没显式指定 DEFINER，默认用调用者身份执行（SQL SECURITY INVOKER），那脱敏逻辑就完全失效——用户绕过视图直接查基表，或者连视图都查不到敏感字段。
-
CREATE VIEW必须带DEFINER = 'admin'@'%'，且该账号要有基表SELECT权限 - 普通用户只授视图的
SELECT权限，**绝不授予基表权限** - 脱敏逻辑写在视图定义里，比如用
CASE WHEN CURRENT_USER() = 'reporter'@'%' THEN phone ELSE CONCAT(LEFT(phone,3), '****', RIGHT(phone,4)) END - 注意：
CURRENT_USER()返回的是定义者身份，USER()才是调用者——脱敏判断必须用USER()
敏感字段类型不同，脱敏函数要手动适配
MySQL 没有统一的 DESENSITIZE() 函数，手机号、身份证、邮箱、金额等必须分别处理，而且要注意字段类型隐式转换导致的报错。
- 手机号/身份证：用
CONCAT(LEFT(col,3), '****', RIGHT(col,4))，但前提是col是字符串类型；如果是BIGINT存的手机号，先转成CHAR：CONCAT(LEFT(CAST(phone AS CHAR),3), '****', RIGHT(CAST(phone AS CHAR),4)) - 邮箱：用
CONCAT(SUBSTRING_INDEX(email, '@', 1), '@', SUBSTRING_INDEX(email, '@', -1))只能取前后缀，真要掩码用户名部分得嵌套LEFT/RIGHT - 金额类字段（如
DECIMAL）不能直接拼字符串，否则查询会报Truncated incorrect DOUBLE value错误；需先CAST(amount AS CHAR)再处理
视图无法拦截 SELECT * 或跨库 JOIN 的脱敏漏洞
只要用户有基表权限，或视图被用于 JOIN 场景，脱敏就可能被绕过。这不是 bug，是 MySQL 视图机制的天然限制。
- 如果给用户授了基表
SELECT权限，哪怕他从不主动查基表，SELECT * FROM sensitive_view JOIN other_table也可能触发优化器下推，绕过视图逻辑 -
SELECT *查视图时，如果基表字段改名或新增字段，视图不会自动更新结构，容易漏脱敏或报错Unknown column - 跨数据库 JOIN（比如
sensitive_db.user_info和log_db.access_log）时，即使user_info用了脱敏视图，JOIN 后结果仍可能暴露原始字段——因为视图只封装单表查询逻辑 - 解决方案只有两个：彻底回收基表权限；所有业务 SQL 强制走视图别名，禁止
*，并在应用层做字段白名单校验
权限变更后视图不会自动刷新，必须手动 FLUSH TABLES
给新用户授权、或修改 DEFINER 账号权限后，已存在的视图不会感知变化。用户可能突然查不到数据，或脱敏失效，但错误信息里完全看不出关联。
- 添加新角色权限后，执行
FLUSH TABLES（不是FLUSH PRIVILEGES）强制重载视图元数据 - 如果用的是 MySQL 8.0.22+，可配合
information_schema.VIEWS查DEFINER和SECURITY_TYPE字段确认状态 - 最易忽略的一点：视图依赖的函数或自定义函数（UDF）如果被删或改权限，视图查询会直接报
ERROR 1356: View references invalid table(s) or column(s)，但这个错误和权限无关，容易误判
脱敏视图本质是权限网关，不是数据保险箱。只要基表权限没卡死、DEFINER 账号权限过大、或业务 SQL 不规范，一层视图挡不住任何有意绕过的操作。
