视图不支持触发器，只能在基表创建触发器并通过会话变量或注释标记识别视图来源；不可更新视图无法触发任何DML操作，故日志为空；物化视图是替代方案但非实时且数据库支持有限。
视图本身不支持触发器，直接在 CREATE VIEW 上加 BEFORE INSERT 会报错
SQL 标准里，视图是只读的查询封装，不是物理表，所以数据库（MySQL、PostgreSQL、SQL Server）都不允许对视图直接定义 INSERT/UPDATE/DELETE 触发器。你执行类似 CREATE TRIGGER log_view_insert ON my_view BEFORE INSERT ...，一定会遇到错误，比如 PostgreSQL 报 ERROR: "my_view" is not a table，MySQL 则提示 Trigger can't be defined on a view。
真正能加触发器的，只有基表（base table），也就是视图背后 SELECT 所依赖的真实表。
- 视图只是语法糖，不存数据，也不参与 DML 生命周期
- 所谓“通过视图写入”，本质是数据库把语句重写后落到基表上（需满足可更新视图条件）
- 想记录日志，必须把触发器建在基表上，并在触发器逻辑里识别出这次修改是否来自视图路径
如何区分“谁改了基表”——用 current_setting() 或应用层标记（PostgreSQL）
数据库原生不记录“哪条 SQL 来自哪个视图”，但你可以人为注入上下文。PostgreSQL 支持会话级配置，适合做轻量标记；MySQL 没有等价机制，得靠应用层传参或命名约定。
- 在应用执行
INSERT INTO my_view (...) VALUES (...)前，先执行SET LOCAL app.view_context = 'my_view'; - 在基表的
BEFORE INSERT触发器里，用current_setting('app.view_context', true)读取该值 - 如果返回非空，就往日志表插入一行，带上
view_name、operation、row_id等字段 - 注意：MySQL 不支持这种会话变量透传，只能靠在 SQL 中显式带注释（如
/* view:my_view */ INSERT ...），再用触发器解析QUERY（不推荐，不可靠且性能差）
可更新视图的限制直接影响日志捕获完整性
不是所有视图都能被 INSERT/UPDATE。一旦视图含 DISTINCT、聚合函数、GROUP BY、多表 JOIN（无主键映射）等，数据库就会拒绝写入——这时候你根本走不到触发器，自然也记不了日志。
- PostgreSQL 要求可更新视图必须满足“每个输出列唯一对应一个基表列”，且不能有
WITH CHECK OPTION冲突 - MySQL 更严格：只允许单表视图，且不能含子查询、计算列、
UNION - 如果你的视图不可更新，用户执行
INSERT INTO view会直接报错，压根不会触发任何基表操作，日志也就完全空白 - 建议用
SELECT table_name, is_updatable FROM information_schema.views查看视图实际可写性
替代方案：用物化视图 + 定时任务补日志（仅限 PostgreSQL / Oracle）
如果真需要“视图维度”的操作审计，又不想改应用代码，可以绕开触发器，改用物化视图（MATERIALIZED VIEW）配合定时扫描。但这不是实时日志，而是准实时补采。
- 物化视图是物理表，可以建触发器，但它只在
REFRESH时更新，不是自动同步 - 你可以写个脚本每分钟跑一次
REFRESH MATERIALIZED VIEW CONCURRENTLY my_mv;，再查增量（比如比对last_updated字段） - 代价高：频繁刷新影响性能，且无法捕获中间状态；只适合低频、审计类场景
- SQLite、MySQL 不支持物化视图，这条路直接堵死
复杂点在于：日志不是“视图行为”的镜像，而是基表变更的副产品；你得自己维护视图与基表的映射关系，还要处理并发写入时上下文覆盖、事务中断导致标记丢失等问题。这些细节不显眼，但一出问题就难排查。
