sql触发器无法拦截select查询或防止截屏，因其仅响应dml/ddl事件；防导出应聚焦字段授权、数据库防火墙、审计日志及应用层水印等可控措施。
SQL触发器无法拦截 SELECT 查询，也不能防止截屏——这是根本性限制，不是配置问题。
为什么触发器对 SELECT 无能为力
MySQL、PostgreSQL、SQL Server 的标准触发器只响应 DML（INSERT、UPDATE、DELETE）和 DDL（CREATE、DROP）事件，SELECT 不在触发器支持范围内。试图用 AFTER SELECT 或类似语法会直接报错：ERROR 1064 (42000)。
常见误解是以为在视图或临时表上建触发器能捕获查询，但实际：视图上的触发器只对通过视图执行的 DML 生效；临时表不支持触发器；而普通表上的触发器对 SELECT 完全静默。
- MySQL 8.0+ 引入了
INFORMATION_SCHEMA.PROCESSLIST和 performance_schema 表，可轮询查活跃查询，但非实时、有延迟、且需高权限 - PostgreSQL 可用
pg_stat_activity配合pg_notify做轻量监听，仍属异步采样，无法阻断 - SQL Server 的
QUERY_NOTIFICATION或扩展事件（XEvent）能捕获查询，但同样不能在语句执行前拦截
真正能落地的“防导出”替代方案
把防护点从“查不到”转向“拿不走”，聚焦可控环节：
- 禁用客户端导出能力：在应用层或数据库代理（如 ProxySQL、MaxScale）拦截含
INTO OUTFILE、SELECT ... INTO DUMPFILE、bcp、pg_dump关键字的语句 - 限制字段级可见性：用
GRANT SELECT(col1, col2) ON table TO user明确授权，敏感列（如id_card、bank_no）不授，比任何触发器都可靠 - 启用数据库防火墙：如 MySQL Enterprise Firewall 设置
BLOCK规则匹配SELECT.*FROM users WHERE.*类通配模式，或用开源方案mysql-audit插件记录并告警 - 审计日志必须包含
USER()、HOST()、完整 SQL 文本、执行时间戳——这不是为了阻止，而是让导出行为可追溯、可追责
CURRENT_USER() 在审计中的真实作用与陷阱
它唯一可靠的作用是标识认证账号，但极易被绕过：
- 若应用使用统一连接池账号（如
app_rw@'10.%'），CURRENT_USER()对所有请求都返回相同值，失去区分意义 -
USER()返回client@host，可伪造（如通过代理或中间件修改连接字符串），绝不可用于权限判断 - 想关联真实操作人，必须由应用在每次查询中显式传入上下文，例如：写入
SET @app_user_id = 'u12345'，再在审计日志里读取@app_user_id - MySQL 中没有
SESSION_USER()函数，调用即报错：ERROR 1305 (42000): FUNCTION xxx.SESSION_USER does not exist
截屏完全不在数据库控制范围内
截图发生在客户端设备（浏览器、终端、远程桌面），数据库连屏幕内容都看不到。所有声称“用触发器防截屏”的方案，本质是混淆概念或营销话术。
可行的协同防护只有两层：前端水印（含用户 ID、时间戳的半透明浮层）、终端管控软件（如禁止剪贴板复制、禁用截图工具）。数据库最多配合提供动态水印参数（如通过 API 返回带签名的 user_id），但绝不参与图像渲染或设备控制。
真正容易被忽略的是：把“防导出”寄托在触发器上，会让人误判风险边界，反而放松对字段权限、网络隔离、审计告警这些确定有效的手段的投入。
