视图加where条件是行级过滤最常用方式，但需配合权限模型、命名规范、with check option及definer设置，否则易导致数据泄露或权限失效。
直接用视图加 WHERE 条件做行级过滤是最常用也最可控的方式，但必须配合权限模型和命名规范，否则上线即崩。
CREATE VIEW 时必须带明确的行过滤条件
视图本身不存数据，行级控制全靠定义里的 WHERE。漏写或写错条件，用户就能看到不该看的数据。
- 错误写法：
CREATE VIEW v_user_finance AS SELECT * FROM users—— 没过滤，等于裸表授权 - 正确写法：
CREATE VIEW v_user_finance AS SELECT id, name, dept FROM users WHERE dept = 'finance' - 如果要支持多部门动态过滤，不能用变量（如
WHERE dept = current_dept()），MySQL 不支持函数式谓词；PostgreSQL 可用current_setting('app.dept')，但需提前SET - MySQL 8.0+ 若启用
SQL_MODE=STRICT_TRANS_TABLES，INSERT INTO v_user_finance会因违反WHERE报错——这是好事，但得加WITH CHECK OPTION显式声明
GRANT SELECT ON view 不等于行级权限生效
视图只是“查询封装”，执行时仍走底层表权限校验。尤其在 PostgreSQL 和 SQL Server 中，默认按 DEFINER 身份检查权限，不是当前用户。
- 即使你
GRANT SELECT ON v_user_finance TO analyst，如果analyst对users表所在 schema 缺少USAGE权限，照样报错permission denied for schema public - PostgreSQL 中，若视图
DEFINER是admin，且admin有SELECT权限，则analyst能查视图，哪怕自己没底层权限——这是脱敏安全的基础，但也意味着DEFINER账号不能随便设 - MySQL 默认是
INVOKER，但生产环境强烈建议显式写成SQL SECURITY DEFINER统一行为：CREATE VIEW v_user_finance ... SQL SECURITY DEFINER
嵌套视图 + 角色继承才是可持续的行级分发模式
单个视图配单个角色很快失控。真实系统里，角色之间有继承关系，数据域有交叉，靠手工 GRANT 无法维护。
- 建一个基础角色
role_readonly，只授SELECT权限给所有v_*视图：GRANT SELECT ON ALL TABLES IN SCHEMA public TO role_readonly（PostgreSQL）或逐个GRANT SELECT ON v_* TO role_readonly（MySQL） - 让业务角色继承它：
GRANT role_readonly TO finance_analyst、GRANT role_readonly TO hr专员 - 视图命名带业务域前缀，比如
v_finance_users、v_hr_active_staff，后期审计或批量授权时可直接用正则匹配：SELECT table_name FROM information_schema.views WHERE table_name LIKE 'v_finance%' - 新增一个
v_finance_pnl_by_dept，只需确保它被role_readonly覆盖，所有下游角色自动获得访问权，不用改任何角色配置
WHERE 字段是否还能走索引？取决于你怎么写
视图里对过滤字段做任何加工，基本就废掉索引。别以为“写了 WHERE 就能走索引”。
- 安全写法：
WHERE dept_id = 101或WHERE dept_id IN (101, 102)—— 原始字段、等值或 in，能命中dept_id索引 - 危险写法：
WHERE SUBSTRING(dept_code, 1, 3) = 'FIN'、WHERE UPPER(dept_name) = 'FINANCE'、WHERE dept_id + 0 = 101—— 全表扫描，性能雪崩 - 如果必须用函数过滤，把计算逻辑放到外层查询，视图只做投影：
CREATE VIEW v_users_base AS SELECT id, name, dept_id, dept_name FROM users；然后应用层查SELECT * FROM v_users_base WHERE dept_name = 'Finance' - MySQL 中，
LIKE 'prefix%'可走索引；LIKE '%suffix'或LIKE '%mid%'不行——这点常被忽略
真正难的不是写那条 CREATE VIEW，而是确保 DEFINER 有效、schema USAGE 已授、WITH CHECK OPTION 加了、命名和角色体系能撑住未来三个月新增的五个业务线。漏掉任意一环，权限就形同虚设。
