SELECT不触发任何DML触发器，因其为只读操作，不修改数据、不激活伪表；所有主流数据库均不支持AFTER SELECT语法，报错属规范限制；替代方案包括启用查询日志、应用层埋点或代理层拦截。
SELECT 不触发任何 DML 触发器
SQL 触发器根本不会响应 SELECT 语句，因为标准触发器（BEFORE INSERT、AFTER UPDATE 等）只监听对永久表的写操作（DML），而 SELECT 是只读操作，不修改数据、不产生事务日志记录、不激活任何伪表（如 inserted 或 deleted），因此从数据库引擎层面就跳过触发器匹配流程。
试图用 AFTER SELECT 触发器会报语法错误
所有主流 SQL 数据库（MySQL、PostgreSQL、SQL Server）都不支持为 SELECT 定义触发器。你写 CREATE TRIGGER tr ON t AFTER SELECT ... 会被直接拒绝：
- MySQL 报错：
ERROR 1064 (42000): You have an error in your SQL syntax - SQL Server 报错：
Incorrect syntax near the keyword 'SELECT' - PostgreSQL 报错：
ERROR: syntax error at or near "SELECT"
这不是版本差异或配置问题，是语法规范本身就不允许。
替代方案：审计日志或应用层埋点
想监控谁查了哪张表、什么条件、执行多久，得绕开触发器走其他路径：
- 启用数据库级查询日志：
general_log = ON（MySQL）、log_statement = 'all'（PostgreSQL）、SQL Server Audit（SQL Server），再过滤含SELECT的行 - 在应用代码中统一封装查询入口，加
try/finally记录上下文（用户、SQL 模板、参数、耗时） - 用代理层（如 ProxySQL、pgBouncer）拦截并记录流量，不侵入业务逻辑
- 某些场景可用
INFORMATION_SCHEMA或性能视图（如sys.dm_exec_query_stats）做事后分析，但无法实时捕获单条SELECT的完整语句和参数
临时表或视图里的 SELECT 也完全不可见
哪怕你在存储过程中执行 SELECT * FROM #temp 或 SELECT * FROM v_user_summary，只要目标不是永久表，就不会被任何触发器机制感知——临时表不注册元数据，视图只是查询重写规则，二者都不构成触发事件源。误以为“触发了”，往往是因为后续对永久表的写操作（比如把查询结果 INSERT INTO log_table）才真正触发了触发器。
