这种方法最为简单直接，反正不管三七二十一，搜索引擎每次全量拉取商品信息表所有数据，然后创建搜索索引，提供给外部客人查询。这种方法实现起来的确最为简单，当然同时也具有非常明显的缺点：

  • 浪费资源： 假如商品的变更频率为20%，那么剩下的80%商品实际上是不需要更新的。换句话说全量更新会浪费掉80%的系统资源(IO/CPU/Memory)来做无用功。
  • 耗时严重： 由于获取的是表的全量数据，所以全量更新大大增加了数据获取阶段和搜索索引生成阶段锁的概率，加之浪费资源做无用功，最终导致时间消耗大大拉长。

全量+增量更新

针对全量更新的种种“罪行”，我们可以有针对性的采用全量+增量更新的方式来有效解决。这种方法的思路是，我们可以周期性的做全量更新，比如每天或者每周，然后在两个全量更新周期之间，我们采用增量更新的方式来覆盖新的数据变更，比如每小时或者每分钟。增量更新问题的关键在于如何获取数据变更记录，让我们来看看关系型数据库MSSQL Server是如何提供解决方法的。

MSSQL Server提供了一个函数，名为COLUMNS_UPDATED可以解决这个问题。先让我们来看看微软官方的解释：返回 varbinary 位模式，它指示表或视图中插入或更新了哪些列。官方文档的解释非常的抽象，如果想要使用这个函数来获取数据变更记录，我们需要踩过很多坑，突破很多点，这也是这篇文章的价值。

首先，我们来看看这个函数表达的含义。假如某张表有8个字段，那么COLUMNS_UPDATED使用一个byte，八个bit来表示哪些列发生了数据变更，表示方法如下：

Col_id：表字段顺序ID

Bit：bit位顺序，从0开始

Value：2的bit次方

当某些列被更新后，COLUMNS_UPDATED函数会返回varbinary位模式（varbinary位模式是什么？可以理解为所有列Value的SUM值的二进制格式）。比如：当第二列和第四列被更新，那么COLUMNS_UPDATED的varbinary位模式是2 + 8 = 10。来看一个具体的例子。

踩过的坑1: INT数据类型溢出

注意上面的代码POWER(2, column_id - 1)，返回的应该是一个INT数据类型的值。在MSSQL SQL Server中INT类型使用4个字节来存储，也就是32bit，换句话说，当表的字段列个数达到32时，这个POWER操作会导致INT数据类型溢出而报告异常。当我们将上面的表字段加到32个后，INSERT和UPDATE操作会导致TRIGGER报告如下错误：

关于这个问题，在没有完美的解决方法之前，很长一段时间，我们强制将POWER转化为BIGINT数据类型来暂时突破32个字段数量限制。但是，这个坑原理和上面一样，仅仅是将字段数量从32个扩大到64个。方法如下：

如何完美的解决上面两个坑，我们先暂时留个悬念。

庖丁解牛

让我们回到最原始的需求，对于DML操作，不外乎三种，即INSERT，UPDATE和DELETE。我们的Trigger必须具备识别这三种操作类型的能力。

INSERT：Trigger需要具备识别表数据行唯一标识(RID)的能力（通常是主键），然后通过RID反过来查询正式表即可。

UPDATE：Trigger需要具备识别哪些字段被更新的能力，然后通过RID获取这些被更新的字段的值。

DELETE：Trigger获取到数据行唯一标识即可，通过RID删除对应的行。

最后一条查询语句结果如下截图：

02.png

Rowid 1-3:表无主键，但存在IDENTITY属性列的情况，RID为IDENTITY属性列的值，我们抓取到的RID和Updated_columns

Rowid 4-6:表无主键，但存在UNIQUE约束的情况，RID为UNIQUE列的值，取到的RID和Updated_columns

Rowid 7-9:表有主键，这里是更加复杂的联合主键，RID为联合主键的值，取到的RID和Updated_columns

在本例的表字段个数超过了64个，达到73个，我们是采用循环获取的方式来踩过坑1和2，具体代码268行到307行。

到目前为止，我们的搜索引擎只需要从dbo.triggeredDataLog表中获取数据变更RID和相应发生了变化的字段Updated_columns，而不需要从正式表中整个拉取全量数据，节约了数据库系统开销，增加了搜索索引创建的时效性，提高了客户体验。

注意：