必须先收回基表select权限再单独授予视图权限，且视图须显式声明sql security definer、剔除敏感字段并脱敏处理，否则无法实现有效隔离。
必须先收回底层表的SELECT权限
只给视图授权却不撤掉基表权限，等于没设防。用户只要执行 SELECT * FROM users 就能绕过视图直接查原始数据。正确顺序是两步缺一不可：
-
REVOKE SELECT ON mydb.users FROM 'dev'@'%'—— 先清空对基表的访问权 -
GRANT SELECT ON mydb.v_user_safe TO 'dev'@'%'—— 再单独放行视图
漏掉第一步，SHOW GRANTS FOR 'dev'@'%' 里仍会看到基表权限，说明隔离失败。
创建视图时必须显式声明 SQL SECURITY DEFINER
MySQL 视图默认是 SQL SECURITY DEFINER，但某些 ORM、迁移工具或手动导出导入过程可能把它覆盖成 INVOKER。一旦变成 INVOKER，用户执行 SELECT 时就按自己的权限去查基表——而你刚 revoke 掉的权限又失效了。
安全写法是创建时明确指定：
CREATE VIEW mydb.v_user_safe AS SELECT id, name, SUBSTRING(phone, 1, 3) AS phone_masked FROM users WITH CASCADED CHECK OPTION SQL SECURITY DEFINER;
别依赖默认值，尤其在跨版本迁移或用脚本批量建视图时。
视图定义里不能暴露敏感字段或逻辑
视图本身不隐藏结构，SHOW CREATE VIEW v_user_safe 能直接看到它查了哪些表、用了哪些列、甚至函数调用。真正起作用的是字段裁剪和脱敏处理：
- 删掉
id_card、salary等原始列，不加就不暴露 - 手机号不能只写
phone，得加工成SUBSTRING(phone, 1, 3) AS phone_prefix - 避免在视图里用
ORDER BY或嵌套子查询，它们可能被逆向推断出业务规则
如果视图里还留着 WHERE status = 'active' 这种条件，用户虽看不到全量数据，但能猜出状态字段存在且有该取值。
验证时要用新连接，且查全限定名
权限变更后，旧连接会缓存旧权限上下文，导致测试结果失真：
- 执行完
GRANT和REVOKE后，务必断开重连，或新开终端执行mysql -u dev -p -h host - 测试时用
SELECT * FROM mydb.v_user_safe，而不是USE mydb; SELECT * FROM v_user_safe—— 后者可能因默认库影响解析路径 - 再试一次
SELECT * FROM mydb.users，应报错ERROR 1142 (42000): SELECT command denied
最容易被忽略的是：即使权限设置完全正确，如果用户账号是从角色（ROLE）继承权限的，你还得检查角色里有没有悄悄授了基表权限——SHOW GRANTS FOR 'dev'@'%' USING 'app_reader' 才能看到真实生效的权限链。
