MySQL中仅授予视图SELECT权限不够，还需确保SQL SECURITY类型匹配且定义者有效或调用者拥有底层表权限；SQL Server则只需视图级或架构级SELECT权限。
只执行 GRANT SELECT ON view_name TO 'user'@'host' 是不够的，多数情况下会报错 ERROR 1142 (42000): SELECT command denied to user —— 因为 MySQL 默认要求用户同时拥有视图和所有底层表的 SELECT 权限。
MySQL 中必须显式授予视图权限
视图在 MySQL 权限系统里是独立对象，哪怕和基表同名、同库，GRANT SELECT ON db.* 或 GRANT SELECT ON db.table 都不会自动覆盖视图。必须单独授权：
GRANT SELECT ON db.view_name TO 'user'@'host';- 执行后需
FLUSH PRIVILEGES;（仅当使用非mysql系统库方式修改权限表时才必需；常规GRANT语句已自动生效） - 验证：运行
SHOW GRANTS FOR 'user'@'host';，确认输出中包含该视图的SELECT行
为什么授了视图权限还是查不了？查 SQL SECURITY 类型
MySQL 执行视图查询时，会根据 SECURITY_TYPE 决定权限检查主体。默认是 DEFINER，但前提是定义者账号存在且仍有对应基表权限：
- 查当前视图的安全属性：
SELECT SECURITY_TYPE FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'view_name'; - 若返回
INVOKER，说明每次查询都校验调用者权限 → 用户必须同时有视图 + 所有基表的SELECT - 若返回
DEFINER，但定义者（如'root'@'localhost'）已被删或被收回基表权限，查询仍失败 - 修复方法：用
CREATE OR REPLACE SQL SECURITY DEFINER VIEW ...重建视图，确保定义者账号有效且权限完整
SQL Server 授予视图查询权限更直接
SQL Server 没有 MySQL 那套双层权限校验，只要用户有视图所在架构（如 dbo）的 SELECT 权限，或对视图本身显式授权即可：
- 按架构授：
GRANT SELECT ON SCHEMA :: dbo TO [username];（影响该架构下所有现有及未来视图/表） - 按对象授：
GRANT SELECT ON dbo.my_view TO [username]; - 注意：SQL Server 中视图不依赖基表权限，只要视图定义合法、用户有视图
SELECT权，就能查；但若视图引用了其他数据库对象且跨库，可能涉及跨数据库权限（需额外配置TRUSTWORTHY或证书签名）
WITH CHECK OPTION 不影响查询权限，但影响 DML
这个选项和“能否查”无关，但它决定用户能否通过视图做 INSERT/UPDATE 并绕过视图逻辑：
- 没加
WITH CHECK OPTION：用户可能INSERT INTO my_view VALUES (...)写入违反视图WHERE条件的数据（比如向只显示status='active'的视图插入status='deleted'） - 加了
WITH CHECK OPTION：DML 操作前会校验结果是否仍满足视图定义条件，不满足则拒绝 - 它对
SELECT完全无影响，也不改变权限模型
真正容易被忽略的是：MySQL 视图权限不是“开了就通”，而是取决于 SQL SECURITY 类型 + 定义者状态 + 基表权限三者共同作用；一个环节断掉，SELECT 就会静默失败。别只盯着 GRANT 语句本身，得进 INFORMATION_SCHEMA.VIEWS 看清楚实际生效的是谁的权限上下文。
