【发布时间】:2020-11-03 06:20:32
【问题描述】:
我们有一个 250GB 的数据库,其中包含一个 180GB 的表(5500 万行可能 550 列),我们将通过它在末尾添加 24 个新的空白列;
ALTER TABLE [Rpt].[tblHoldings]
ADD
[Rating01AgencyCode] VARCHAR (50) NULL,
[Rating01TypeCode] VARCHAR (50) NULL,
[Rating01Code] VARCHAR (50) NULL,
[Rating01Score] FLOAT (53) NULL,
[Rating02AgencyCode] VARCHAR (50) NULL,
[Rating02TypeCode] VARCHAR (50) NULL,
[Rating02Code] VARCHAR (50) NULL,
[Rating02Score] FLOAT (53) NULL,
[Rating03AgencyCode] VARCHAR (50) NULL,
[Rating03TypeCode] VARCHAR (50) NULL,
[Rating03Code] VARCHAR (50) NULL,
[Rating03Score] FLOAT (53) NULL,
[Rating04AgencyCode] VARCHAR (50) NULL,
[Rating04TypeCode] VARCHAR (50) NULL,
[Rating04Code] VARCHAR (50) NULL,
[Rating04Score] FLOAT (53) NULL,
[Rating05AgencyCode] VARCHAR (50) NULL,
[Rating05TypeCode] VARCHAR (50) NULL,
[Rating05Code] VARCHAR (50) NULL,
[Rating05Score] FLOAT (53) NULL,
[Rating06AgencyCode] VARCHAR (50) NULL,
[Rating06TypeCode] VARCHAR (50) NULL,
[Rating06Code] VARCHAR (50) NULL,
[Rating06Score] FLOAT (53) NULL ;
我们过去使用相同的方法在此表中添加了 75 个列,并且只用了几秒钟。这一次,在弹性 Azure 池 (800 EDTU) 中,我将 DB 最大大小设置为 500GB,但在运行上述查询 6 小时 后空间不足。
这似乎是在后台间接重建表或更多(即使这是一个不涉及直接复制表的 TSQL 调用) - 更奇怪的是,即使它重建了表,为什么它需要更多比另一个 ~180 GB(即 250 GB + 另一个 180 GB 应该小于 500 GB)
注意:这些不是具有任何默认值或上面未显示的任何其他内容的索引列
我很想知道这是否是预期的行为。是否存在将可空列添加到表末尾会触发重建的任何条件,如果是,是什么条件强制执行此操作,为什么它比原始表消耗更多?
【问题讨论】:
-
看看那些列名让我畏缩 - 你应该使用正确的关系建模 - 而不是这样的 - 这违反甚至关系数据库设计的第一范式!
-
@marc_s 这并不是一个规范化的表格。它的意思是完全相反的。
标签: sql-server azure-sql-database alter-table