触发器无法审计SELECT操作，因标准SQL不支持SELECT触发器；可行方案包括数据库原生审计（如MySQL audit_log、PostgreSQL pg_audit、SQL Server SERVER AUDIT）或应用层主动记录。
审计敏感数据访问不能只靠触发器
直接在 SELECT 操作上加触发器实现“访问审计”是行不通的——标准 SQL 触发器（MySQL/PostgreSQL/SQL Server）**不支持 SELECT 事件**。BEFORE/AFTER INSERT/UPDATE/DELETE 是 DML 触发器的合法时机，但 SELECT 属于查询操作，不在触发器覆盖范围内。
强行用触发器审计读取行为，常见错误是试图在视图上建 INSTEAD OF SELECT（仅 SQL Server 支持，且需配合视图+权限控制），或误以为 AFTER SELECT 存在。结果要么语法报错 ERROR 1064: You have an error in your SQL syntax，要么逻辑完全失效。
真正可行的替代方案有哪些
敏感数据访问审计必须依赖数据库原生审计能力或应用层协作，而非触发器：
-
MySQL：企业版自带
audit_log插件，开源版需用general_log+ 过滤（性能开销大），或借助PERFORMANCE_SCHEMA中的events_statements_history_long表（需开启并配置采样） -
PostgreSQL：启用
pg_audit扩展，或配置log_statement = 'all'+log_line_prefix记录用户、时间、SQL，再用日志分析工具提取SELECT敏感字段语句 -
SQL Server：使用
SERVER AUDIT+DATABASE AUDIT SPECIFICATION，可精确到SELECT ON schema::table BY user -
libSQL/SQLite：无内置审计机制，必须由应用层在执行
SELECT前主动写入审计表（例如调用INSERT INTO access_log），或改用 WAL hook + 自定义 VFS（极小众）
触发器能补位的有限场景
虽然不能捕获 SELECT，但触发器可在某些间接路径上增强审计闭环：
- 当敏感数据被
UPDATE或DELETE时，用AFTER UPDATE记录谁改了什么、改前值（OLD.*）、改后值（NEW.*），这对“篡改审计”有效 - 若敏感字段（如身份证号）被脱敏写入中间表，可用
BEFORE INSERT拦截并记录原始值来源（比如从哪个用户会话、哪条 SELECT 结果插入） - 配合应用层：应用在执行敏感
SELECT后，主动触发一个INSERT INTO audit_log（带user_id、query_hash、accessed_columns），此时可建触发器对audit_log表做校验（如检查user_id是否合法）
最容易被忽略的合规风险点
即使你用插件或扩展实现了 SELECT 审计，仍需注意：
- 日志本身也是敏感数据——
audit_log文件或pg_audit表若未设访问控制，可能成为新的泄露面 - 高频查询会迅速撑爆日志表，
audit_log默认不自动轮转，pg_audit需配log_rotation_age - 触发器里调用
CURRENT_USER()或SESSION_USER()只反映连接用户，若应用用固定账号池连接（如连接池），实际操作人无法还原
审计链要完整，光有“谁查了”不够，还得有“为什么查”“查完干了什么”，这部分只能靠应用日志与数据库日志关联分析，触发器插不上手。
