视图不能隐藏表结构，仅能限制访问入口并控制字段暴露范围；需配合权限隔离、手动脱敏、避免嵌套与ORDER BY、验证权限及字符集一致性。
视图能隐藏表结构吗？不能，但能控制暴露范围
视图本身不加密、不隐藏底层 CREATE TABLE 语句，DBA 或有 SHOW CREATE VIEW 权限的人仍可查到依赖关系。它的作用是「限制访问入口」：用户只能通过视图查数据，无法直接 SELECT * FROM users，也看不到真实字段名（比如把 id_card 改成 identity_masked）。
关键在权限隔离：REVOKE SELECT ON users FROM 'app_user'@'%'，再 GRANT SELECT ON v_users_safe TO 'app_user'@'%'。没这步，视图形同虚设。
脱敏字段必须在 SELECT 列表里显式处理
别指望视图自动“模糊化”。身份证、手机号、邮箱这类敏感字段，得手动用函数加工，否则原样透出。
-
SUBSTRING(id_card, 1, 6)+'****'+SUBSTRING(id_card, -4)（MySQL） -
REGEXP_REPLACE(phone, '^(\d{3})\d{4}(\d{4})$', '\1****\2')（PostgreSQL / MySQL 8.0+） - 避免用
CONCAT(LEFT(phone,3), '****', RIGHT(phone,4))—— 当字段为NULL时整个结果变NULL，建议加COALESCE
注意：不同数据库的字符串函数行为差异大，SUBSTR 在 Oracle 里从 1 开始，在 PostgreSQL 里支持负数偏移，MySQL 的 REPLACE 不支持正则，得换 REGEXP_REPLACE。
视图嵌套会放大性能风险
一个脱敏视图基于另一个聚合视图，再被 JOIN 到第三个视图——这种链式嵌套会让优化器失去索引下推能力，尤其当底层表有千万级数据时，EXPLAIN 可能显示全表扫描。
- 优先扁平化：把多层逻辑压进单个视图，减少中间结果集
- 避免在视图里写
ORDER BY（除非配合LIMIT），它会强制物化结果，无法被外层查询优化 - 如果底层表有
created_at索引，但视图里写了DATE(created_at)，索引就失效了
测试方法很简单：对视图执行 EXPLAIN SELECT * FROM v_user_summary WHERE status = 'active'，看 type 是不是 ref 或 range，而不是 ALL。
权限变更后务必验证视图是否仍可访问
常见翻车点：DBA 给新用户开权限时只授了视图，忘了授底层表的 SELECT 权限（MySQL 5.7 及以前要求；8.0+ 默认允许，但开了 sql_mode=STRICT_TRANS_TABLES 可能报错）。
- 错误信息典型是：
ERROR 1356 (HY000): View 'db.v_users_safe' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them - PostgreSQL 更严格：视图创建者默认以
SECURITY DEFINER运行，但若用SECURITY INVOKER，调用者必须有底层表权限 - 上线前用目标账号连库，执行
SELECT * FROM v_users_safe LIMIT 1，别只测 DDL
最易忽略的是字符集和排序规则不一致导致的隐式转换——比如底层表用 utf8mb4_0900_as_cs，视图里拼接字符串用了默认 collation，JOIN 时可能走不了索引，甚至查不出数据。
