昨天我在查询时遇到了一些性能问题,经过进一步调查,我注意到我认为我正试图深入了解的聚集列存储索引的奇怪行为。
该表是
CREATE TABLE [dbo].[NetworkVisits](
[SiteId] [int] NOT NULL,
[AccountId] [int] NOT NULL,
[CreationDate] [date] NOT NULL,
[UserHistoryId] [int] NOT NULL
)
与索引:
CREATE CLUSTERED COLUMNSTORE INDEX [CCI_NetworkVisits]
ON [dbo].[NetworkVisits] WITH (DROP_EXISTING = OFF, COMPRESSION_DELAY = 0) ON [PRIMARY]
该表目前有 13 亿行,我们不断地向其中插入新行。当我说不断时,我的意思是一直。这是一次向表中插入一行的稳定流。
Insert Into NetworkVisits (SiteId, AccountId, CreationDate, UserHistoryId)
Values (@SiteId, @AccountId, @CreationDate, @UserHistoryId)
执行计划在这里
我还有一个计划作业,每 4 小时运行一次,以从表中删除重复的行。查询是:
With NetworkVisitsRows
As (Select SiteId, UserHistoryId, Row_Number() Over (Partition By SiteId, UserHistoryId
Order By CreationDate Asc) RowNum
From NetworkVisits
Where CreationDate > GETUTCDATE() - 30)
DELETE
FROM NetworkVisitsRows
WHERE RowNum > 1
Option (MaxDop 48)
执行计划已粘贴在这里。
在深入研究这个问题时,我注意到该NetworkVisits
表中有大约 2000 个行组,其中大约 800 个处于打开状态,并且没有接近允许的最大值 (1048576)。这是我所看到的一个小样本:
我对索引进行了重组,压缩了除 1 个行组之外的所有行组,但今天早上我再次检查,我们再次有多个打开的行组 - 昨天在重组后创建的行组,然后大约在删除时创建了 3 个其他行组工作运行:
TableName IndexName type_desc state_desc total_rows deleted_rows created_time
NetworkVisits CCI_NetworkVisits CLUSTERED COLUMNSTORE OPEN 36754 0 2019-12-18 18:30:54.217
NetworkVisits CCI_NetworkVisits CLUSTERED COLUMNSTORE OPEN 172103 0 2019-12-18 20:02:06.547
NetworkVisits CCI_NetworkVisits CLUSTERED COLUMNSTORE OPEN 132628 0 2019-12-19 04:03:10.713
NetworkVisits CCI_NetworkVisits CLUSTERED COLUMNSTORE OPEN 397718 0 2019-12-19 08:02:13.063
我正在尝试确定可能导致创建新行组而不是使用现有行组的原因。
插入和删除之间是否可能存在内存压力或争用?这种行为是否记录在任何地方?
我们在此服务器上运行 SQL Server 2017 CU 16 企业版。
是INSERT
MAXDOP 0,DELETE
是 MAXDOP 48。唯一关闭的行组是最初的行组BULKLOAD
,然后REORG_FORCED
是我昨天做的行组,所以修剪的原因分别sys.dm_db_column_store_row_group_physical_stats
是REORG
和NO_TRIM
。除此之外没有封闭的行组。没有针对此表运行的更新。我们在插入语句上平均每分钟执行约 520 次。表上没有分区。
我知道涓流插入。我们在其他地方做同样的事情,并且在多个开放行组中没有遇到同样的问题。我们怀疑它与删除有关。每个新创建的行组都在计划删除作业的时间附近。只有两个增量存储显示已删除的行。我们实际上并没有从这个表中删除很多数据,例如在昨天的一次执行中,它删除了 266 行。