必须用视图封装脱敏逻辑、撤销基表权限、设置SQL SECURITY DEFINER三者结合；视图需显式写脱敏表达式（如CONCAT+TRIM），身份证末位X需适配，权限须精确授予视图并撤回基表权限，DEFINER确保执行上下文安全，INVISIBLE COLUMN不具安全性，脱敏字段无法索引。
直接结论：用视图封装脱敏逻辑 + 撤销基表权限 + 设置 SQL SECURITY DEFINER，三者缺一不可。只建视图不撤权限，等于没锁门。
CREATE VIEW 时必须显式写脱敏表达式，不能依赖应用层拼接
视图是静态查询定义，一旦创建就固化逻辑。比如手机号脱敏，得在 CREATE VIEW 里写死 CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))，而不是留个裸字段让下游自己处理。
- 错误示范：
SELECT id, name, phone FROM users→ 后续靠 Java 代码再截取，这等于把脱敏策略散落在各处，改格式就得全量修代码 - 安全写法：视图里直接返回脱敏后字段，如
CONCAT(LEFT(TRIM(phone), 3), '****', RIGHT(TRIM(phone), 4))，加TRIM()防空格干扰，避免RIGHT(phone, 4)返回空字符串 - 身份证号注意末位
X：用RIGHT(id_card, 4)可能拿不到真实末4位，应改用RIGHT(TRIM(id_card), 4)并配合建表时的CHECK(LENGTH(TRIM(id_card)) IN (15, 18))
GRANT 权限必须精确到视图，且 REVOKE 基表 SELECT
MySQL 的权限检查是“白名单制”：没给就不让查。只给视图权限但忘了撤基表权限，用户仍可绕过视图直查原表。
- 先执行：
REVOKE SELECT ON mydb.employees FROM 'app_user'@'%' - 再执行：
GRANT SELECT ON mydb.emp_public_view TO 'app_user'@'%' - 验证是否生效：
SHOW GRANTS FOR 'app_user'@'%'，确认输出里没有ON mydb.employees这一行 - 别漏掉
FLUSH PRIVILEGES（仅在手动修改 mysql.user 表后需要，GRANT/REVOKE 自动刷新）
SQL SECURITY DEFINER 是防止权限绕过的硬性要求
默认 SQL SECURITY INVOKER 会以调用者身份执行视图，如果用户有其他高权限表的访问权，可能通过子查询或 JOIN 窃取数据。设为 DEFINER 才能锁定执行上下文。
- 创建时必须声明：
CREATE SQL SECURITY DEFINER VIEW emp_public_view AS SELECT ... - DEFINER 用户需具备基表的 SELECT 权限（通常是 DBA 或专用账号），但该账号本身不应开放给应用使用
- 切勿在视图中使用
CURRENT_USER()、NOW()等非确定性函数，MySQL 会直接报错ERROR 1351 (HY000): View's SELECT contains a subquery in the FROM clause类似提示
别碰 MySQL 8.0 的 INVISIBLE COLUMN 当作脱敏手段
隐藏字段（INVISIBLE COLUMN）不是安全机制，只是语法糖。它对 SELECT * 不可见，但任何明确写出字段名的查询都能读到，且权限系统完全不感知它的存在。
-
ALTER TABLE users MODIFY phone VARCHAR(11) INVISIBLE后，SELECT phone FROM users依然能查出原始号码 - 它解决的是兼容性问题（如新增字段不影响老应用的
SELECT *），不是数据安全问题 - 真要防敏感字段暴露，必须走视图+权限组合，而不是寄希望于“别人不写字段名”
最容易被忽略的一点：视图里的脱敏字段无法建立索引，WHERE 条件里对 CONCAT() 结果做筛选会强制全表扫描。高频检索需求（如按脱敏手机号搜索）必须保留原始字段，并通过行级权限或应用层过滤来控制可见性——数据库视图只负责“展示态”脱敏，不负责“查询态”加速。
