SQL触发器无法在SELECT时触发，因主流数据库仅支持INSERT/UPDATE/DELETE三类DML操作；替代方案为启用原生审计功能或应用层埋点，而非实现真正的SELECT触发器。
SQL触发器无法在数据被读取（SELECT）时触发——这是绝大多数关系型数据库的硬性限制，TRIGGER 只支持 INSERT、UPDATE、DELETE 三类 DML 操作，不支持 SELECT。
为什么不能用 BEFORE/AFTER SELECT 触发器？
MySQL、PostgreSQL、SQL Server、Oracle 等主流数据库均未实现 SELECT 触发器。即使某些实验性扩展（如 PostgreSQL 的 pg_stat_statements 配合事件触发器）能间接捕获查询，也**不是真正意义上的“读取触发器”**，而是依赖日志或统计视图轮询，存在延迟、漏报和权限限制。
- MySQL 完全不支持
SELECT触发器，语法直接报错ERROR 1365 (HY000): Trigger's event is not supported - PostgreSQL 的
EVENT TRIGGER可监听sql_drop或table_rewrite，但无法监听普通SELECT - Oracle 的细粒度审计（FGA）虽可对
SELECT做响应，但它属于审计机制，不是触发器，也不能执行自定义逻辑（如写报警表、调用存储过程发消息）
替代方案：用数据库审计功能捕获敏感字段读取
真正可行的路径是绕过触发器，启用数据库原生审计能力，再通过外部程序解析日志或轮询审计表。关键在于区分“谁查了什么字段”，而非“如何在 SQL 层拦截 SELECT”。
- MySQL 8.0+：启用
audit_log插件，配置audit_log_include_tables和正则过滤SELECT.*ssn|phone|id_card类语句，日志输出到文件或 JSON 表 - PostgreSQL：开启
log_statement = 'all'+log_line_prefix记录用户/时间/SQL，再用pg_audit扩展精准匹配含敏感字段的SELECT（需建专用策略：CREATE AUDIT POLICY ... ON table_name BY user_name WHERE column_name IS NOT NULL） - SQL Server：使用
SQL Server Audit，创建AUDIT SPECIFICATION监控SELECTon specific columns，目标设为FILE或SECURITY_LOG，后续由 PowerShell 或 Logstash 提取含ssn、credit_card的事件
应用层埋点比数据库层更可控
如果业务系统结构清晰（如统一 ORM 或 API 网关），在代码中拦截读取请求，比依赖数据库审计更及时、更精确、更易扩展。
- Spring Boot + MyBatis：在
Interceptor中检查MappedStatement.getBoundSql().getSql()是否包含敏感字段名（如LIKE '%ssn%'），匹配后记录到alarm_log表并推送企业微信 - Node.js + pg：用
pg-monitor或封装client.query()，对text字段做正则检测（/SELECT.*\b(ssn|dob|address)\b/i），命中即写入audit_events表 - 注意：避免在高频查询路径中做复杂字符串匹配，建议预编译敏感字段白名单数组，用
some(field => sql.includes(field))快速判断
真正的难点不在“怎么写触发器”，而在于接受一个事实：数据库不让你在 SELECT 时执行任意逻辑。所有绕过这个限制的方案，要么依赖审计日志的异步分析，要么把控制权交还给应用——后者反而更稳定、更易测试、更少受数据库版本升级影响。
