视图本身不提供权限隔离，必须回收基表SELECT权限、显式声明SQL SECURITY DEFINER、仅授权指定视图，并严格限定字段列表以防敏感信息泄露。
视图本身不能自动隔离权限，必须配合显式授权 + 安全定义模式（DEFINER） + 基表权限回收才能生效。只建视图不收基表权限，低权限用户照样能绕过去查原始表；只设权限不控制视图定义方式，高权限账号一换，所有视图就失效。
视图权限和基表权限是两套独立系统
MySQL 8.0+ 默认用 SQL SECURITY INVOKER，即执行视图时检查调用者对基表的权限。这意味着：如果你给 dev_user 授了 SELECT ON v_orders_safe，但没收回它对 orders 表的权限，它仍可直接 SELECT * FROM orders 看到 cost 字段。
- 生产环境必须执行
REVOKE SELECT ON orders FROM dev_user，再单独授视图权限 - PostgreSQL 和 SQL Server 默认走
DEFINER模式，但 MySQL 需显式声明：CREATE VIEW v_orders_safe AS ... WITH CASCADED CHECK OPTION SQL SECURITY DEFINER -
DEFINER账号（如view_admin@localhost）必须长期有效，且不能被删或改密，否则所有依赖它的视图会报ERROR: permission denied for table orders
避免 SELECT * 和字段漂移风险
用 SELECT * 创建视图等于埋雷。一旦基表加了新列（比如 discount_rate），v_orders_safe 就会意外暴露该字段，而你根本没审核过它是否该开放。
- 始终显式列出字段：
SELECT id, order_no, customer_id, amount, status, created_at - 敏感字段如
cost、owner_id、internal_note必须从SELECT列表中剔除，而不是靠WHERE 1=0或注释掉 - 命名带角色前缀，例如
v_sales_orders、v_finance_summary，方便审计和批量授权
行级过滤必须由应用层显式传参，不能依赖会话变量
别写 CREATE VIEW v_my_orders AS SELECT * FROM orders WHERE owner_id = @current_user_id。连接池复用后，@current_user_id 极可能残留上一个用户的值，导致数据越界。
- MySQL 8.0.24+ 支持函数参数，但需应用层调用
tenant_orders('u789')，且该函数内部必须用SECURITY DEFINER才能安全访问基表 - 更稳妥的做法是：所有查询都由应用拼接
WHERE owner_id = ?，视图只负责字段裁剪，不承担行过滤 - 如果真要用会话变量，必须在每次获取连接后立即执行
SET @current_user_id = 123，并确保连接池支持初始化语句（如 HikariCP 的connection-init-sql）
最常被忽略的一点：视图加了 WITH CHECK OPTION 只防 INSERT/UPDATE，不防 SELECT。它解决的是“用户能否通过视图改非本人订单”，不是“能不能看到别人订单”。行级隔离的兜底动作永远在应用层——数据库只管字段和表级边界，别让它扛动态条件。
