REVOKE撤销视图权限必须精确指定带库名和反引号的视图名，如REVOKE SELECT ON db_name.salary_view FROM 'analyst'@'%';漏写库名或反引号将导致错误或误操作；撤销后旧连接仍可查询，需重连才生效；不可用DENY替代REVOKE，批量撤销前须验证视图有效性。
REVOKE对视图的权限要精确到对象名
直接写 REVOKE SELECT ON *.* FROM 'user'@'host' 会撤掉所有表和视图的查询权，这不是“只动视图”的做法。必须显式指定视图名，且带上数据库名前缀，否则 MySQL 可能报错或误操作。
-
REVOKE SELECT ON `db_name`.`salary_view` FROM 'analyst'@'%';—— 正确：只影响该视图 - 漏掉反引号或库名（如写成
REVOKE SELECT ON salary_view）会导致语法错误或权限被撤到默认库，尤其当用户有多个库访问权时极易出错 - 视图名区分大小写（取决于系统变量
lower_case_table_names），建议始终按实际元数据中的大小写书写
撤销后旧连接仍能查视图，这是正常行为
权限变更不触发已建立连接的实时校验。用户只要没断开连接，SELECT * FROM finance.salary_view 依然能执行成功，哪怕你刚跑完 REVOKE。
- 真正生效需等连接重连（比如应用重启、客户端断线重连、或手动执行
KILL CONNECTION） - 无法通过 SQL 主动“踢掉”当前会话的权限，MySQL 没有类似
FLUSH PRIVILEGES FOR CONNECTION的机制 - 生产环境若需立即阻断，得配合连接管理（如 ProxySQL 限流、应用层熔断）或临时
DROP VIEW（仅限确认无依赖场景）
别用 DENY 替代 REVOKE，除非真要覆盖所有授权路径
DENY 和 REVOKE 行为完全不同：REVOKE 是“收回之前给的”，而 DENY 是“明确禁止”，且优先级最高——哪怕用户从角色继承了 SELECT 权限，DENY 也会把它压住。
- 想干净移除某用户对某视图的访问？用
REVOKE SELECT ON `db`.`v` FROM 'u'@'h'; - 用
DENY SELECT ON `db`.`v` TO 'u'@'h';后，即使后续给该用户所属角色授了SELECT，他也查不了这个视图 - 撤销
DENY必须用REVOKE（不是UNDO DENY），且语法一样：REVOKE SELECT ON `db`.`v` FROM 'u'@'h';
批量撤销视图权限前，先确认视图是否还“活着”
如果视图定义已腐烂（比如基表被删），REVOKE 虽然能执行成功，但后续有人尝试查这个视图时会直接报 ERROR 1356。这时你撤的不是“权限”，而是个失效对象的壳。
- 先验证：运行
SELECT * FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'v_name'; - 再检查依赖：查
INFORMATION_SCHEMA.VIEW_COLUMN_USAGE，看返回结果是否为空或报错 - 若发现腐烂，别急着
REVOKE，先用CREATE OR REPLACE VIEW修复定义，或直接DROP VIEW（前提是确认无下游引用）
权限撤销本身不难，难的是判断“这个视图现在到底还能不能用”以及“撤完之后谁会突然连不上”。真实环境里，REVOKE 前那条 SELECT * FROM v_name LIMIT 1，比任何语法检查都管用。
