数据仓库增量更新的核心任务是识别业务系统在两次抽取之间发生过变化的数据行。常见做法包括时间戳扫描、全表对比和变更数据捕获，其中SQL触发器属于主动捕获方式。它在源表执行INSERT、UPDATE、DELETE时同步把主键、操作类型、变更时间写入增量日志表，后续ETL只需要读取这张日志表即可定位变化数据。与全量抽取相比，触发器方案可以大幅降低IO和网络传输量，也避免了时间戳字段无法识别物理删除的问题。
一、SQL触发器捕获增量数据的基本原理
SQL触发器是绑定在表上的特殊存储过程，当目标表发生INSERT、UPDATE或DELETE时会自动执行。利用这种特性，可以在触发器中把变化行的关键信息写入另一张增量日志表。例如，在订单表上创建AFTER INSERT、AFTER UPDATE、AFTER DELETE触发器，每当订单新增、修改或删除，就向订单增量表写入一条记录，记录订单编号、操作类型、发生时间和必要的业务字段。
触发器捕获的最大优势是实时性和完整性。只要DML语句成功提交，触发器产生的日志也会在同一事务中提交，因此不会出现时间戳扫描中因为事务未提交而漏读或幻读的问题。对于DELETE操作，源表中已经不存在该行，时间戳方案往往无法捕获，而触发器可以从deleted虚拟表里拿到被删除行的主键，这是触发器方案特别适合数据仓库增量维护的原因之一。
但触发器并非没有代价。它会在源表写入路径上增加额外逻辑，如果触发器内部包含复杂计算或大表关联，会拖慢业务写入。因此触发器日志逻辑应保持简单，只做必要的字段复制和主键记录，避免在触发器里执行耗时查询。
二、设计增量日志表与触发器代码
增量日志表一般包含自增流水号、源表主键、操作类型、变更时间、变更前值和变更后值等字段。为了支持每日批量合并，日志表还需要一个处理状态字段，例如0表示未处理，1表示已合并。下面以订单表为例，先创建订单增量日志表：
CREATE TABLE dbo.OrderChangeLog
(
LogID BIGINT IDENTITY(1,1) PRIMARY KEY,
OrderID INT NOT NULL,
ActionType CHAR(1) NOT NULL, -- I=新增 U=修改 D=删除
ChangeTime DATETIME NOT NULL DEFAULT GETDATE(),
OldAmount DECIMAL(18,2) NULL,
NewAmount DECIMAL(18,2) NULL,
Processed BIT NOT NULL DEFAULT 0
);
在这个表结构中，ActionType使用单个字符表示操作类型，ChangeTime记录触发时间，OldAmount和NewAmount用于保存金额字段变更前后的值。如果源表字段较多，可以为需要参与增量计算的业务字段分别建旧值和新值列，也可以只记录主键，让ETL阶段再回源表取最新快照。但记录旧值对缓慢变化维和审计场景更有价值。
接下来为订单表创建三个DML触发器。SQL Server中可以在一个触发器里同时处理INSERT、UPDATE、DELETE，但为便于阅读，这里分开创建。INSERT触发器从inserted虚拟表读取新增行，写入I类型日志：
CREATE TRIGGER trg_Order_Insert
ON dbo.Orders
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
INSERT INTO dbo.OrderChangeLog(OrderID, ActionType, ChangeTime, NewAmount)
SELECT i.OrderID, 'I', GETDATE(), i.Amount
FROM inserted AS i;
END;
UPDATE触发器需要同时读取inserted和deleted两张虚拟表，inserted保存更新后的行，deleted保存更新前的行。写入U类型日志时，可以把旧值和新值都记录下来：
CREATE TRIGGER trg_Order_Update
ON dbo.Orders
AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON;
INSERT INTO dbo.OrderChangeLog(OrderID, ActionType, ChangeTime, OldAmount, NewAmount)
SELECT i.OrderID, 'U', GETDATE(), d.Amount, i.Amount
FROM inserted AS i
INNER JOIN deleted AS d ON i.OrderID = d.OrderID;
END;
DELETE触发器只需要从deleted虚拟表读取被删除的主键和旧值，写入D类型日志：
CREATE TRIGGER trg_Order_Delete
ON dbo.Orders
AFTER DELETE
AS
BEGIN
SET NOCOUNT ON;
INSERT INTO dbo.OrderChangeLog(OrderID, ActionType, ChangeTime, OldAmount)
SELECT d.OrderID, 'D', GETDATE(), d.Amount
FROM deleted AS d;
END;
上述三个触发器保持逻辑简单，只做插入日志操作。需要注意，如果业务系统会在同一事务中多次修改同一行，每次修改都会产生一条日志，这是符合变更捕获需求的。但也要意识到日志表会快速增长，必须建立合适的索引和归档策略，否则日志表本身可能成为新的性能瓶颈。
三、每日增量合并到数据仓库的流程
有了增量日志表后，数据仓库的每日ETL任务可以按以下步骤执行：先读取所有未处理日志，按主键和操作类型生成针对维度表或事实表的合并语句，然后标记日志为已处理，最后做数据质量校验。以订单事实表为例，I类型日志对应INSERT，U类型对应UPDATE，D类型对应DELETE或标记删除。
一个常见的合并策略是使用MERGE语句。ETL过程先把未处理日志加载到数据仓库的临时表，然后用MERGE匹配目标事实表主键。对于I类型且目标表不存在该主键时执行插入；对于U类型执行更新；对于D类型执行删除或逻辑删除。示例代码如下：
MERGE INTO dwh.FactOrders AS t
USING (
SELECT l.OrderID, l.ActionType, l.NewAmount
FROM stage.OrderChangeLog AS l
WHERE l.Processed = 0
) AS s
ON t.OrderID = s.OrderID
WHEN MATCHED AND s.ActionType = 'U' THEN
UPDATE SET t.Amount = s.NewAmount, t.UpdatedTime = GETDATE()
WHEN MATCHED AND s.ActionType = 'D' THEN
DELETE
WHEN NOT MATCHED AND s.ActionType = 'I' THEN
INSERT(OrderID, Amount, InsertedTime)
VALUES(s.OrderID, s.NewAmount, GETDATE());
合并完成后，需要把已处理的日志标记为1。为了避免在标记过程中出现新的日志被误标，通常会记录当前批次的最大LogID，只更新小于等于该LogID且Processed为0的记录。这样即使有新的日志持续写入，也不会影响本批次的一致性。
在实际调度中，每日任务可以先用一个事务读取一批未处理日志到临时表，接着执行MERGE，最后更新日志状态并提交。如果MERGE失败，整个事务回滚，日志仍然保持未处理状态，第二天可以重新处理。需要注意的是，如果数据仓库要求保留历史变化而不是直接覆盖，可以把日志表作为事实表的附加变更流，再通过拉链表或快照表来还原历史。
四、触发器方案与CDC机制的对比及注意事项
SQL Server自带的变更数据捕获（CDC）和更改跟踪（Change Tracking）也能实现类似目标。CDC通过读取事务日志来捕获变更，不需要修改源表结构，也不会在DML路径上增加触发器代码，对业务写入的影响较小。但CDC需要开启数据库或表级配置，日志读取代理需要持续运行，并且对事务日志的保留时间有要求。触发器方案则更直观，开发人员可以完全掌控日志表结构和捕获逻辑，部署门槛低。
不过触发器方案最大的隐患是维护成本。如果源表结构发生变更，例如增加字段、修改字段类型，对应的触发器和日志表也需要同步调整。大量表的触发器会让数据库对象数量迅速膨胀，版本管理和发布流程需要跟上。另一个问题是性能：所有写入操作都要额外插入日志，对高频交易表可能造成明显的写入延迟。因此触发器方案适合每日变更量在几十万到几百万行、写入频率中等、且开发团队对触发器管理有经验的场景。
无论选择触发器还是CDC，都需要关注增量日志的完整性。建议在源表增加最后修改时间戳作为辅助校验手段，定期对比时间戳扫描结果和触发器日志数量，发现漏数时及时补抽。同时，对于UPDATE操作，如果业务只关心最终状态，可以在每日合并时对同一主键的多条日志做压缩，只保留最后一条，以减少数据仓库端的处理量。
综合来看，SQL触发器维护数据仓库每日增量更新是一种轻量、直接、可控的变更数据捕获方案。它的核心在于设计合理的增量日志表、保持触发器逻辑简单、并在ETL阶段做好幂等合并和状态管理。只要对日志增长和源库性能有充分评估，这一方案能够在中小规模数据仓库中稳定运行，并显著降低每日抽取成本。