视图本身不能实现审计回溯，因其仅封装查询、不存储历史数据且不捕获变更事件；真正回溯依赖带created_at、updated_at、deleted_at等可信审计字段的基表，配合合理设计的视图暴露逻辑。
视图本身不能实现审计回溯——它只是查询的封装，不存储历史数据，也不捕获变更事件。真正能回溯用户变更的，是底层带审计字段的基表 + 合理设计的视图暴露逻辑。
为什么不能靠视图“生成”审计时间
常见错误是试图在视图里写 NOW()、CURRENT_TIMESTAMP 或 COALESCE(updated_at, created_at) 来“模拟”变更时间。结果每次查视图，viewed_at 都是当前时刻；而 COALESCE 会把 updated_at IS NULL 的脏数据也当成“已更新”，掩盖真实状态。视图不参与写入，它只读；时间戳必须由 INSERT/UPDATE 时写入基表才可信。
必须存在的基表审计字段
回溯的前提是基表已有可信赖的审计列。缺一不可：
-
created_at：类型为DATETIME(6)或TIMESTAMP(6)，带DEFAULT CURRENT_TIMESTAMP约束 -
updated_at：同上，且需确保每次 UPDATE 都刷新（MySQL 8.0+ 支持ON UPDATE CURRENT_TIMESTAMP；PostgreSQL 需触发器或gen_random_uuid()配合表达式索引） -
deleted_at（软删场景）：非 NULL 时代表逻辑删除，视图中用WHERE deleted_at IS NULL过滤
若旧表缺失这些字段，不要在视图里“补”——得用触发器兜底写入，或迁移数据补全。
视图该怎么写才支持有效回溯
视图的作用是安全、统一、无歧义地暴露审计字段，不是加工时间。典型写法：
CREATE VIEW user_history_vw AS
SELECT
id,
name,
email,
created_at,
updated_at,
CASE
WHEN updated_at > created_at THEN 'UPDATED'
ELSE 'CREATED'
END AS change_type
FROM users
WHERE deleted_at IS NULL;
关键点：
- 不重命名
created_at/updated_at，避免下游误解语义 - 不加
ORDER BY或LIMIT——视图不该约束结果集大小 - 软删字段必须显式过滤，否则
deleted_at为非 NULL 的行仍会出现在视图里 - 如需按“最后修改时间倒序查最新10条用户”，应在查询视图时加
ORDER BY updated_at DESC LIMIT 10，而非写死在视图定义中
想查某用户全部变更快照？视图做不到，得靠审计表
如果需求是“看到张三邮箱从 a@1.com → b@2.com → c@3.com 的完整过程”，单靠 users 表的 updated_at 不行——它只存最新值。此时必须另建审计表（如 user_audit_log），用触发器或应用层写入每次变更的 old_values 和 new_values（JSON 格式）。视图可以包装这个审计表：
CREATE VIEW user_change_timeline_vw AS SELECT record_id AS user_id, operation, JSON_UNQUOTE(JSON_EXTRACT(old_values, '$.email')) AS old_email, JSON_UNQUOTE(JSON_EXTRACT(new_values, '$.email')) AS new_email, changed_at FROM audit_log WHERE table_name = 'users' AND (old_values->>'$.email' != new_values->>'$.email');
注意：JSON_EXTRACT 返回带引号字符串，JSON_UNQUOTE 才得干净值；WHERE 条件必须显式比对字段，否则会拉出所有无关变更。
最易被忽略的一点：时钟同步。如果应用服务器、数据库服务器、审计服务部署在不同机器，changed_at 时间可能错位，导致“先删后改”的时序误判。上线前务必校准 NTP。
