不能仅用revoke select(phone)限制敏感列访问，因mysql列权限是叠加型而非屏蔽型，用户有整表select权限即可绕过；必须撤基表权限、建脱敏视图、只授视图权限三步收口。
直接限制开发人员查不到敏感列，靠 REVOKE SELECT (column_name) 不可靠——MySQL 的列权限只在显式指定字段时生效，一旦用户有整表 SELECT 权限，就能绕过列级限制直查所有字段。
为什么不能只用 REVOKE SELECT (phone) ON table
MySQL 的列权限（Column Privileges）是“叠加型”而非“屏蔽型”：它只控制你能否在 SELECT 语句里明确写出该列，但不阻止你写 SELECT * 或 SELECT id, name 后再通过应用层读取未声明字段。更关键的是，只要用户有整表 SELECT 权限，REVOKE SELECT (phone) 就完全失效。
- 执行
REVOKE SELECT (phone) ON mydb.users FROM 'dev'@'%'后，用户仍可执行SELECT * FROM users并拿到phone值 -
SHOW COLUMNS FROM users和SELECT phone FROM users都会成功，除非同时撤掉整表权限 - 列权限无法防止 mysqldump、客户端自动补全、IDE 表结构探测等间接暴露
真正有效的三步收口法
必须切断“原始数据可触达”的所有路径，仅保留脱敏后视图这一出口：
- 先撤基表权限：
REVOKE SELECT ON mydb.users FROM 'dev'@'%'（不是REVOKE SELECT (phone)） - 建安全视图：
CREATE SQL SECURITY DEFINER VIEW v_users_safe AS SELECT id, username, email, CONCAT(LEFT(TRIM(phone), 3), '****', RIGHT(TRIM(phone), 4)) AS phone FROM users，注意加TRIM()防空格干扰 - 只授视图权限：
GRANT SELECT ON mydb.v_users_safe TO 'dev'@'%'，并确认SHOW GRANTS FOR 'dev'@'%'输出中不含任何mydb.users
容易被忽略的两个致命细节
很多团队卡在这两步上，导致视图形同虚设：
-
CURRENT_USER()不能出现在视图定义里——MySQL 会报ERROR 1351，且即使语法侥幸通过，也会让执行计划无法缓存，性能骤降；脱敏逻辑必须是确定性表达式，如CONCAT()、LEFT()、RIGHT() - 视图必须显式声明
SQL SECURITY DEFINER，否则默认INVOKER可能因调用者权限不足而查不出数据，或因权限过高导致越权；DEFINER账号需有底层表权限，但该账号本身绝不能开放给开发人员使用
最常翻车的点是：以为建了视图就万事大吉，却忘了检查旧权限是否还挂着——开发人员昨天被授过 SELECT ON mydb.*，今天只加了视图权限，那他照样能 SELECT * FROM users 看到原始手机号。
