MySQL无开箱即用字段级动态脱敏，须通过VIEW+显式权限隔离+手动脱敏逻辑实现，核心是控制访问而非模糊数据，缺任一环节即失效。
MySQL 本身不提供开箱即用的字段级动态脱敏功能，必须靠 VIEW + 显式权限隔离 + 手动脱敏逻辑组合实现。核心不是“让数据变模糊”，而是“让不该看的人查不到明文”。只要漏掉任一环节——比如忘了 REVOKE 基表权限，或用了 CURRENT_USER() 判断身份——脱敏就形同虚设。
CREATE VIEW 必须显式指定 DEFINER 和 SQL SECURITY DEFINER
这是整个方案生效的前提。MySQL 默认创建视图时用当前用户作为 DEFINER，且默认 SQL SECURITY DEFINER，但显式写出才能确保行为可预期、可审计。
- 不写
DEFINER：如果创建者账号后来被删或权限降级，视图可能直接失效 - 误用
SQL SECURITY INVOKER：权限检查会切到调用者，用户必须同时有基表权限，脱敏逻辑就失去意义 - 正确写法示例：
CREATE VIEW v_user_safe AS SELECT id, name, CASE WHEN USER() = 'admin'@'%' THEN phone ELSE CONCAT(LEFT(CAST(phone AS CHAR), 3), '****', RIGHT(CAST(phone AS CHAR), 4)) END AS phone FROM users;
注意这里用了USER()而非CURRENT_USER()，因为后者返回的是DEFINER身份（如'admin'@'%'），永远无法区分真实调用者
敏感字段类型不同，脱敏表达式必须手动适配
MySQL 没有统一的 DESENSITIZE() 函数，字段类型决定你能不能直接套用 LEFT() 或 CONCAT()。常见坑点都在隐式转换上。
-
phone是BIGINT？必须先CAST(phone AS CHAR)，否则LEFT(phone, 3)报错或截断异常 -
email是VARCHAR？用SUBSTRING_INDEX(email, '@', 1)取用户名，再嵌套LEFT(..., 1)+'***'拼接，不能只靠SUBSTRING_INDEX简单拆分 -
salary是DECIMAL(10,2)？不能CONCAT(salary, ' 元')，得先CAST(salary AS CHAR)，否则触发Truncated incorrect DOUBLE value - 所有脱敏字段都要包一层
IFNULL(..., '')，否则源值为NULL时整列返回NULL，前端容易空指针
GRANT 权限必须严格收口，且要清理历史残留
视图脱敏能起效的唯一前提是：用户对基表**完全不可见**。而 MySQL 权限是叠加的，旧授权不撤销，新视图就是摆设。
- 先查清现状：
SHOW GRANTS FOR 'reporter'@'%'，重点看有没有SELECT ON `db_name`.*这类宽泛授权 - 显式回收：
REVOKE SELECT ON db_name.users FROM 'reporter'@'%'，不能只依赖“没授就不给” - 只授视图：
GRANT SELECT ON db_name.v_user_safe TO 'reporter'@'%'，注意语法是db.view，不是db.table - 别乱跑
FLUSH PRIVILEGES：GRANT/REVOKE后自动生效；真要刷新，只在直改mysql系统表后才需要
视图无法覆盖的脱敏盲区必须提前识别
这不是 bug，是 MySQL 视图机制的硬限制。一旦出现以下任一情况，脱敏逻辑就可能被绕过，得靠流程或架构补位。
-
SELECT *查视图：如果基表新增了敏感字段但视图定义没更新，该字段会原样透出，变成漏脱敏 - 跨库
JOIN：比如SELECT * FROM v_user_safe JOIN log_db.access_log ON ...，优化器可能下推条件或展开视图，导致脱敏字段参与计算 - 用户有其他高权限账号（如 DBA）：哪怕他从不登录，只要存在一个带基表权限的账号，就能间接导出明文
- 备份/导出脚本未过滤：
mysqldump --no-create-info db_name v_user_safe是安全的，但若脚本写成mysqldump db_name users，就全暴露了
真正难的从来不是写那几行 CONCAT(LEFT(...))，而是把权限、视图定义、字段类型、查询方式、运维流程全部拧成一股绳。少环一扣，脱敏就只是自我安慰。
