这是我昨天提出的一个问题的后续问题：我可以批量插入空的页面压缩表并获得完全压缩吗？这个问题的答案（转述自 Randi Vertongen 的优秀回答）是肯定的，但它要求批量插入采用表级锁；否则，大容量插入采用行级锁并仅执行行数据压缩。这就提出了一个问题：之后我如何知道应用了什么压缩？
下面是在理论上页压缩的表中创建行压缩数据的步骤：
1. 创建一个表，DATA_COMPRESSION=PAGE并不使用sp_tableoption打开该表的“批量加载表锁定”选项。
2. 使用 bcp 将平面文件中的数据批量插入到新表中，但不指定-h TABLOCK锁定表的选项。
结果是一个表中的数据在行级别上被压缩（小于未压缩表但大于页压缩表），但检查sys.allocation_units目录表显示数据压缩为页。
问题
在这种情况下，当表的数据分配用于页面压缩时，我该怎么做才能确定该表中的数据是否经过页面压缩？
我有很多大表（大约 1000 万行宽）需要定期加载到 SQL Server 2016 中以进行只读报告。我希望这些表在磁盘上尽可能小，这比加载或查询的性能改进更重要。
这是我对不需要进一步索引的表所做的工作：
DATA_COMPRESSION=PAGE. 表中的列类型是 varchar（不超过 512，不是最大值）、float、tinyint 或日期（不是日期时间）。所有列都创建为可为空的，并且没有定义主键或外键——它们与查询无关，表永远不会直接更新。一切的默认排序规则是SQL_Latin1_General_CP1_CI_AS.
当我这样做时，我可以看到sys.allocation_units该页面数据压缩已应用于堆，并且我可以看到sys.partitions填充因子正确为 0 (100%)。由于表比未压缩的表小得多，我认为压缩已完成。
但是，如果我然后使用相同的选项重建DATA_COMPRESSION=PAGE，则假定已经压缩的表会缩小大约 30%！看起来它从每个数据页大约 17 行到每页 25 行。（虽然只有一次。在那之后再次重建不会使它比第一次重建更小。）
问题
所以我的问题是：（a）这里发生了什么？(b) 有没有办法在加载表时直接获得这个超小的压缩大小，而无需在加载数据后重建？