MySQL 8.0+ 和 PostgreSQL 视图中实现递归部门树查询需用 WITH RECURSIVE，Oracle 用 CONNECT BY；因视图不支持参数，须通过 current_setting('app.dept_id')::int（PG）或封装函数（MySQL）获取运行时部门ID，避免硬编码。
视图里怎么写递归部门树查询
MySQL 8.0+ 和 PostgreSQL 支持 WITH RECURSIVE，SQL Server 用 CTE，但 Oracle 需要 CONNECT BY。不能直接在视图定义里写参数化递归（比如传入 @dept_id），必须把“当前用户所属部门ID”作为运行时上下文来获取。
常见错误是硬编码部门ID或试图在视图里用变量——视图不接受参数，CURRENT_USER() 或 SESSION_CONTEXT('dept_id') 才是正解。
- PostgreSQL 示例：用
current_setting('app.dept_id')::int获取当前会话部门ID，再递归查子部门 - SQL Server 示例：需配合
CONTEXT_INFO或自定义函数（如fn_get_user_dept_tree()）返回表值，视图里JOIN该函数结果 - MySQL 8.0+ 示例：无法直接在视图中调用带参递归CTE，得先建一个函数封装递归逻辑，再在视图中调用该函数（如
get_sub_dept_ids(current_user_dept_id())）
视图定义中如何避免性能崩盘
视图本身不执行，但查询它时，数据库会把视图SQL和外层查询合并优化。如果视图里写了 WHERE UPPER(dept_name) = UPPER(?) 或 CASE WHEN dept_id IN (SELECT ...)，很可能导致索引失效、全表扫描。
- 确保用于过滤的字段（如
dept_id、dept_path）在基础表上有索引 - 别在视图定义里对过滤字段做函数处理；
dept_path LIKE 'D001/%'可走前缀索引，但SUBSTRING(dept_path, 1, 5) = 'D001/'就不行 - 递归查询结果集若过大（比如顶层部门有上千子部门），建议用物化视图（PostgreSQL）或定期刷新的中间表替代实时递归
- 避免在视图里
JOIN权限表并用EXISTS嵌套多层子查询——执行计划容易退化为 Nested Loop
为什么不能直接用 GRANT 控制层级行权限
GRANT 只能控制「能不能查这张表」或「能不能查某几列」，它没有行级语义。你给用户授了 SELECT ON employees，他就真能扫全表；哪怕你额外 GRANT SELECT (id,name) ON employees，也拦不住他用其他账号或绕过应用直连查敏感字段。
- 列授权不等于行过滤：即使只授了
name和dept_id，用户仍可通过WHERE dept_id IN (1,2,3...)扫描所有部门数据 - MySQL 5.7 及更早版本根本不支持列级
GRANT，执行会报ERROR 1064 (42000) - 真正起作用的是视图 + 权限分离：只给用户
SELECT ON employee_dept_vw，而该视图定义里已固化了部门树逻辑和WHERE dept_id IN (...)条件
视图 DEFINDER 权限怎么设才安全
MySQL 默认用 DEFINER = CURRENT_USER，这意味着视图执行时检查的是调用者权限——如果调用者没底层表权限，视图就查不了。但你要的是“调用者没权限也能查脱敏后数据”，就得显式设成高权限账号，比如 DEFINER = 'admin'@'localhost'。
- 设错 DEFINDER 是最隐蔽的坑：视图创建成功，但一查就报
ERROR 1449 (HY000): The user specified as a definer does not exist - PostgreSQL 没 DEFINDER 概念，靠
SECURITY DEFINER函数 + 视图组合实现类似效果 - SQL Server 视图无 DEFINDER，但要注意：若视图引用了用户无权访问的表，即使加了
WITH CHECK OPTION，查询仍会失败
ThreadLocal<Dept>，必须通过数据库驱动显式设置 session variable 或调用 SET app.dept_id = 123，否则所有用户看到的都是同一份“默认部门”数据。 
