Change Tracking 可准确捕获 INSERT 行，需配合 CHANGETABLE(CHANGES) 与有效版本号；漏掉 INSERT 常因版本越界、未提交事务、历史数据无记录或权限/保留期不足。
Change Tracking 本身不区分 INSERT/UPDATE/DELETE 的具体数据内容，但它能准确告诉你哪些行被插入了——前提是正确使用 CHANGETABLE(CHANGES) 并配合版本号比较。
为什么直接查 CHANGETABLE(CHANGES) 可能漏掉 INSERT
Change Tracking 不保存变更前后的值，只记录“某主键行在某版本发生了某操作”。如果你用固定起始版本（比如 0）反复查询，而中间有未提交事务或版本清理发生，就可能跳过某些 INSERT。更常见的是：没正确处理版本边界，导致第一次同步时漏掉初始数据。
- SQL Server 的版本号是全局递增的，但
CHANGETABLE(CHANGES)要求传入的版本必须 ≥CHANGE_TRACKING_MIN_VALID_VERSION()，否则报错The specified version is invalid - INSERT 操作对应的
sys_change_operation值是I，但这个标记只在该行首次出现的版本中有效；后续版本里它不会重复出现 - 如果表刚启用 Change Tracking，且已有历史数据，那些行不会自动产生 INSERT 记录——Change Tracking 只跟踪启用之后的变更
正确获取新增行的三步实操
以表 dbo.orders 为例，主键为 order_id：
- 第一步：获取当前有效最低版本
SELECT CHANGE_TRACKING_MIN_VALID_VERSION(OBJECT_ID('dbo.orders'));—— 记下返回值，比如是123 - 第二步：查询自该版本以来的所有变更，并过滤出 INSERT
SELECT order_id, sys_change_operation FROM CHANGETABLE(CHANGES dbo.orders, 123) AS CT WHERE sys_change_operation = 'I'; - 第三步：更新你的“已处理版本”为最新值
SELECT CHANGE_TRACKING_CURRENT_VERSION();—— 下次同步就用这个值作为新起点
track_columns_updated = ON 对 INSERT 没影响，但别误开
这个选项只影响 UPDATE 操作是否记录哪些列被改过，对 INSERT 和 DELETE 完全无作用。开启它会略微增加日志和 tempdb 开销，纯 INSERT 场景下没必要设为 ON。
- 建表后启用时写：
ALTER TABLE dbo.orders ENABLE CHANGE_TRACKING WITH (track_columns_updated = OFF); - 如果已经启用了，无法单独关闭该选项，只能先
DISABLE再重新ENABLE - 检查状态用：
SELECT object_id, is_track_columns_updated_on FROM sys.change_tracking_tables WHERE object_id = OBJECT_ID('dbo.orders');
容易忽略的权限和保留期陷阱
即使语法全对，也会因两个隐形条件失败：
- 用户必须有
VIEW CHANGE TRACKING权限，否则CHANGETABLE返回空结果，且不报错 —— 这是最难排查的问题之一 - 数据库级保留期（
CHANGE_RETENTION）若设得太短（比如 1 小时），而你的同步周期长于该值，旧版本就会被自动清理，导致CHANGETABLE查不到早期 INSERT - 确认保留期：
SELECT retention_period, retention_period_units_desc FROM sys.change_tracking_databases;
Change Tracking 的 INSERT 捕获本质是“版本差集”，不是事件流。它可靠，但要求你严格管理版本号、权限和保留策略——少一个环节，增量就断了。
