不能直接授SELECT权限，因为会暴露password_hash、ssn等敏感列；MySQL仅支持列级授予而非拒绝，须通过显式指定非敏感列的视图隔离，并禁用DEFINER越权风险，同时限制INFORMATION_SCHEMA访问以防结构探测。
创建审计用户时为什么不能直接授 SELECT 权限？
因为 GRANT SELECT ON table_name TO 'auditor'@'%' 会让审计员看到整张表，包括 password_hash、ssn、credit_card 这类敏感列。MySQL 原生不支持“列级拒绝”，只有“列级授予”——你得显式列出允许查的列，而不是排除敏感列。
用视图隔离敏感字段是最稳妥的做法
直接对原始表授权风险太高，而视图能固化非敏感列集合，且后续表结构变更不影响审计用户权限边界。操作要点：
- 先确认审计需要哪些字段，比如
user_id、username、last_login、status，但明确排除password_hash和email（如果邮箱也被视为敏感） - 创建视图时用具体列名，别写
SELECT *，否则加新列后可能意外暴露 - 视图定义里避免子查询或函数调用，否则可能影响性能或触发权限检查绕过
示例：
CREATE VIEW audit_user_view AS<br>SELECT user_id, username, last_login, status, created_at<br>FROM users<br>WHERE deleted_at IS NULL;然后只给这个视图的
SELECT 权限：GRANT SELECT ON your_db.audit_user_view TO 'auditor'@'%';
必须禁用 DEFINER 权限并设为 SQL SECURITY DEFINER
如果视图用了 DEFINER = 'root'@'%' 且没设 SQL SECURITY DEFINER，审计用户可能借视图执行越权操作（比如通过视图间接访问被屏蔽的列或触发器逻辑）。安全写法是：
CREATE ALGORITHM = MERGE<br>SQL SECURITY DEFINER<br>VIEW audit_user_view AS ...同时确保
definer 是一个最小权限账号（比如 'view_admin'@'localhost'），且该账号本身无敏感列访问权。
审计用户登录后仍可能通过 INFORMATION_SCHEMA 探测表结构
即使看不到敏感列数据，auditor 用户默认能查 INFORMATION_SCHEMA.COLUMNS，从而知道哪些列存在、类型是什么。若合规要求严格，需限制元数据访问：
- MySQL 8.0+ 可用
REVOKE SELECT ON INFORMATION_SCHEMA.* FROM 'auditor'@'%';（注意：这会阻止其查任何系统表，包括必要的PROCESSLIST监控，需权衡） - 更实用的做法是，在应用层或审计脚本中禁止拼接列名查询，靠流程约束而非纯技术封锁
- 定期检查
SHOW GRANTS FOR 'auditor'@'%';，确认没有意外获得SHOW VIEW或SELECT ANY TABLE这类高危权限
真正麻烦的是视图与主表之间的 JOIN 场景——比如审计视图关联了 orders 表，而 orders 里有 billing_address，这时得同步审查关联表的列暴露范围。漏掉一个 JOIN 就可能让整套隔离失效。
