columns_updated() 返回位掩码判断显式更新的列，需用位运算（如 & 0x02）检测特定位，而非直接比较整数；它不反映值是否真变，须结合 inserted/deleted 表比对；update() 函数功能受限且不支持多列组合逻辑。
如何用 COLUMNS_UPDATED 判断哪些列被修改了
COLUMNS_UPDATED 返回一个 varbinary 位掩码，每一位对应表中一列（按定义顺序），值为 1 表示该列在 UPDATE 语句中被显式赋值（哪怕赋的是相同值），为 0 则未出现在 SET 子句里。
注意：它不检测值是否真变了，只看 SQL 语句里有没有写这一列。比如 UPDATE t SET name = name 中 name 会被视为“已更新”。
常见错误是直接拿返回值和整数比较，比如 IF COLUMNS_UPDATED() = 4 —— 这不可靠，因为位掩码长度随列数变化，且高位可能为零但实际占用字节。
正确做法是用位运算测试特定位：
IF SUBSTRING(COLUMNS_UPDATED(), 1, 1) & POWER(2, 0) > 0 -- 第1列（从0开始计）
或者更清晰地按列名映射位置（推荐）：
-- 假设表结构：id INT, name NVARCHAR(50), status TINYINT, created DATETIME -- 列序：id=0, name=1, status=2, created=3 IF COLUMNS_UPDATED() & 0x02 > 0 -- 0x02 = 二进制 0010 → 第2位（即 name 列）
- 位掩码字节顺序是从左到右，每字节含 8 列；第 n 列对应位偏移
n % 8，所在字节索引n / 8 - 使用
SUBSTRING(COLUMNS_UPDATED(), byte_index, 1)提取单字节再位与，比直接对整个varbinary位与更安全 - SQL Server 2005+ 支持
COLUMNS_UPDATED()在 INSTEAD OF 触发器中使用，但 AFTER 触发器更常用
为什么不能只靠 UPDATE() 函数
UPDATE(column_name) 看起来更直观，但它有严重限制：只能用于 INSERT 或 UPDATE 触发器，且对计算列、XML 列、大型对象（text/ntext/image，已弃用）或加密列返回 NULL 或不可靠结果。
更重要的是：UPDATE() 在 UPDATE t SET col1 = col1 时仍返回 TRUE，和 COLUMNS_UPDATED 行为一致，但它无法批量判断多列组合场景。
例如要触发逻辑仅当 status 或 priority 被改，而 name 没动：
-- 用 UPDATE() 得写三重判断，易错 IF (UPDATE(status) OR UPDATE(priority)) AND NOT UPDATE(name) <p>-- 用 COLUMNS_UPDATED 更可控（假设 status=2, priority=3, name=1） DECLARE @cols VARBINARY(128) = COLUMNS_UPDATED() IF (@cols & 0x0C > 0) AND (@cols & 0x02 = 0) -- 0x0C = 00001100 → status+priority；0x02 = name</p>
-
UPDATE()不区分列是否真的出现在 SET 中——如果触发器嵌套或调用存储过程间接更新，行为更难预测 -
COLUMNS_UPDATED()是底层位图，不受列类型限制，兼容性更好 - 二者都对
UPDATE ... FROM语法有效，但UPDATE()在某些 JOIN 更新场景下可能误报
实战：只在 price 或 stock 变更时写审计日志
假设订单明细表 OrderItems(id, product_id, price DECIMAL(10,2), stock INT, updated_at DATETIME)，要求仅当 price 或 stock 被显式更新时，往 AuditLog 插入记录。
关键点：必须用 inserted 和 deleted 表比对真实值变化（因为 COLUMNS_UPDATED 只管“有没有写”，不管“写没写新值”）：
CREATE TRIGGER tr_OrderItems_AuditOnPriceOrStock
ON OrderItems
AFTER UPDATE
AS
BEGIN
IF NOT UPDATE(price) AND NOT UPDATE(stock) RETURN;
<p>INSERT INTO AuditLog(table_name, row_id, action, details, changed_at)
SELECT
'OrderItems', i.id,
'UPDATE',
CONCAT('price: ', d.price, '→', i.price, '; stock: ', d.stock, '→', i.stock),
GETDATE()
FROM inserted i
INNER JOIN deleted d ON i.id = d.id
WHERE
(i.price != d.price OR i.stock != d.stock)
AND (
-- 确保 price 或 stock 确实出现在 UPDATE 语句中
COLUMNS_UPDATED() & 0x04 > 0 -- price 是第3列（0-indexed），0x04 = 00000100
OR
COLUMNS_UPDATED() & 0x08 > 0 -- stock 是第4列，0x08 = 00001000
);
END</p>
- 先用
UPDATE()快速过滤（可选但高效），再用COLUMNS_UPDATED精确锁定列位置 - 必须联查
inserted/deleted才能确认值是否真变，否则日志会刷无意义记录 - 位掩码常量（如
0x04）建议用注释标明对应列和索引，避免后期加列后失效 - 若表列数超 8，需用
SUBSTRING(COLUMNS_UPDATED(), 2, 1)访问第二字节，别硬算十六进制
容易忽略的兼容性和性能坑
COLUMNS_UPDATED() 在分区表、内存优化表（In-Memory OLTP）中行为不同：后者不支持该函数，会报错 Msg 12321；分区表则正常，但位图仍按全表列序生成，和分区键无关。
性能方面，它本身开销极小，但若在触发器中频繁调用且配合复杂位运算，可能影响高并发更新吞吐。更隐蔽的问题是维护成本：
- 当表增加新列，尤其插在中间位置时，原有位掩码常量全部失效，必须重新计算列索引
- 使用
sys.columns动态查列序（如SELECT column_id FROM sys.columns WHERE object_id = OBJECT_ID('t') AND name = 'col'）虽灵活，但触发器内不建议执行查询，会引入额外锁和延迟 - SQL Server 2022 开始支持
IS_COLUMN_SET，但仅限稀疏列集，不适用于普通场景
最稳妥的做法：把列序映射固化在注释里，并在建表/改表 SOP 中强制要求同步更新触发器中的位常量。
