SQL Server聚集索引大于实际表。为什么以及如何解决?

时间:2019-01-04 20:49:26

标签: sql-server database sql-server-2016 database-administration clustered-index

我在SQL Server数据库中有几张表,其中聚集索引确实很大,仅用于ID的大小就达到表大小的50%?

例如:

  • 表1 3000万行,10GB数据,聚集索引= 10GB
  • 表2 4000万行,2.4GB数据,聚集索引= 18GB

获取我正在使用的索引大小的脚本为:https://blog.sqlauthority.com/2016/11/13/find-size-indexes-database-interview-question-week-097/

SELECT
    OBJECT_SCHEMA_NAME(i.OBJECT_ID) AS SchemaName,
    OBJECT_NAME(i.OBJECT_ID) AS TableName,
    i.name AS IndexName,
    i.index_id AS IndexID,
    8 * SUM(a.used_pages) AS 'Indexsize(KB)'
FROM 
    sys.indexes AS i
JOIN 
    sys.partitions AS p ON p.OBJECT_ID = i.OBJECT_ID AND p.index_i = i.index_id
JOIN 
    sys.allocation_units AS a ON a.container_id = p.partition_id
GROUP BY 
    i.OBJECT_ID, i.index_id, i.name
ORDER BY 
    8 * SUM(a.used_pages)

索引代码如下(两个表都相同):

ALTER TABLE [dbo].[my_Table] 
     ADD PRIMARY KEY CLUSTERED ([pkID] ASC)
         WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
               SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, 
               ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

请有人可以帮助我解决此问题,或帮助解释为什么会发生这种情况吗?

索引完全没有碎片(<5%),可以肯定,就像聚集索引一样,它里面只有PK?每个表中都有一个nvarchar(max),这是索引中的“隐藏”内容吗?仍然没有解释为什么它比实际表大?

我正在使用SQL Server 2016 Standard。

感谢您度过美好的一天。 韦德

1 个答案:

答案 0 :(得分:0)

我们通常为日志文件使用的初始空间超过1 GB,以避免更多的VLF,这有助于更快地恢复并提高性能。并且自动增长应超过1 GB,这将严格生成更多VLF。

如果知道加载行为,则可以分配最大的初始大小,这将有助于提高性能,因为它不会每次都初始化文件。

请告诉我是否有帮助。