MySQL触发器不能用于白名单式敏感字段读取控制，因其仅支持INSERT、UPDATE、DELETE三类DML操作，不支持SELECT拦截；真正可行方案是视图+账户权限隔离，即为不同角色创建限定字段的视图并严格授予权限。
MySQL 触发器无法在 SELECT 语句执行前拦截或重写查询，因此**不能用于实现白名单式的敏感字段读取控制**。这是根本限制，不是配置或语法问题。
为什么 BEFORE SELECT 触发器不存在？
MySQL 的触发器只支持 INSERT、UPDATE、DELETE 三类 DML 操作，且仅在数据变更时触发。SQL 标准和 MySQL 实现均未定义 SELECT 触发器 —— 这意味着你无法用触发器“拦住”一个 SELECT salary FROM users 查询并检查调用者是否在白名单中。
- 触发器本质是「数据变更钩子」，不是「查询拦截器」
-
INFORMATION_SCHEMA或performance_schema中也查不到当前 SQL 的原始字段列表，触发器内部无从得知用户想查什么字段 - 即使伪造逻辑（如在视图里加判断），也无法阻止用户直接绕过视图查基表
真正可行的替代方案：视图 + 账户权限隔离
白名单控制必须落在权限层，而非触发器层。核心思路是：为不同角色创建专用视图，并严格限制账户只能访问对应视图或列。
- 用
CREATE VIEW定义白名单字段集合，例如CREATE VIEW user_public AS SELECT id, name, email FROM users - 为敏感操作账号（如
'analyst'@'%'）只授予该视图的SELECT权限，不给基表权限：GRANT SELECT ON mydb.user_public TO 'analyst'@'%' - 撤销其对基表的任何权限：
REVOKE SELECT ON mydb.users FROM 'analyst'@'%' - 若需动态白名单（如按用户 ID 过滤行），可在视图中嵌入
WHERE created_by = USER()，但注意USER()返回的是连接凭据，不是应用层身份
如果坚持要在数据写入时做字段级校验，触发器能做什么？
触发器可用于写入侧的敏感字段保护，比如防止非法值写入、强制脱敏或记录修改痕迹，但这和「访问控制」无关。
-
BEFORE INSERT或BEFORE UPDATE中可检查NEW.salary是否为空或超出阈值，但不能检查谁在查它 - 可自动对
NEW.id_card调用SHA2()脱敏存储，但原始值仍存在于写入语句中，触发器无法加密传输中的查询 - 误用示例：试图在
BEFORE UPDATE里查information_schema.PROCESSLIST判断发起者 —— 该表不可被触发器访问，会报错ERROR 1356 (HY000)
白名单的本质是「谁可以查什么」，这必须由 MySQL 的权限系统（GRANT）、代理层（如 ProxySQL 做 SQL 解析过滤）或应用层（ORM 字段白名单配置）承担。触发器连查询的边都碰不到。
