SQL Server性能:50列vs单二进制/ varbinary

是否可以通过用float一个binary(n)(n50 x 4)替换(比如说)50 列来改进SQL Server 2008 R2(和更新版本)的插入性能？

我认为使用固定大小binary(n)应该可以提高性能(数据量相同,处理所有列和更短的SQL查询所需的工作量更少),但许多网站建议不要使用binary列,所以我想看看是否有使用它真的有问题吗？

此外,问题是该表是非规范化的,并且通常不是所有列都填充值,因此varbinary(n)在许多情况下允许我减小行大小.有时只填充一列,但平均为~10列.

然后第三个问题是,如何更进一步,用一个替换(比如说)5行×50 float32列varbinary(5*50*4)？

因此,获得一些见解会很酷:

float用单个替换1行50 列binary(200);

float用单个替换1行50 x varbinary(204)(标志/长度信息的几个字节) - 在未使用列时节省空间;

float用单个替换5行50 x varbinary(1024)(标志/长度信息的几个字节).

在所有情况下,始终一次读取整行.

(更新)

为了澄清,存储的数据是:

 Timestamp_rounded    Value_0ms  Value_20ms  Value_40ms ... Value_980ms
 2016-01-10 10:00:00    10.0       11.1        10.5     ...    10.5

我总是读取整行,主要聚类键是第一列(Timestamp),我将永远不必通过任何其他列查询表.

标准化数据显然会有一个Timestamp/ Value对,Timestamp然后具有毫秒精度.但是我必须存储50行的两列,而不是1行(Timestamp+ BLOB).

这是个坏主意.拥有50列4个字节而不是一个200字节的列消除了为这50个列中的任何一个优化查询的任何希望.首先,从"经典"SQL Server pov开始:

您可以消除下推谓词和扫描时间过滤

您消除了索引的可能性

您消除了数据纯度检查(对于浮点数尤其重要,因为并非所有位模式都可以生成有效的浮点数!)

您可以消除基于成本优化的列统计信息

当你更"现代"并开始考虑SQL Server更新的选项时:

您可以消除行内压缩选项

您消除了列式存储选项

您消除了内存存储优化

所有这些甚至没有考虑到你对试图查询数据的同胞造成的痛苦.

问题是该表是非规范化的,并且并非所有列都通常填充值,因此varbinary(n)允许我在许多情况下减小行大小.有时只填充一列,但平均为~10列.

然后使用行压缩存储:

ALTER TABLE  REBUILD PARTITION = ALL  
   WITH (DATA_COMPRESSION = ROW);

如果数据仅附加且很少更新/删除,并且大多数查询都是分析性的,那么甚至可以更好地使用列存储.由于SQL Server 2016 SP1列存储可用于每个 SQL Server版本.