触发器里不能直接调用缓存写入逻辑，因其运行在数据库事务上下文中，所有操作必须是T-SQL原生支持的；无法安全执行Redis SET、Kafka生产者API或xp_cmdshell等外部调用，否则会破坏事务一致性并引发阻塞、超时、连接池耗尽等问题。
触发器里不能直接调用缓存写入逻辑
SQL Server 触发器运行在数据库事务上下文中，所有操作必须是 T-SQL 原生支持的；你无法在 INSERT 或 UPDATE 触发器里直接调用 Redis 的 SET、Kafka 的生产者 API，甚至无法安全执行 xp_cmdshell 调用外部程序——这既违反事务一致性，又极易引发阻塞或超时。
常见错误现象包括：触发器长时间挂起、连接池耗尽、主表 UPDATE 被阻塞数秒以上、事务日志暴涨。
- 触发器中尝试用
sp_OACreate调用 HTTP 客户端 → SQL Server 报错Msg 15281, Level 16（OLE Automation disabled） - 用
EXEC xp_cmdshell 'curl ...'→ 默认禁用，启用后极难审计且存在严重安全风险 - 在触发器内写入另一张“待同步队列表”但未配合适当轮询机制 → 队列表堆积、消费者滞后、重复投递
用“触发器 + 队列表 + 外部轮询服务”解耦同步流程
真正可行的做法是把“通知”和“执行”分离：触发器只做轻量级记录，缓存同步由独立服务完成。核心在于设计一张高吞吐、低锁争的队列表，例如：
CREATE TABLE dbo.CacheSyncQueue (
QueueId BIGINT IDENTITY(1,1) PRIMARY KEY,
TableName SYSNAME NOT NULL,
RowId INT NOT NULL, -- 假设主键是 INT
Operation CHAR(1) NOT NULL CHECK (Operation IN ('I','U','D')),
CreatedAt DATETIME2(2) DEFAULT SYSDATETIME(),
Processed BIT DEFAULT 0,
ProcessedAt DATETIME2(2) NULL
);
CREATE INDEX IX_CacheSyncQueue_Unprocessed ON dbo.CacheSyncQueue (Processed)
WHERE Processed = 0;在业务表的 AFTER INSERT, UPDATE, DELETE 触发器中，仅插入该队列表：
INSERT INTO dbo.CacheSyncQueue (TableName, RowId, Operation) SELECT 'Products', inserted.ProductId, 'I' FROM inserted;
注意点：
- 避免在触发器中 JOIN
deleted和inserted做复杂判断——会显著拖慢主 DML 性能 - 不要在触发器里更新原表或其它业务表，否则形成嵌套触发器链
- 队列表的
Processed字段必须用WHERE Processed = 0过滤，并搭配过滤索引提升轮询效率
轮询服务怎么安全消费队列表而不丢数据
外部服务（如 .NET Core 后台服务、Python Celery worker）需实现“获取-处理-标记”三步原子操作，防止崩溃导致消息丢失。推荐用带输出参数的存储过程完成单次安全出队：
CREATE PROCEDURE dbo.DequeueNextCacheItem
@QueueId BIGINT OUTPUT,
@TableName SYSNAME OUTPUT,
@RowId INT OUTPUT,
@Operation CHAR(1) OUTPUT
AS
BEGIN
SET NOCOUNT ON;
UPDATE TOP (1) dbo.CacheSyncQueue
SET Processed = 1, ProcessedAt = SYSDATETIME()
OUTPUT inserted.QueueId, inserted.TableName, inserted.RowId, inserted.Operation
INTO @outputTable
WHERE Processed = 0;
<pre class="brush:php;toolbar:false;">SELECT TOP 1
@QueueId = QueueId,
@TableName = TableName,
@RowId = RowId,
@Operation = Operation
FROM @outputTable;END;
关键约束：
- 每次只取
TOP (1)，避免批量出队后某条失败导致整批回滚困难 - 必须用
UPDATE ... OUTPUT，而非先SELECT再UPDATE—— 否则并发下可能重复消费 - 轮询间隔建议 ≥ 100ms；太密会无效刷表，太长则延迟升高
- 消费失败时，应将
Processed改为-1（失败态），并记录错误日志，便于人工干预
缓存写入失败后要不要重试？怎么控制重试边界
缓存服务（如 Redis）临时不可用时，轮询服务不能简单跳过或抛异常。必须实现有限重试 + 降级策略：
- 对单条队列记录最多重试 3 次，每次间隔指数退避（1s → 3s → 9s）
- 第 3 次失败后，写入独立的
CacheSyncErrorLog表，包含原始队列 ID、错误信息、时间戳 - 不建议在数据库中自动“死信转储”到另一张表再重入队列——容易造成无限循环或状态混乱
- 如果业务允许，可设置兜底 TTL：比如热点商品信息在缓存中过期时间为 5 分钟，则队列积压只要不超过 5 分钟，就不算严重问题
真正棘手的是“部分成功”场景：比如 Redis 写入成功但 Kafka 发送失败，或反之。这种混合系统间的一致性，只能靠最终一致性模型 + 幂等消费来收敛，没有银弹。
