MySQL视图不支持动态会话变量过滤，因变量未初始化、作用域错误或连接池残留导致查不到数据或跨租户泄露；推荐用MySQL 8.0.24+内联表值函数或租户库隔离方案。
MySQL 本身不支持在视图定义中动态读取会话变量（如 @current_tenant）并用于 WHERE 过滤，直接写 WHERE tenant_id = @current_tenant 的视图在多数场景下无法生效——因为变量未初始化、作用域不对，或查询优化器将其当作常量处理导致隔离失效。
MySQL 视图里写 @current_tenant 为什么经常查不到数据？
MySQL 视图是静态编译的，创建时不会“记住”变量值；运行时若未提前 SET @current_tenant = 't123'，该变量为 NULL，导致 WHERE tenant_id = NULL 永远不成立。更隐蔽的问题是：某些连接池（如 HikariCP 默认配置）会复用连接但不清除用户变量，上一个租户设的 @current_tenant 可能残留，造成跨租户数据泄露。
- 必须在每次查询前显式执行
SET @current_tenant = 'xxx'，不能依赖应用启动时一次设置 - ORM（如 MyBatis、JPA）通常不自动注入这类语句，需在拦截器或 DataSource 包装层统一处理
- MySQL 8.0+ 中
SET PERSIST或全局变量对单连接无效，仍得走会话级SET - 用
SELECT @@current_tenant测试变量是否存在，避免静默失败
替代方案：用 SQL SECURITY INVOKER + 显式传参视图（MySQL 8.0.24+）
MySQL 8.0.24 起支持带参数的内联表值函数（ITVF），虽不是视图，但可达到类似效果且更安全。你不能给视图加参数，但可以创建函数，让应用传入租户 ID：
CREATE FUNCTION tenant_orders(tenant_id CHAR(32)) RETURNS TABLE (id BIGINT, order_no VARCHAR(32), amount DECIMAL(10,2)) READS SQL DATA SQL SECURITY INVOKER AS $$ SELECT id, order_no, amount FROM orders WHERE orders.tenant_id = tenant_id $$;
- 调用时写
SELECT * FROM tenant_orders('t123');，参数由应用严格控制，无变量污染风险 -
SQL SECURITY INVOKER确保权限检查基于调用者，防止越权查基表 - 必须配合
GRANT SELECT ON orders给租户用户——否则函数执行会因权限不足失败 - 注意：此语法仅 MySQL 8.0.24+ 支持，5.7 和早期 8.0 版本不可用
最稳妥做法：放弃“动态视图”，改用应用层强制拼接 + 数据库账号隔离
真正生产可用的组合是：每个租户独立数据库 + 独立账号 + 应用层禁止裸表访问。视图在这里只做字段抽象，不做租户过滤：
- 建库
CREATE DATABASE tenant_abc;，建用户CREATE USER 'tenant_abc'@'10.20.30.%'; - 授权仅限本库：
GRANT SELECT, INSERT ON tenant_abc.* TO 'tenant_abc'@'10.20.30.%'; - 视图定义为
CREATE VIEW v_orders AS SELECT id, order_no FROM tenant_abc.orders;（不带WHERE） - 应用连接时固定指定
database=tenant_abc参数，ORM 配置spring.datasource.hikari.connection-init-sql=USE tenant_abc
这样既规避了视图动态过滤的所有坑，又利用 MySQL 原生权限机制实现强边界——哪怕 SQL 注入成功，攻击者也最多查到当前租户库里的数据，不可能跨库。
绕不开的细节：SHOW DATABASES 依然可见其他租户库名
这是 MySQL 权限模型固有行为，和视图无关。只要用户存在（哪怕只有 USAGE），SHOW DATABASES 就会列出所有库名。这不是漏洞，而是设计如此。如果你的应用 UI 或日志里意外暴露了这个列表，就得靠代理层（如 ProxySQL）过滤，或升级到 MySQL 8.0.12+ 并启用 information_schema_restricted=ON，再配合细粒度 GRANT SELECT ON information_schema.schemata 控制——但依然无法完全隐藏库名。
