需要一些输入，我需要使用colprimkey 1，col 2，colyear，day 1，day 2，day 3，...day366在azure/synapse中创建类似这样的表（为了拥有更少的记录，否则将以十亿条记录结束），它是否更适合DML主要更新并给予更好的性能（稍后将取消透视），而不是使用类似这样的表
列主键1，列2，列年，日期，日期数据then 1，xx，2020，'第1天'，88 1，xx，2021，'第4天'，28？
我正在尝试第一列第二列第一年第一天第二天第三天...第366天1，xx，2020，88，10，34，28，... 41
关于效率、存储、性能等方面的任何其他建议提前感谢
我尝试了小数据，但没有在大规模只认为考虑是它将减少表中的记录数，但列明智的更多的数据将有。
如果有人在类似的情况下工作，并得到更好的解决方案，让我知道
1条答案
按热度按时间iq3niunx1#
如果有人在类似的情况下工作，并得到更好的解决方案，让我知道
是的，我曾经处理过数TB的表，每个表中有数十亿行。
有关效率、存储、性能的任何其他建议
不要以行换列。正确地设计表，并使用根据计划运行的查询类型设计的适当索引。
它是否更适合DML主要更新并给予更好的性能
不，事实上，这可能会降低性能，尤其是在尝试搜索多个列或将数据重新拼凑在一起时。
B树索引的搜索时间复杂度为
O(log(n))。如果您的表有10亿行，在最坏的情况下log2(1 billion)= 40。这只需要搜索40个节点就可以找到您要搜索的任何数据子集。如果您的表增长到1万亿行，log2(1 trillion) = 50。我的图形计算器可以在一秒钟内搜索50个节点。在几毫秒或更短的时间内完成。如果您计划执行聚合类型的查询，则从压缩Angular 和批处理模式操作来看，列存储索引可能会更有效。
如果将行拆分为多个列，则会失去上述方法所带来的效率提升，并且需要编写更复杂的查询来搜索和重塑数据。对数十亿行执行取消透视操作将花费很长时间。