<p>不能直接用SELECT * FROM audit_log做增量抽取，因为审计日志表缺乏单调递增且唯一的游标字段，存在乱序写入、批量补录以及时钟回拨等问题，易导致漏抽或重复；需通过视图封装ROW_NUMBER() OVER (ORDER BY created_at, log_id)生成稳定游标，并配合适当索引与下游游标式分页抽取机制。</p>
为什么不能直接用 SELECT * FROM audit_log 做增量抽取
因为审计日志表通常没有自增主键或可靠的时间戳字段，或者即使有 created_at，也可能存在乱序写入、批量补录、时钟回拨等情况。直接按时间范围查会漏数据或重复抽取。视图本身不存储数据，但可以封装逻辑——关键在于让视图暴露一个**单调递增且唯一可排序的游标字段**，供下游ETL识别“上次抽到哪”。
如何设计带增量游标的视图（含 ROW_NUMBER() + ORDER BY 稳定性控制）
必须确保 ROW_NUMBER() 的排序依据是确定性的。常见错误是只按 created_at 排序，但同一毫秒可能有多条记录。正确做法是叠加一个唯一字段（如 id 或 log_id）作为第二排序条件：
CREATE VIEW v_audit_log_incremental AS
SELECT
log_id,
user_id,
action,
created_at,
ROW_NUMBER() OVER (ORDER BY created_at, log_id) AS row_num
FROM audit_log
WHERE created_at >= '2020-01-01'; -- 防止历史脏数据干扰注意：ORDER BY 中的字段必须全部存在于 SELECT 列表里（SQL Server 要求），且所有字段都需有索引支撑，否则视图查询性能会断崖式下跌。
- 必须为
(created_at, log_id)建复合索引，否则ROW_NUMBER()会触发全表扫描 - 避免在视图里用
GETDATE()或SYSDATETIME()，会导致每次查询结果不可复现 - 不要用
NEWID()或随机值做排序依据——破坏单调性
下游怎么安全地分页抽取（用 row_num 替代 OFFSET/FETCH）
OFFSET/FETCH 在大数据量下性能差，且无法跳过已删除行导致错位。应改用游标式抽取：每次取 row_num > @last_row_num 的前 N 条，并记住新最大值。
DECLARE @last_row_num BIGINT = 1000;
SELECT TOP 10000
log_id, user_id, action, created_at
FROM v_audit_log_incremental
WHERE row_num > @last_row_num
ORDER BY row_num;执行后，取结果集中最大的 row_num 作为下一次的 @last_row_num。这个值必须由下游持久化保存（比如写进配置表或文件），不能依赖内存变量。
- 如果某次抽取失败，重试时仍从原
@last_row_num开始，不会丢数据 - 视图里的
WHERE created_at >= ...是兜底，防止因索引失效或数据异常导致row_num生成错乱 - SQL Server 2012+ 才支持
ROW_NUMBER()窗口函数；老版本得用临时表+标识列模拟
视图变更时最容易被忽略的三个风险点
视图只是查询封装，但下游 ETL 往往把它当“稳定接口”硬编码。一旦底层表结构或排序逻辑变，增量抽取就 silently 失效。
- 新增字段不影响
row_num生成，但若修改ORDER BY字段（比如把log_id换成user_id），原有row_num就完全不可比了 - 如果审计表开启了 CDC 或变更数据捕获，
audit_log可能被分区或归档，视图需同步加UNION ALL或动态 SQL，但ROW_NUMBER()跨分区必须保证全局有序 - DBA 清理历史数据时删了早于
WHERE created_at >= ...的行，会导致视图里row_num断层，下游以为“抽完了”，实际漏掉中间段
真正麻烦的不是写视图，而是让 row_num 这个虚拟游标，在表结构演进、数据生命周期管理、权限变更等现实约束下保持语义一致。它不像数据库序列号那样天然可靠，得靠人工盯住排序依据和索引状态。
