sys.dm_db_index_usage_stats未显示所有更新的问题求助

核心原因：sys.dm_db_index_usage_stats的统计逻辑限制 #

你遇到的情况完全符合这个动态管理视图（DMV）的设计规则：

• 这个DMV仅记录SQL Server实例启动后，用户操作触发的索引/表使用行为，且只覆盖常规DML（逐行INSERT/UPDATE/DELETE）或查询操作（SEEK/SCAN/LOOKUP）。
• SSIS的全量复制如果采用批量插入（Fast Load）模式，这类操作属于批量数据加载，SQL Server不会将其计入last_user_update，甚至不会在DMV中生成该表的条目——因为批量加载是直接写入数据页，跳过了常规DML的索引更新统计逻辑。
• TRUNCATE TABLE是DDL操作，本身就不在这个DMV的统计范围内，所以截断步骤不会留下痕迹。

另外3张表能出现在DMV里，大概率是以下两种情况之一：

• 这3张表的同步用了逐行插入模式（而非Fast Load），逐行INSERT会触发索引更新，被计入last_user_update；
• 同步完成后，这3张表被其他用户查询或修改过，触发了DMV的统计记录。

至于第4张表只有执行COUNT(*)后才出现，是因为COUNT(*)触发了表扫描操作，符合DMV的统计条件，所以生成了last_user_scan的记录，但之前的批量插入依然不会被标记为last_user_update。

解决建议 #

1. 不要依赖这个DMV验证同步结果：它的统计范围不覆盖批量加载操作，不能作为SSIS同步是否成功的依据。
2. 改用可靠的验证方式：
   • 检查SSIS作业的执行日志，确认所有同步步骤都成功完成；
   • 对比源表和目标表的行数（你已经完成这一步）；
   • 可以通过CHECKSUM_AGG(BINARY_CHECKSUM(*))对比源表和目标表的数据一致性（注意排除自增列、时间戳列这类同步后会变化的字段）。
3. 若非要让表出现在DMV中：可以在SSIS包的最后对第4张表执行一次简单查询（比如SELECT TOP 1 * FROM 目标表），触发一次扫描操作，但这仅为满足DMV显示需求，对同步本身无实际意义。

内容的提问来源于stack exchange，提问作者Oky