视图必须显式列出字段，禁用SELECT *；脱敏需用确定性函数并包裹IFNULL；权限须分层回收，仅授视图SELECT权，禁用基表权限；视图无法解决动态角色、跨库JOIN等场景，应换行级安全策略等方案。
视图必须显式列出字段，不能用 SELECT *
用 SELECT * 创建视图看似省事，但基表一旦新增敏感字段（比如后期加了 password_hash 或 id_card），视图会自动包含它，而你可能根本没意识到权限已泄露。这等于把脱敏逻辑交给了运气。
显式写字段名才是白名单控制：只放行业务真正需要的列，其余一律过滤。例如 HR 查员工信息，只需 id、name、dept、join_date，其他字段不出现就是最硬的隔离。
- 字段顺序不重要，但别漏掉
WHERE中引用的字段（如带行级过滤时用了id = CURRENT_USER()，那id就必须在SELECT列表里） - 如果字段是数值型或日期型，但后续要脱敏（如金额转字符串掩码），需提前
CAST，避免查询时报Truncated incorrect DOUBLE value - 建表时对敏感字段加
CHECK约束（如CHECK (LENGTH(TRIM(phone)) = 11)），能减少视图中函数处理的边界异常
脱敏表达式必须确定性，禁用 CURRENT_USER() 做字段逻辑
CURRENT_USER() 是会话级非确定性函数，MySQL 视图定义中禁止使用——轻则创建失败报 ERROR 1351，重则让优化器拒绝缓存执行计划，每次查询都重解析，性能断崖下跌。
更危险的是权限越权：即使语法侥幸通过（比如嵌套在子查询里），视图默认以 DEFINER 身份执行，CURRENT_USER() 返回的是定义者（如 'root'@'%'），不是调用者。结果就是所有用户查到的都是未脱敏数据。
- 字段级脱敏只能用纯函数：如
CONCAT(LEFT(TRIM(phone), 3), '****', RIGHT(TRIM(phone), 4)) - 每个脱敏表达式必须包裹
IFNULL(..., '')，防止 NULL 导致整列为空，破坏下游业务校验 - 手机号、身份证号等要区分存储类型：BIGINT 存的手机号得先
CAST(phone AS CHAR)再切片，否则LEFT(phone, 3)会按数字截取，结果不可控
权限必须分层回收，只授视图 SELECT，禁用基表任何权限
视图本身不拦截访问，它只是个保存好的 SELECT 语句。只要用户有原表的 SELECT 权限，他就能绕过视图直接查明文——这是生产环境最常翻车的地方。
MySQL 权限是“白名单制”，但旧权限不会自动过期。常见错误是建了视图后只授视图权限，却忘了 REVOKE SELECT ON db_name.users FROM 'reporter'@'%'。
- 先查现状：
SHOW GRANTS FOR 'reporter'@'%'，确认没有SELECT ON db_name.*这类宽泛授权 - 显式回收基表权限：
REVOKE SELECT ON db_name.users FROM 'reporter'@'%'（注意不是REVOKE ALL，它不包含SHOW DATABASES） - 只授视图权限：
GRANT SELECT ON db_name.v_user_safe TO 'reporter'@'%'（库名、视图名都要用反引号，尤其含短横线时） -
FLUSH PRIVILEGES不需要执行——GRANT/REVOKE会自动刷新内存权限缓存
视图无法覆盖的场景，必须提前识别并换方案
视图是单表投影封装，它解决不了动态角色切换、跨库 JOIN、SELECT * 泄露、索引失效这些本质限制。很多问题不是“视图没写对”，而是“不该用视图”。
- 同一字段要按角色显示不同强度（如普通用户看
138****1234，管理员看完整号码）→ 必须上 MySQL 8.0.22+ 的行级安全策略（CREATE ROW POLICY）或代理层 - 视图被用于
JOIN场景（如SELECT * FROM v_user_safe JOIN log_table）→ 优化器可能下推谓词，绕过视图脱敏逻辑 - 应用代码里写了
SELECT * FROM users→ 即使用户没基表权限，这条 SQL 也会因视图不存在而报错，但错误信息可能暴露表结构 - 跨库关联（如
v_user_safe和log_db.access_log）→ 视图只封装单库单表逻辑，JOIN 后原始字段仍可暴露
最容易被忽略的是：视图定义里的字符串函数一旦出错（比如 RIGHT(NULL, 4) 返回 NULL），整个字段就变空，而业务系统可能依赖该字段非空做判断——所以每个脱敏表达式都得带 IFNULL 和 TRIM，不能图省事。
